Wedge

Much as I hate to get involved, someone who I owed a favour to asked me to comment.

Firstly, you're incorrect about some of your assertions. The salt you're referring to is not used to compute the password hash. The password in the database is stored as SHA1(strtolower(username) . password) and has been for a very long time in SMF. No extra table is required for this. Oh, and if you notice, it's not actually 'rolling their own'. It's following standard practice (take the password, add something that's account specific and hash that)... and in ANY case the salt would be useless if it were used because it's RIGHT THERE IN THE TABLE. It's only any use if it's otherwise an unknown, but since it's not an unknown element, because it's right there in the table, it doesn't really help any since you already have to construct a rainbow table for every account in the first place.

Secondly, not all hosts are currently using 5.3.7 and up. There are still some very major hosts running 5.2 and in fact some hosts still offering 4.4 hosting for the time being, even though 5.3 itself is officially maintenance only now, and most of SMF's typical demographic applies to those because they're the budget end of the market. So that's not really something SMF can implement in a realistic fashion, but I guess reality of lots of support requests (and there are already multiple requests per day related to one really poor free host and their limitations, but hey, let's add a crap ton more!) is irrelevant.

Thirdly, I don't believe you understand what it means by 'decrypting the password'. It is mathematically impossible to actually decrypt the password hashed by a digest hash like SHA1. What you do is find something that when combined with the username and then hashed will give you the same hash as what you're looking for... that means potentially multiple passwords will actually work because you're not looking to find the original, you're merely looking for a collision. You may want to search for multiple collisions for this very reason.

Fourthly, it is well researched and documented that most people suck at choosing passwords. A 2011 study (whose link I can't immediately find) found that 'password' was still by far the most common password, followed by '123456' and direct variations of that. Breaking into systems can be done with that fairly easily.

Incidentally, pushing everything to bcrypt may not be the smartest idea in the world. If everything is pushed to bcrypt and a *single* vulnerability is found, suddenly a lot more targets are actually located. Having everything in a slightly different form does at least have some benefits with respect to lowering the immediate attack vector options. There is a little comfort - but very certainly not a lot - from security through obscurity, but it is no substitute by any means for real security.

Thing to note: the system is only ever as strong as the people who hold the keys to it. It is often significantly easier to leverage a weakness in a person rather than in the technology under them, as was done here, to leverage the access to perform queries on the database. Once the database is compromised, best security practice is to assume it is *always completely compromised* even if the data is encrypted with the strongest possible methods, because you never know what resources the intruder has to break that.

Consider: this attack was to force an admin's account. If there was no way to run arbitrary code through some fashion with an admin's account or to pull a database backup of some kind, there would be less risk. In fact, if there is no method by which to run arbitrary code or pull a database backup without server access directly, you need to do more than brute force that account, and proceed to brute force a server account. If someone's already gotten into the server itself, assume everything is compromised anyway because by definition it is.

The whole thing about hashes is only an issue if someone gets into the server or otherwise can obtain raw access to the tables and right now there are ways by which an admin can do just that, either by splicing code into template files, or by uploading a package. Stronger controls need to be added to these to prevent arbitrary code being able to be run with just an admin's account, for example enforcing upload via FTP of plugins (as other software does), as well as limiting the ability to run arbitrary code from the admin panel by removing the ability to edit files from said admin panel and enforcing use of either hosting control panel or FTP download/local editing.

I see where you're going but honestly you're picking on one of the stronger links in the chain. There are far, far many more issues to consider... like how on a number of shared hosting setups it is actually possible for your setup to be hijacked as soon as you install a mod. Or how in a number of shared hosting setups it's possible for your entire database to be compromised and with you not being able to do *anything* about it whatsoever. But of course these are minor considerations when compared to worrying about what will happen when a hacker gets in... I'd personally prefer to keep them out in the first place where possible, rather than tightening up what happens when they already have. (Not that you shouldn't ALSO do that, but in terms of priority, it's really a secondary consideration. Don't worry about locking up the family silver if the front door is already unlocked.)