It’s been a while since PHP has had its security functions augmented with password_hash and password_validate. In fact, these functions are so important they’ve been backported into earlier versions. We’ve written about this API before and we’ll have more to say on it, but for now, I’d like to mention an interesting post by Evert Pot from not so long ago.
Evert argues that because it was possible to build this functionality in PHP without resorting to lower level languages, it should have been done exclusively so. He argues against upgrading PHP’s core with such functionality naming reasons such as it introducing more maintenance overhead in a language fewer developers of our ecosystem are familiar with. He also argues that it’s more difficult to get people to upgrade their PHP versions as opposed to getting them to install a simple package.
I’m on the fence about this.
On one hand, you know I’m a stickler for cutting edge - I’ll upgrade anything and everything and rather rewrite 10k lines of code to make them fit a new version than suffer an old one. Like solving USA’s ban on Kinder Surprise by simply unbanning it and letting evolution take its course, I’d solve the upgrading problem by just leaving everyone who refuses to do so behind to die in the dust. If you can’t upgrade, that means you refuse to upgrade, and no, your client/employer can’t insist on using an older version or a specific host - it’s your job to educate them. Also, if we put the functionality inside PHP, we basically force everyone on PHP 5.5+ to have it installed, which is arguably easier to achieve than to convince security newbies to use a package they’re not comfortable with. We live in a world where even some experienced devs are still afraid of Composer, so getting them to become package-friendly wouldn’t be an easy task. Evert mentions Python as a role model here, but we’re far from Python’s status - PHP only recently got proper package management in the form of Composer.
On the other hand, having this functionality written in PHP code through-and-through would make it more accessible to PHP devs for reviews and potential fixes, should anyone feel competent enough to meddle. It also makes it easier to keep it all in sync across PHP versions. In future major versions, the API might change significantly for some reason or other and keeping the API consistent across versions if it was a PHP-only implementation would be easier. Heck, someone might even come up with a better solution, and having to fight the standard implementation as implemented in the core would be a terrible battle, once again dividing the community as the “elders” bite down hard to defend the outdated approaches, while the fresh(er) blood argues for change.
What do you think? Which side would you take in this argument?
I think this is the crux of the argument here. If we end up with different branches of the same core libraries then there is simply no point including them in PHP in the fist place because PHP might not provide the “right” one. The second issue here is that if I include two libraries in my project using different branches of the core functionality then I have to include both versions of that functionality. Performance problems, compatibility problems… it’s a huge can of worms.
The other alternative is for PHP to only provide interfaces. One the face of it, this sounds like a good solution. That way a library is only dependent on the interface. A “PasswordHash” interface, maybe. It’s then up to the user to install a suitable implementation. Ideologically this is a fantastic approach as it’s the most flexible. My issue is, that from a practical perspective it doesn’t actually add any benefit to 99% of people. Not only that, for new developers who just want to hash a password they have to search around for a specific implementation which is needlessly confusing.
That seems a bit short sighted. There are several reasons why one might not be able to upgrade immediately, but it looks like you’re already admittedly a full zealot of what I call the “Apple lifecycle”
Cost - as the adage “it’s cheaper to add hardware than rewrite code” is so prevalent, there are times when upgrades to PHP might mean a new server is required. Or a new version of mySQL/PostgreSQL, which have requirements which mean new hardware. And if the current host can’t provide, that means transitioning to a new host, which means a whole other migration effort, which must be planned and executed.
Time - it’s very rare that a new version of something fixes just one problem/issue, so there is time which is going to be required to evaluate the differences, then time to code and test the changes and all the associated test cases.
I would LOVE to be able to be cutting edge, but our customers would string us alive if we told them we were going to have to stop maintenance for six+ months while we refresh our 100+ applications and supporting code base to today’s best practices, which will allow us to support them better in the future.
Try talking management or executives into allowing a team of 6 figure (or close to) developers drop everything, or slow down considerably and completely re-architecture their software every few months. But if you’re salary, I’m sure they’d be willing to let you do it as long as you’d be willing to work 80-120hr weeks until it’s completed… that is if you’re not already doing that already.
I’m sure people who’ve never worked in enterprise apps see this as just being excuses, but that doesn’t change the fact that it’s reality. Or they may say “don’t work in enterprise then”, which again… the reality that enterprise applications literally drives the world’s economy.
Ain’t that the truth? We’re doing something similar to deal with a new product line for our company. It’s a struggle to do that and still keep up with the existing product line as well.
You lost me there, can you elaborate on this reference? : )
No, no, never this. But a sub-team of main devs can easily prepare the grounds for new versions, while the others do maintenance of the old system. Naturally, I speak here only of useful updates - not updates for the sake of updating. For example, ditching ZF1 for any other framework = valid. Ditching Symfony 2.4 for 2.6 if everything still works, not so much.
Regardless, this isn’t the topic of this discussion - the flames have been sent my way already regarding my stance on legacy code in the article linked in the text above : ) I’d rather talk about the PHP implementation of core functionality - yay or nay?
I build Web sites for very small clients who can only afford shared hosting (over 60% of my clients are still hosted on 5.2.17). I can’t add a package or extension. That makes my vote default to core, because that’s the only way I’ll ever get a feature.
Um, I am also on the fence on this. Although hashing and verifying a password are simple tasks probably done better at a lower level, there are functions that could be added to verification, which makes the system a bit more secure, like what Symfony does with stringUtils, which you can use to avoid timing attacks. Theoretically, such a feature, like StringUtils offers, could also be part of the verify_password() function, but it isn’t and thus “unknowing” developers wouldn’t know to add such a function to their password verification, when essentially, it could be part of the function and in every PHP application. So…hmmm…
I tend to agree. I can’t recall which upgrade of PHP it was now, but my host moved versions unbeknownst to me. Or at least until I started getting error reports coming out of my (blog I think). Whilst it forced me into an upgrade I’d not really given too much consideration too on my installation, it got me back on the horse so to speak. For me and a single personal blog that’s not life changing, but I can readily understand how someone managing on a more professional basis would need to be a bit more proactive in how they managed that eventuality.
But is it, though? You’re using a long dead version of PHP (5.2), so it’s highly unlikely you’ll ever really get to the version which does have these functions in the core.
That sounds strange. Have you investigated enough options? You have VPS hosting today as cheap as shared hosting, i.e. on DigitalOcean, where you are in absolute control over what you install on the server, from PHP version all the way down to OS. If that’s not your cup of tea, brutally cheap shared hosts like Hostgator have 5.5 already.
Bruno, that’s just not a real-world position. 5.2 might be “deprecated” but it’s the heart of more than half my clients’ sites. It’s alive and breathing in the wild.
Spoken like someone who is complete control of their PHP environment. Again, reality, that’s a pipe dream for me. My clients pay for their hosting, I give them the best advice I can and they decide what they will pay. $70 one way or the other may not be a big deal to you or me, but what do you think a very small business person faced with $70 or $140 options is going to choose? They’ll pay a lot for me to build the site, but when recurring costs are involved they are very, very tight-fisted. It’s their tea.
Don’t misunderstand me here. Your job is to be very current with PHP and you do that well. I’ve been a magazine editor and I know how it is. But I’m in the trenches now.
A lot of my clients are at HostGator. I appreciate that I have a choice of PHP versions there but if the client hasn’t asked me to do anything and the site is running fine, I won’t alter the PHP version just on principle. And more reality, HostGator’s reliability and availability have plummeted since EIG decided to consolidate HG’s data center in Utah with BlueHost, so I no longer recommend HG for reasons other than PHP. Don’t get me started.
I’m aware of the options and I do my best to keep up. One thing I can’t afford is to become a systems administrator for all my clients, so I’ll only move a client to VPS if performance demands it and then I’ll still want a stable environment managed by the vendor. Because my clients are small, heavier solutions have not yet been necessary.
My main concern would be speed. PHP is not the fastest language out there (to put it mildly), and if they were to migrate from C to PHP the speed would take yet another hit. I’m not sure if that weighs up against the benefit of easy backporting. Personally I don’t think so, but I have the advantage of working for a company that are always on the latest PHP version, or at most 1 minor version behind, so I guess I’m biased there.
It’s not deprecated, it’s effectively dead. As in, “must not be used or you’re putting users in danger” dead. See here.
But you should - not on principle, but because dead versions didn’t get their security fixes in a while and are vulnerable by default. See here.
What are your major dislikes with HG? I use it to host a couple of inboxes and a couple dozen parked domains so I don’t have to maintain a thing, and it works like a charm.
I can relate to that, but if all are so small, then it should be even easier to host multiple clients of yours on a single VPS instance, making it even cheaper for them, and much easier for you to keep up to date. By doing that you gain the most up to date and secure environment, maximum reliability, and most importantly, you avoid the pitfalls of shared hosting, particularly in regard to, for example, 777 permissions in modern CMS where having such a folder open is required for the CMS but incredibly insecure in general.
PHP is actually one of the faster interpreted languages, and it’ll only be faster with PHP7 if benchmarks are to be believed. I agree with the speed argument - a C version will usually be much, much faster if done right. Whether that’d be needed, though, needs to be decided on a case by case basis - in password hashing, speed is completely irrelevant.
A core tenet of my business is that my clients can walk away from me safely at any time. (The reason is my age.) I do nothing that makes my clients dependent upon me, which means I don’t resell anything. I should probably add that this business practice makes my clients very loyal.
The CMS is my code. It doesn’t leave anything open.
Mostly availability. Most of my HG clients are getting two 9s, which is pathetic. I don’t expect top-tier enterprise data center five 9s - I’ll settle for four.
Performance is off since the move to Utah. Code performance is about the same but my belief is that more sites are being crammed into single servers, which means that sometimes my client’s sites don’t stay cached very long. But the big problem is latency, which makes me think the Utah data center doesn’t have enough bandwidth or has problems with its internal network (my best guess based on a number of incidents with support).
HG also angered me with its handling of the move to Utah, which required me to touch every single client I had hosted there. That came out of my hide; I couldn’t charge my clients for HG’s bad planning. It was so bad that I had a checklist of everything I had to do to correct the problems created by the move. This disaster played out over several months.
I told you not to get me started. I moved my own sites from HG to a better host (albeit with PHP 5.3) just this past Monday. I’m cancelling my HG account today.
You’re comparing parked domains in one account to a few dozen live sites?
I know. But what would you have me do, tell my clients that they have to pay me to move them from a host where they’ve been for six years and that I suggested they buy in the first place for security threats that are very remote and will inflict little damage if they do materialize? I say little damage because a) these clients don’t have sites that are inviting targets and b) I’m not so stupid that I would not take precautions of my own, which of course I won’t discuss.
No, just update the PHP version on Hostgator to 5.5 if you don’t want to move away from it. You get the security and features, and none of the hassle. No need to charge anyone anything. Additionally, you get built-in opcache and other wonderful stuff which improves PHP’s speed drastically without you having to do anything.
No comparison was made. Just said that I’ve yet to encounter a problem.
At this point in the evolution of my code I can do that (and I do) but not all my clients have my most current code. I found some problems when I first tried 5.3, which I took care of. But I can’t go back and upgrade all those sites unless the client has given me some paying work. Believe me, I don’t want to deploy on 5.2.
It’s not PHP versioning that drove me from HostGator, though.
I just found out today that HostGator is moving its data center again, back to Texas. I’m scared to death.