I really, really, really wish that GoPHP5 Round Two [1] takes off and all the popular blog & forum programs get on board.
PHP 5.3.7 is the first version of PHP that is guaranteed to come with a proper implementation of bcrypt. All versions before 5.3.7 either don't support it at all, depend on the OS to support it, or have the wrong implementation. phpass won't help you; it just produces a weaker, "portable", md5-based hash, as it does in WordPress by default.
As a result, no open-source blog or forum program that needs to support PHP versions lower than 5.3.7 can use bcrypt by default. Since the world isn't going to abandon PHP any time soon, the only option is to force every web hosting company to upgrade PHP to 5.3.7 or higher.
I can't understand the superficiality in doing security-related activities (not being hacked of course, but the leakage of passwords because of md5+salt...).
Or better, I can understand that security is not priority 1 when one launches a new product, but there should be periodic reviews, similarly as reviews of the ux/ui, the branding/communication, the algorithms...
Someone should make a good post like: you can launch a website without x, y, z. When you reach 1k users, you need to implement x. At 10k you must have y. You can't think to 1M users without z.
MacRumors didn't design their own password storage scheme, they just used the popular VBulletin forum software. I don't think it makes sense to ask people to switch forum softwares when they reach a certain number of members.
It may or many not be VBulletin's fault that the site was hacked in the first place, but it's definitely VBulletin's fault that it uses md5 by default. Absolutely no excuses there, since supporting PHP 4.4 is not a valid excuse. The only fault of MacRumors operators that I can think of is that they used a vulnerable piece of software.
Unfortunately, forums aren't cool anymore, so few people write them anymore and it's difficult to find forum software that meets modern standards.
It's not the point who the fault is, it's that if MacRumors/VBulletin grows the amount of users, they (jointly, the former, the latter) need to take into account security.
So you are saying at a certain point they should security-audit the software they run on.
At what point does that mean the source of the PHP forum-software? At what point does that mean the source of PHP itself? On what point does that become the source of the operating system PHP runs on?
Add to this any other component involved which may or may not expose a security-risk, like MySQL, Email-servers, etc.
I think while your attitude may be the right one, your statement is overly simplistic.
Absolutely. However, even though a site can and should take steps to mitigate risks, that doesn't really excuse the vendor for shipping software that doesn't even attempt to adhere to security best practices in the first place. Especially in the world of PHP software (forums in particular - vBulletin/phpBB/IPB/etc.) where it's marketed pretty much as an all-in-one solution. Easy to setup, easy to manage, easy to grow. It's the software equivalent of "just add water."
But when you're marketing solutions like that to lay audiences, the onus is on you to at least try and account for the fact that most of your customers don't really have a clue what's going on. Especially at first, their customers are placing a great deal of trust in the software and the notion that the people behind it know what they're doing. What's a shame is that, if you've ever had the misfortune to dig into the source code for pretty much all of the PHP options out there, they really don't know what they're doing.
To call it a mess would be an understatement of epic proportions.
I wasn't being very precise there, but I meant security "best practices" -- common precautions and programming habits that most security experts agree are good for security. Some examples for apps written in PHP:
- bcrypt (at least 10 work factor) or PBKDF2 (at least 10K iterations of sha256) for password hashing.
- PDO and prepared statements for all DB queries. Don't let me find a single `mysql_query()` function call in your codebase, the mysql extension is deprecated anyway.
- Proper XSS filtering with HTMLPurifier or equivalent. BBCode and Markdown are not XSS filters, don't trust their regexps to keep you safe.
- Systematic protections against CSRF attacks. Don't do it manually. Don't trust plugin authors to get it right. Use a helper to insert a token to every form and every AJAX call. Validate the token automatically when submitted. No exceptions.
- Protections against arbitrary code execution via uploaded files (Never execute or `include` them!)
- Out-of-the-box compatibility with SSL (especially when generating absolute URLs), HTTP Strict Transport Security, set cookies with "secure" and "httponly" flags by default, etc.
- UTF-8 everything (primarily for convenience, but also helps protect against XSS and SQL injection using weird charsets)
Thanks for the answer, it makes very clear. Can I also ask how one learns about the latest best practices? I have come across many of these just by reading websites on the web.
Do most people learn these by reading books, reading about other people's mistakes or security blogs?
Unfortunately there is no single source that has all the best practices right. This is especially true of PHP, where too many tutorials are written for absolute beginners and not enough for advanced users. You just have to read a lot of stuff from many sources and stay tuned to the latest developments. (Avoid any PHP tutorial that is more than 3 years old. PHP development has really picked up in the last few years.)
phpbestpractices.org is definitely above average, but it seems light on security-related stuff. It's also getting a little long in the tooth in some parts. Possible modifications:
- Replace phpass with password_hash(), it has an even simpler interface.
- Don't close the ?> tag if possible. (Follow the PSR-0, PSR-1 and PSR-2 coding standards.)
- Use htmlspecialchars() instead of htmlentities()
- Know when not to use the resource-intensive DateTime class.
- Know that PHP 5.5 introduces a new opcode cache that isn't APC.
- This is down to personal preference, but I think SwiftMailer is more "modern" than PHPMailer and integrates better with third-party mailing APIs.
There's no excuse about priority. Even the random services I've occasionally scrapped together on a weekend use proper password storage. If I was storing so much user information, I'd sure as hell be doing it right.
Question: why half of the salt isn't hardcoded in the application code? That would make a database access completely useless without a deeper penetration, and it's really easy to implement.
A hardcoded second salt is called a pepper, and some programs use it. Unfortunately, with a popular and outdated PHP app like VBulletin, it won't be too difficult for an attacker to obtain both the DB dump and whatever configuration file that contains the pepper. All those PHP files just sit inside the document root, and everyone knows exactly where they are.
Public key cryptography. I want to generate a public/private key pair and upload the public key as my identity when I register for an account somewhere. Then there is nothing to steal on their end.
I want to say this is how websites authenticate themselves to users, but ssl certs serve a somewhat different purpose.
https://www.varnish-cache.org/docs/trunk/phk/http20.html may resonate with you. Generally a lot of people were critical of Paul's opposition to SPDY, but myself I think he makes some good and valid points especially regards identity.
I'd like my phone to ask for some pin or my fingerprint when I want to login something. No username, password or anything. Like bluetooth pairing, I'd pair my phone with services that I register and they could trigger my phone to ask my confirmation.
What's the difference between a pin and a password?
I think the solution is public key cryptography. See my other reply. However, I don't want my private keys stored on a computer or phone, since they can be stolen. I want to store they keys on a frob (USB key, wireless doodad, whatever) that signs messages with private keys but can't be accessed directly. This frob would be protected with a password or PIN of some kind. The frob should display the requested confirmation (Log into Hacker News as cottonseed? Yes/No) and require direct confirmation. This is, for example, the architecture people using for bitcoin hardware wallets, where the potential cost of failed security is very high.
I use Google Authenticator on iOS and Android. It's just a standards-compliant (RFC 6238) TOTP app, not anything Google specific. I've got six logins using it - gmail, Dropbox, Amazon (AWS), Github, Digital Ocean, and an internal service.
One thing that is a bit badly done - and I understand why - is making it easy to have "redundant duplicates". When setting up a new TOTP three factor auth account, I need to get my iPhone, iPad, and Android phone all together and manually type in the seeds (or QR code them) to all three to ensure I'm not completely screwed if I lose the only device with the magic tokens…
I'd love to have more of my important stuff secured with TFA/TOTP.
hash(pwd) -> attacker can build a rainbow table and password cracking becomes a table lookup. Required storage depends on the length of the hash value, and md5 is only 128 bits.
hash(salt|pwd) -> no rainbow table because of salt. The attacker can use a dictionary attack. Time depends on how fast she can compute the hash, and again md5 is pretty fast.
Rainbow tables are antiquated. A GPU can blast through many more hashes in a second than you get with pregenerated database. MacRumors passwords will fall incredibly quickly. The salt just means that the effort is proportional to the number of target hashes.
"Worse than", as in "six orders of magnitude worse than"
Hashcat on a single PC (with an appropriate video card) can test over 5 billion passwords/second, and salted MD5 passwords barely slow it down at all (the Joomla result below is for MD5(password + 32CharSalt)). The salt helps, because I can't just look the hash up in a rainbow table (or google for it), but you should expect any password to have ever been made public from any other exploit to be on somebody's wordlist and to fall in seconds to any attacker with a few hundred bucks worth of video card, and any combo of two or three dictionary words with or without obvious letter-number substitutions to fall in well under an hour.
With bcrypt, that comes down to under 4 thousand attempt per second. That makes password cracking one million times harder.
I see from another comment that vBulletin uses MD5(MD5(password)+salt) - I'd expect hashcat to be able to still blast through that at something north of 2 billion c/s…
That'll search the entire 32million entry list of Rockyou passwords in under a tenth of a second, and all 9-lower-case-letter passwords in an hour - or two hours if you include all 9char combinations with a single leading uppercase char. The rulesets that hashcat can use almost certainly means that any admin password which was human-created and under about 20 characters in that leak has already been cracked (anything made out of names or dictionary words with guessable letter/number/punctuation substitutions and leading/trailing digits - M1ffyTheC@t is not unguessable)
Modern password cracking is really quite sophisticated. They've taken to using words and phrases from common websites such as wikipedia in addition to ordinary words.
You really can't manage passwords in your head any more. At least not enough of them.
In my head I've got three banking passwords, two domain registrar passwords, and one "important email account password" (which is backed with TFA) that's the email that password resets get sent to - all are 16 random chars, and also two five word GPG passphrases. Those are _only_ in my head (well, one GPG passphrase is also in a sealed envelope in work's safe). Everything else is in 1Password locked behind a 7 word (intentionally misspelled) pass phrase – there are right now 866 sets of credentials in there - mostly 16 or 25 character (depending on when they were created/updated) random upper/lower/digits/special strings - with a few exceptions where sites/services won't let me use 25char passwords or sometimes prohibit "special characters" (Like your slow cryptographically secure hash function is susceptible to SQLi or XSS? That's why I can't use quotes or angle brackets? Really? Or are you actually incompetent?)
The 1Password file is synced between 4 machines in two physical locations plus 3 mobile devices, and time machine archived on one machine in both physical places - and one of those time machine archives is EncFS encrypted and stored on Dropbox and archived on S3 weekly, the other is daily rsynced to a pair of local drives. The passphrase isn't written down anywhere - but a hint which'd remind _me_ of the passphrase but would be innocuous/meaningless without sufficient context is written down and safely stored in two places. I _would_ be screwed without my 1Password data.
In my more paranoid moments, I wonder if both EncFS and 1Password's encryption is reliable enough to make leaking that file to Dropbox (which means S3/Amazon, which means the NSA if they're ever curious enough to ask Dropbox and/or Amazon for it). I also wonder about the attack vectors I've opened by having the 1Password file and app on two iOS devices - potentially leaking them to Apple and hence the NSA. But if the NSA ever come looking at _me_ specifically, I'm going to assume I've lost everything already. I don't _think_ any of that'll get caught up in dragnet surveillance though (except for when I get clients asking me to mail them hosting/admin/registrar credentials to their gmail or yahoo email addresses - facepalm )
(Actually, I also have my AppleID password "in my head" - since I need to type it in too many places where 1Password can't autofill it for me...)
md5/sha without hash is not really any better than md5/sha with hash. Rainbow Tables stopped being relevant around 2009-2010 with the advent of massively parallel GPU clusters.
>hash(salt|pwd) -> no rainbow table because of salt. The attacker can use a dictionary attack.
I'm having trouble understanding this. So what does the attacker do? He captured the encrypted passwords and he got all the salts.
What does he do now? Instead of generating a "normal" table by doing hash(<anyPWcomboThereIs>), he is now doing has(salt|<anyPWComboThereIs>)
Is that right? So basically, all that the salt does is to prolong the cracking. Say I had 10 users, so I would have 10 salts in my db. Without the salts, the attacker would have "just" had to calculate the hash(anyPWcomboThereIs) table. But now, he would have to do this 10 times because there are 10 different salts which could have been used to create the encrypted password.
It's a look up table operation vs. a per-item computation, essentially.
If you have passwords hashed using md5 and no salt then you just go get a giant pre-computed library of hashes and you go through each hash and figure out if it's in your library. This is EXTREMELY fast, and with modern computing power and memory/storage capacities these libraries can be huge and won't just include things like common passwords and dictionary words but also random strings of characters up to fairly long lengths. With this sort of attack you just filter the list of hashes through your table and you end up with a list of passwords.
The important thing about un-salted hashes is that no matter how much work is put into building the table it's amortized over the total number of passwords attacked, over all time. Which drastically lowers the amount of effort per password.
With a per-entry salt this sort of attack is no longer possible. Instead you are forced to do a brute force attack on each and every password. If, hypothetically, it took a week to generate a really good rainbow table then it would take essentially just one week to crack nearly 860,000 passwords. Whereas with unique salts it would take 860,000 weeks.
However, that's only in the hypothetical case. In practice many people have weak passwords, and a well-built system can compute a huge number of md5 hashes per second. Someone built a multi-GPU monster system that could compute 180 billion md5 hashes per second while only taking up about half of a standard server rack of space (5x 4U). So if you toss an extremely large dictionary of password guesses with even millions or tens of millions of entries it will still take only a fraction of a second to check each hash, so you can crack a significant number of passwords (at leas the ones that aren't incredibly strong) in only a matter of days.
Rainbow tables remove the need for doing hash(anyPwComboThereIs). They are huge hash->plaintext dictionaries where you just enter the hash and get the plaintext. If the website adds salt to the hashes, you need a rainbow table for every hash, which is practically unfeasible, so you have to revert to attempting to guess the password.
You don't even need to burn your own disk space for those lists. Try just feeding '5f4dcc3b5aa765d61d8327deb882cf99' into Google. Or 'f25a2fc72690b780b2a14e140ef6a9e0'. Or pretty much anything else that's ever showed up in a publicly leaks MD5 password dump (or plaintext password dump).
Any password that is likely to be duplicated will fall within 20 seconds to a brute force attack, as it is likely to be one of the first 7 trillion (yes, trillion) password that can be hashed in that amount of time. That's 70 terabytes worth of rainbow tables. Run it for 3 minutes and you've got 700 terabytes of rainbow tables. I don't think 700 terabyte rainbow tables exist.
Salts were critical from 1990s to around 2010, at which point they became mostly irrelevant for cracking accounts because of the increasingly parallel processing power that has exceeded the storage capacity of rainbow tables.
scrypt/bcrypt do the right thing, regardless, and generate unique password hash for the same plaintext, so if you use them you are covered both ways.
Bcrypt does use a salt to create unique hashes for the same plaintext, it's just that the function is written so that a random salt is created and stored for you, you don't have to provide a salt along with the plaintext.
Other implementations may not work quite this way.
Since I was compromised, I finally went through all my passwords and made them all unique with 1Password. I've had the app for a while but I never did a security audit for myself and bothered to update passwords. Definitely one of those must-have apps/services.
Don't know about 1Password, but LastPass encrypts all passwords client-side. Only marginally less safe than storing passwords in an encrypted file on your personal machine.
I can vouch for 1Password as well. Fantastic software, and they have numerous posts detailing their exact encryption techniques. Remember one really good password, and the rest of your passwords can all be completely random. You can sync it over wifi or Dropbox. I don't know the passwords to just about any websites now thanks to 1Password. We mandate it at our company now too. If you can tell me the password to "Important Website X" off the top of your head, you're doing it wrong.
<BTW: This goes without saying, but I'll say it anyway: Don't lose your 1 master password or your password database. ;) >
I use KeePass. It's great. I looked at LastPass but I didn't like that it is "Browser Based". I know it is supposed to be working "offline" but somehow I felt safer using KeePass where I can use the programs own UI, make sure the exe doesn't "phone home" and where I can directly see the encrpted db file and do with that as I please.
At first I worried about what would happen should the db file get corrupted somehow. But then I set up the backup tools with which I can keep as many backups in as many places as I want, so unless the db file gets corrupted in all places, I think I will be fine.
PHP 5.3.7 is the first version of PHP that is guaranteed to come with a proper implementation of bcrypt. All versions before 5.3.7 either don't support it at all, depend on the OS to support it, or have the wrong implementation. phpass won't help you; it just produces a weaker, "portable", md5-based hash, as it does in WordPress by default.
As a result, no open-source blog or forum program that needs to support PHP versions lower than 5.3.7 can use bcrypt by default. Since the world isn't going to abandon PHP any time soon, the only option is to force every web hosting company to upgrade PHP to 5.3.7 or higher.
[1] https://groups.google.com/forum/#!topic/php-fig/ogp03OHbVJ0