The question about password strength is meaningless without looking at the attack. A 4-digit PIN with a 3 attempt lock-out (and no further information) is more secure than a 10 character password encrypted with MD5.
There will be people who say that it would all be fine if they just used bcrypt, but the fundamental problem is that if you don't use different passwords on every site, you're hugely at risk.
Consider a situation where you've given your "trusted" password to a site that you know does all the right hashing with password storage. Your super password is 20 characters of alphanums with specials and you're feeling pretty smug. You now hear that the site was hacked, but you're not worried as all they can get is the hash and let them just try brute-force, right?
Wrong. They hacked the site. They changed the login form and grabbed your password in plaintext. A hack means that they compromise part of the infrastructure. At this time it's sufficient to just grab database data. Changing presented HTML is possibly a little harder as it needs to stay up for longer, but if someone has access to the database, they probably have access to a whole lot more. This is why lastpass.com is less secure than storing your password database yourself.
A 4-digit pin with lockout and an MD5 hash are equally insecure in different ways. The lockout scares me when we acknowledge anyone can be social-engineered into giving up any credential, and anyone can forget a credential no matter how simple.
But yeah, at the end of the day, someone who spends a lot of time making cryptographically secure passwords and rotates them every six months is probably less secure on the balance than someone who uses 4-digit pins they rotate every three months.
This. I'm surprised more sites don't utilize a lockout. Even with a 10 or 50 attempt lockout (for a website not PIN) is still better than giving an attacker unlimited attempts.
Here's my crazy crackpot theory for solving the password problem.
Users should have a handful of passwords, in the old security-level style; everyday sites use a short simple password, email a level up, banking a level up again.
But the passwords should not be entered directly into sites. Instead, they should be hashed by a browser feature / plugin, roughly equivalent to bcrypt(password + user-specific-salt + site DNS name). The output of this process is what gets provided to sites. Not all sites will accept the full entropy of bcrypt or similar, so there needs to be a central registry tracking acceptable mappings from the output of bcrypt to the input of a site's password. There's also an issue around sites that share accounts across different top-level DNS names - Amazon in particular - that can also be handled by the same central registry technique.
This way, there is no list of passwords to worry about backing up, losing or handing over to third parties - everyone should be able to remember two or three passwords. There is no Javascript vulnerability like you see with bookmarklets for things like SuperGenPass. Every website sees a unique and specific password, even if the same underlying password is used by different people.
The only thing you need to worry about is your browser getting completely owned, so that the memory space of its extension mechanism is accessed by remote websites. But if the attacker has that level of control, it's not unreasonable to think he has control over a third party password manager too.
What it doesn't do well is revocation and renewal of a password. It also has a single point of failure - if someone somehow gets access to your underlying password, and knows the mechanism and salt, they can open a whole lot of boxes. This, of course, is why I'm a crackpot: I can live with that.
But you still need to realize that this won't last forever. You can crack an application's hashing algo (and know what hash or field they're using for the salt) because 50% of its users picked crappy passwords. Then if you're really dedicated you can work on the double hashed passwords, knowing that most people use the domain as the salt for browser-side hashing... Also a pre-hashed password has to be pretty easy to spot in a list once you've cracked the server-hash.
"he recovered a 13-character password that he had spent several months trying to crack." -> "The technique is simple enough to do, although it increases the number of required guesses dramatically—from about 26 million, assuming the dictionary Redman uses most often, to about 676 million." -> "8.2 billion Average passwords combinations per second able to be tried by a PC running a single AMD Radeon HD7970 GPU."
Do the math. 676 million should have taken less than a tenth of a second. Unless some rather major details are missing...
> An updated version of LAN Manager known as NTLM was introduced with Windows NT 3.1. It lowered the susceptibility of Windows passwords to rainbow table attacks, but didn't eliminate the risk. To this day, the authentication system still doesn't apply cryptographic "salt" to passwords to render such attacks infeasible.
Is this true? Do WinNT-derived systems _still_ not use password salting? If that is the case, my opinion of Windows's security just dropped quite a bit. I know security can exist without salting, and I've not done any in-depth Windows development, but from experience w/backend dev and Linux dev it seems like it'd be pretty cheap to add . . .
The problem wasn't the difficulty of adding a better hash algorithm. The lousy hash was kept around to maintain compatibility with network clients that didn't support the new algorithms.
The gist of the article is sites ought to be using BCrypt for hashing passwords and users should be using password manager apps for storing strong passwords (not "password123").
Being the second in command of a development team I made the decision to change ALL our authentication to bcrypt a week into the job overnight (luckily we where storing password encrypted in way I could retrieve all the passwords), had to hack into the database server though. The result was an angry customer service department, and the realization that our security was complete shit. I also ended up working with the IT guys to secure our networks. The real result is that now we don't get huge security meltdowns every couple of months. I got a bonus for the initiative... Oh and the customer service guys still hate me :D
The more I read about this, the more I think that 2-factor authentication is the future, whether it's using robocalls / texted codes sent to mobile phones, or just a security token. It's easier to just add one of the 3 types of authentication* to the mix rather than wrapping yet another layer of complexity around a single one of them.
I have been reading the list of 2 factor at lastpass [1] and in addition to mentioning the yubikey, it talks about the grid multifactor [2] - probably about on par with what was used in WW2 but it seems extremely simple, low tech solution to multifactor that doesn't require computers, phones or electronics - solving that problem of 'something you know' + 'something you have'
Duo Security, from some of the Open{BSD,SSH} guys, offers a nice two-factor auth layer that's pluggable into any web or online service; push notifications, SMS, or voice. Similar to Google Authenticator except that Duo isn't limited to Google supported services (although they did take an investment from Google Ventures).
I hope not. Two-factor auth ties you down to a cellphone (or physical token) while giving you only marginal improvement in real-life usage scenarios. (You are not going to enter a new token every time you check your email or Facebook.) We have higher-level problems with authentication that need to be solved.
As far as personal security tokens go, I recently came across the YubiKey, which provides 2-factor auth using OTPs. It looks very promising, but I haven't used it myself, so I can't provide any anecdata on it.
Google authenticator is great; can be used on many sites (gmail, last pass, aws) and is based on an open standard that is to implement on your own servers.
I m in favor of things like browserid, provide a centralized point of failure. It's futile to assume that because people can have different passwords they will have them. Most people use 1-3 passwords, and it sucks whenever you have to learn a new one.
Hypothetical question - say I'm an idiot and I already have a database full of md5-hashed passwords. What do I do now?
The best I've been able to come up with is bcrypting the md5's. But unfortunately, while bcrypt^-1(ALL STRINGS) is hard to compute, it's not clear that bcrypt^-1(range(md5)) is. I see no compelling reason why it wouldn't be, but I don't know enough about the subject to offer a strong claim.
Can any experts offer advice on this?
(I'd also replace the `bcrypt . md5` password with a regular bcrypt one after the user authenticates.)
Since MD5 hashes and bcrypt hashes are recognisably different: when the user next successfully logs in, check if they have an MD5 hash; if they do, use the password they just submitted (that you know is correct) to generate a bcrypt hash and then update your password database with that.
If you have a large number of inactive users, this might not be as effective (you'll still be left with lots of MD5 hashes in the event of a dump) but for other sites it can be quite useful.
You can also use the same strategy to increase the work rate of your bcrypt hashes in the future.
I guess you could run bcrypt on all your database's md5 hashes and do something like:
if entered_password.md5.bcrypt == stored_password:
stored_password = entered_password.bcrypt
login()
That way, you will only have to store the bcrypted md5 hashes, until the next time someone tries to log on - assuming that's the kind of back-end you have.
If inverting bcrypt(md5(.)) was easy then you'd have a preimage attack on md5: given your value md5(x), compute a bcrypt digest of that and attack that instead. (Which is not exactly the same as inverting bcrypt(md5(.)) given a dictionary of likely inputs, though.)
Anyway, if there's any input set X for which bcrypt(X) can be inverted more efficiently than brute force, then you could say that bcrypt is flawed. If that set is the random-looking hashes of user passwords, instead of a carefully constructed one designed to attack bcrypt, then you can safely say bcrypt is catastrophically broken.
bcrypting your md5 hashes is much better than having the md5 hashes around for various reasons. The major reason is that there are many md5 rainbow tables, and if your md5 hashes ever leak out, a huge number of your passwords will be known almost immediately. bcrypt+md5 rainbow tables are much less common.
If you can, also add a user-specific salt (username is the obvious choice).
In theory cracking bcrypt+md5 is easier than plain bcrypt, because users could have passwords with greater than 128 bits of entropy. However, the vast majority of users won't, and generating a 128-bit rainbow table isn't practical.
"The whole password-cracking scene has changed drastically. In the last couple years. You can look online and you
can generally find passwords for just about everyone at
some point. I've found my own username and passwords on
several different sites. If you think every single website
you have an account on is secure and has never been hacked,
you're a much more optimistic person than I am."
This guy is realistic. And he is right. I started revoking access for my google account from a lot of websites.
BTW I've seen a blog post that a guy was able to access his stackoverflow account by getting the session cookies (which was very easy, the parameter names, etc) just by using a cookie chrome extension.
This guy is totally right.
"If you think every single website
you have an account on is secure and has never been hacked,
you're a much more optimistic person than I am."
This reminds me: I need to go through my 1Password DB and change all the passwords. This is a PITA but I only do it quarterly, and 1Password syncs nicely to my phone and iPad, so it's not the end of the world.
It would be a huge help if there was a standardized web API for changing passwords on a site. I don't know how many sites you need to change passwords for; I've got several hundred, all unique, and I certainly don't change them quarterly.
(It would also help attackers, of course - they could instantly lock owners out of whole heaps of accounts once they got a password that got reused. On balance, though, I think the benefits would be positive, since a motivated hacker can already lock people out of high-value accounts, and the drudgery factor of changing passwords regularly is very high.)
I'm the inventor of this technology. Sorry if this looks like advertising, but I think that the problem with passwords nowadays is huge nowadays and has to be solved. BTW: We're releasing a new Android app in a few hours.
The real solution is to switch to public keys. No more shared secrets - you just prove your identity by using your private key to sign an authentication challenge.
I like this idea. But as a novice, how would you, say sign in to gmail? Would you download a file, sign it, and upload it again? That seems quite time consuming as compared to current day password.
I'd really wish some sites would not force me to change the password every other month or every time I clear my cookies or use a different IP: every time, I have to use a simpler password because I just can't come up with a better one without having to write it down somewhere...
3-5 tries with a half hour lockout with an email alert seems like a good solution to me...
I don't write down passwords, I write down password hints. For example, "b + 7 + z" could equal baby753zyxw. A single letter can signify a word/string, and a single number can signify a larger number. I have about 20 strings memorized than I combine in various ways.
Definitely annoying to have to reset pw frequently but the shorter passwords part can be avoided by using a secure pw db like keepass (keepassX on Mac). Storing the db file on dropbox makes it very convenient. Throwaway pw aside, you really only need to remember 3 pws: db, dropbox, and main email (for convenience). I have many passwords I've never even seen thanks to keepassX.
The article talks about brute forcing hashes. This is why a good login system will rehash the password multiple times to exponentially increase the length of time it would take to brute force the passwords.
Accounts could still be cherry picked but it would stop blanket brute forces. This is why BCrypt is good.
How does re-hashing exponentially increase the amount of time brute forcing takes. The time it takes to do N iterations of a hash is N times as long as 1 iteration, so the amount of time it takes to make M guesses is still just N times as long.
Why aren't security experts and hackers mixing and matching the characters that make up the password? I.e. instead of super!!!think3rs, try Supr3Think0rz. Is the added required processing too large of a trade off?
I don't know what the best practices are, but some crackers definitely do do that. And yes, the added processing is generally too large for non-cracking applications.
[+] [-] casca|13 years ago|reply
There will be people who say that it would all be fine if they just used bcrypt, but the fundamental problem is that if you don't use different passwords on every site, you're hugely at risk.
Consider a situation where you've given your "trusted" password to a site that you know does all the right hashing with password storage. Your super password is 20 characters of alphanums with specials and you're feeling pretty smug. You now hear that the site was hacked, but you're not worried as all they can get is the hash and let them just try brute-force, right?
Wrong. They hacked the site. They changed the login form and grabbed your password in plaintext. A hack means that they compromise part of the infrastructure. At this time it's sufficient to just grab database data. Changing presented HTML is possibly a little harder as it needs to stay up for longer, but if someone has access to the database, they probably have access to a whole lot more. This is why lastpass.com is less secure than storing your password database yourself.
TL;DR: make your passwords different.
[+] [-] lukeschlather|13 years ago|reply
But yeah, at the end of the day, someone who spends a lot of time making cryptographically secure passwords and rotates them every six months is probably less secure on the balance than someone who uses 4-digit pins they rotate every three months.
[+] [-] newman314|13 years ago|reply
[+] [-] barrkel|13 years ago|reply
Users should have a handful of passwords, in the old security-level style; everyday sites use a short simple password, email a level up, banking a level up again.
But the passwords should not be entered directly into sites. Instead, they should be hashed by a browser feature / plugin, roughly equivalent to bcrypt(password + user-specific-salt + site DNS name). The output of this process is what gets provided to sites. Not all sites will accept the full entropy of bcrypt or similar, so there needs to be a central registry tracking acceptable mappings from the output of bcrypt to the input of a site's password. There's also an issue around sites that share accounts across different top-level DNS names - Amazon in particular - that can also be handled by the same central registry technique.
This way, there is no list of passwords to worry about backing up, losing or handing over to third parties - everyone should be able to remember two or three passwords. There is no Javascript vulnerability like you see with bookmarklets for things like SuperGenPass. Every website sees a unique and specific password, even if the same underlying password is used by different people.
The only thing you need to worry about is your browser getting completely owned, so that the memory space of its extension mechanism is accessed by remote websites. But if the attacker has that level of control, it's not unreasonable to think he has control over a third party password manager too.
What it doesn't do well is revocation and renewal of a password. It also has a single point of failure - if someone somehow gets access to your underlying password, and knows the mechanism and salt, they can open a whole lot of boxes. This, of course, is why I'm a crackpot: I can live with that.
[+] [-] rapind|13 years ago|reply
But you still need to realize that this won't last forever. You can crack an application's hashing algo (and know what hash or field they're using for the salt) because 50% of its users picked crappy passwords. Then if you're really dedicated you can work on the double hashed passwords, knowing that most people use the domain as the salt for browser-side hashing... Also a pre-hashed password has to be pretty easy to spot in a list once you've cracked the server-hash.
Scary stuff...
[+] [-] cypherpunks01|13 years ago|reply
https://www.pwdhash.com/
[+] [-] tedunangst|13 years ago|reply
Do the math. 676 million should have taken less than a tenth of a second. Unless some rather major details are missing...
[+] [-] tlb|13 years ago|reply
[+] [-] olalonde|13 years ago|reply
[+] [-] ethereal|13 years ago|reply
> An updated version of LAN Manager known as NTLM was introduced with Windows NT 3.1. It lowered the susceptibility of Windows passwords to rainbow table attacks, but didn't eliminate the risk. To this day, the authentication system still doesn't apply cryptographic "salt" to passwords to render such attacks infeasible.
Is this true? Do WinNT-derived systems _still_ not use password salting? If that is the case, my opinion of Windows's security just dropped quite a bit. I know security can exist without salting, and I've not done any in-depth Windows development, but from experience w/backend dev and Linux dev it seems like it'd be pretty cheap to add . . .
[+] [-] courage|13 years ago|reply
The problem wasn't the difficulty of adding a better hash algorithm. The lousy hash was kept around to maintain compatibility with network clients that didn't support the new algorithms.
[+] [-] jayfuerstenberg|13 years ago|reply
[+] [-] sp4rki|13 years ago|reply
[+] [-] Wingman4l7|13 years ago|reply
* (what you have, what you are, what you know)
[+] [-] K2h|13 years ago|reply
[1] http://helpdesk.lastpass.com/security-options/
[2] http://helpdesk.lastpass.com/security-options/grid-multifact...
[+] [-] jm3|13 years ago|reply
[+] [-] romaniv|13 years ago|reply
[+] [-] Wingman4l7|13 years ago|reply
[+] [-] mckoss|13 years ago|reply
[+] [-] egypturnash|13 years ago|reply
What is is, I don't know. I just know that it's not "passwords".
Especially when there are still sites that limit you to like 8 characters out of a highly restricted set. Usually of course these are banks.
[+] [-] zerostar07|13 years ago|reply
[+] [-] yummyfajitas|13 years ago|reply
The best I've been able to come up with is bcrypting the md5's. But unfortunately, while bcrypt^-1(ALL STRINGS) is hard to compute, it's not clear that bcrypt^-1(range(md5)) is. I see no compelling reason why it wouldn't be, but I don't know enough about the subject to offer a strong claim.
Can any experts offer advice on this?
(I'd also replace the `bcrypt . md5` password with a regular bcrypt one after the user authenticates.)
[+] [-] robmil|13 years ago|reply
If you have a large number of inactive users, this might not be as effective (you'll still be left with lots of MD5 hashes in the event of a dump) but for other sites it can be quite useful.
You can also use the same strategy to increase the work rate of your bcrypt hashes in the future.
[+] [-] kmfrk|13 years ago|reply
Someone asked a question similar to yours a while ago. Maybe the answers may be of help: http://news.ycombinator.com/item?id=4076257.
I guess you could run bcrypt on all your database's md5 hashes and do something like:
That way, you will only have to store the bcrypted md5 hashes, until the next time someone tries to log on - assuming that's the kind of back-end you have.[+] [-] shrughes|13 years ago|reply
Anyway, if there's any input set X for which bcrypt(X) can be inverted more efficiently than brute force, then you could say that bcrypt is flawed. If that set is the random-looking hashes of user passwords, instead of a carefully constructed one designed to attack bcrypt, then you can safely say bcrypt is catastrophically broken.
[+] [-] adrianhoward|13 years ago|reply
Alter authentication so that it uses bcrypt column if populated.
Alter registration/password changes so that it populates bcrypt by default.
As old users log in (and you therefore have access to their plain text password and know that it's valid) populate the bcrypt with the correct hash.
After a period of N weeks when you've basically migrated all of your active users, do a forced password reset on the rest.
Kill the MD5 column.
Done :)
[+] [-] CJefferson|13 years ago|reply
If you can, also add a user-specific salt (username is the obvious choice).
In theory cracking bcrypt+md5 is easier than plain bcrypt, because users could have passwords with greater than 128 bits of entropy. However, the vast majority of users won't, and generating a 128-bit rainbow table isn't practical.
[+] [-] rogcg|13 years ago|reply
This guy is realistic. And he is right. I started revoking access for my google account from a lot of websites.
BTW I've seen a blog post that a guy was able to access his stackoverflow account by getting the session cookies (which was very easy, the parameter names, etc) just by using a cookie chrome extension.
This guy is totally right.
"If you think every single website you have an account on is secure and has never been hacked, you're a much more optimistic person than I am."
[+] [-] jfb|13 years ago|reply
[+] [-] barrkel|13 years ago|reply
(It would also help attackers, of course - they could instantly lock owners out of whole heaps of accounts once they got a password that got reused. On balance, though, I think the benefits would be positive, since a motivated hacker can already lock people out of high-value accounts, and the drudgery factor of changing passwords regularly is very high.)
[+] [-] mwww|13 years ago|reply
7 reasons why you should add Rublon to your website http://blog.rublon.com/2012/why-add-rublon/
I'm the inventor of this technology. Sorry if this looks like advertising, but I think that the problem with passwords nowadays is huge nowadays and has to be solved. BTW: We're releasing a new Android app in a few hours.
[+] [-] mckoss|13 years ago|reply
[+] [-] damncabbage|13 years ago|reply
I'm using my friend's laptop; I don't have my private key with me. Now what?
I'm travelling and forgot to bring my private key with me. Now what?
(Similar questions apply to password managers as well, but I'm curious as to what the problems/solutions are for PKI.)
[+] [-] sigkill|13 years ago|reply
[+] [-] jakeonthemove|13 years ago|reply
3-5 tries with a half hour lockout with an email alert seems like a good solution to me...
[+] [-] re_todd|13 years ago|reply
[+] [-] alanning|13 years ago|reply
[+] [-] TomGullen|13 years ago|reply
Accounts could still be cherry picked but it would stop blanket brute forces. This is why BCrypt is good.
[+] [-] gizmo686|13 years ago|reply
[+] [-] gghootch|13 years ago|reply
[+] [-] sesqu|13 years ago|reply