9 ms·

Why passwords have never been weaker—and crackers have never been stronger

115 points by e1ven 14y ago

jakeonthemove 14y ago
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...
- alanning 14y ago
  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.
  - robbiemitchell 14y ago
    If it doesn't work easily on a mobile device, it might as well not exist.
    - SoftwareMaven 14y ago
      Keepass has mobile applications that synchronize easily via webdav or Dropbox. Unfortunately, you can't create new records from the mobile device with Keepass (at least, with the app I'm using; there are others). My technique is to not create high-value accounts from my mobile and for low-value accounts, I'm OK with just using a semi-secure, temporary password that I update when I'm back in front of the desktop.
      - shiven 14y ago
        Unfortunately, you can't create new records from the mobile device with Keepass Perhaps pwSafe is the app you need? Works beautifully on iOS and syncs with Dropbox and/or iCloud too!
      - mock 14y ago
        https://play.google.com/store/apps/details?id=com.android.keepass&hl=en https://play.google.com/store/apps/details?id=com.android.ke... Works just fine with version 1.x files
- re_todd 14y ago
  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.
jayfuerstenberg 14y ago
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").
- sp4rki 14y ago
  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
casca 14y ago
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. TL;DR: make your passwords different.
- newman314 14y ago
  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.
  - casca 14y ago
    Lock-outs are tricky to manage. I can flood 50 login requests and have the legitimate user quickly locked out. CAPTCHAs can help but they're annoying and it's cheap to pay people to solve them if necessary. Forcing a CAPTCHA for a new IP address or when a "you-have-logged-on-from-this-browser-before" cookie added to a lock-out would definitely be an improvement.
    - olalonde 14y ago
      Paying people to read the CAPTCHAs would not help you much with a naive brute force attack. Assuming you can break 1 CAPTCHA/second, you could hypothetically try 86400 passwords/day. Breaking a 6 character password would then take you 52^6/86400 = 228826.5 days ~= 627 years. But I bet you'd run out of money earlier! Of course, it's a different story if the CAPTCHA can be OCRed.
jfb 14y ago
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.
- barrkel 14y ago
  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.)
  - jfb 14y ago
    This would be nice. Even better would be to do away with passwords entirely in favor of email + physical token. There's no getting away from the fact that crackers will always get access to a certain number of passwords; properly incentivizing people to pick excellent passwords seems like a fool's errand. Cue xkcd here. I hold out some hope that Apple (my computing vendor of choice) will roll 1Password-like functionality into the OS (both of them). Only a default-secure system will get the general public into a more secure state -- how long has the computer industry tried to strong-arm people into strong passwords, only to be defeated by 12password12 &c.? It's not that users are stupid, it's that the technology to secure computers is an utter failure.
    - egypturnash 14y ago
      Well, there's the Keychain. But its password generation is hidden deep in the program, not right there when you're asked to create one. And it doesn't synch to anything, not even iOS devices, so it's pretty much useless for generating passwords that are, say, 2k of line noise. It would be totally awesome if Apple acquihired 1PW or LastPass or somesuch, and set things up so that it's always right three, helpfully offering a new super-entropic password whenever you're joining a new site.
barrkel 14y ago
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.
- rapind 14y ago
  http://passwordmaker.org/ http://passwordmaker.org/ 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...
  - uvdiv 14y ago
tedunangst 14y ago
"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...
- olalonde 14y ago
  I think it took him several months of figuring out the right technique to crack the password (it's not the actual computation time).
- tlb 14y ago
  26 million squared is 676 trillion, which would take about a day at 8 billion / sec.
  - tedunangst 14y ago
    nice catch.
Wingman4l7 14y ago
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. * (what you have, what you are, what you know)
- Wingman4l7 14y ago
  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.
- mckoss 14y ago
  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.
- jm3 14y ago
  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).
- K2h 14y ago
  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' [1] http://helpdesk.lastpass.com/security-options/ http://helpdesk.lastpass.com/security-options/ [2] http://helpdesk.lastpass.com/security-options/grid-multifactor-authentication/ http://helpdesk.lastpass.com/security-options/grid-multifact...
  - 14y ago
ethereal 14y ago
From the article: > 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 14y ago
  The LM hash hasn't been stored by default for years now: http://en.wikipedia.org/wiki/LM_hash http://en.wikipedia.org/wiki/LM_hash. 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.
mckoss 14y ago
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.
- damncabbage 14y ago
  I lost my private key. Now what? 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 14y ago
    I believe, in an ideal world you'd have your private key stored safely on a private webserver, or maybe your mobile phone.
    - rjzzleep 14y ago
      you mean the mobile phone who's data can be accessed remotely by apple, google, htc and god knows who else?
    - greyboy 14y ago
      In an ideal world, we wouldn't need to worry about unauthorized access. Unfortunately, that world doesn't exist. But I sincerely hope a requirement for me to use the internet doesn't demand we have a private server instance or a smartphone of any variety (my Nokia candy bar variant serves me just fine). I can think of many problems we'd need to account for (lack of internet, dead/lost phone, corruption, older folks, etc).
      - sigkill 14y ago
        You know, sometimes the simplest problems are the hardest to solve. You'd think right? "What's the best way to know if this guy is who he is claiming to be?" 1. Shared secret/Password - He tells me something during registration and then I use that information to verify if he's saying the same thing when he want access the site. 2. PKI - Describes itself. 3. Something he claimed to have during sign-up, so let me check if he has it now. The problem is, every system is going to have a point of failure/point of absolute control. This is because, you want someone to be able to reset their password/public key/auth token if they forget/misplace/get stolen. Sure, things would be a lot easier if you left the liability on the user, by explicitly stating that if Acts of God (legal term) happen to him, you are not liable. But in this day and age where I see every service tending towards dummifying and hand-holding, I don't see this approach being popular at all. In the above approach, by pushing all liability onto the user, you tell him that HE and ONLY HE is responsible towards the safe storage of his credential. It's not like in real-life, people can't come up with a gun pointed at you and tell you to give up your auth token, assuming they MitM'ed your password.
egypturnash 14y ago
More and more I feel like passwords are a fundamentally broken system. We need a better system of locks and keys. 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 14y ago
  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.
gghootch 14y ago
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?
- sesqu 14y ago
  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.
yummyfajitas 14y ago
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.)
- adrianhoward 14y ago
  Add a new bcrypted password column. 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 :)
  - yummyfajitas 14y ago
    As I said: "I'd also replace the `bcrypt . md5` password with a regular bcrypt one after the user authenticates." The question is what to do to protect passwords starting today?
    - adrianhoward 14y ago
      Apologies. I'm an idiot who can't read a question :-) bcrypting the md5s sounds like a good approach.
- CJefferson 14y ago
  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.
TomGullen 14y ago
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.
- gizmo686 14y ago
  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.
mwww 14y ago
This is why websites should start to adopt solutions like Rublon (www.rublon.com). 7 reasons why you should add Rublon to your website http://blog.rublon.com/2012/why-add-rublon/ 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.
rogcg 14y ago
"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."

115 points by e1ven 14y ago

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...

alanning 14y ago
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.
- robbiemitchell 14y ago
  If it doesn't work easily on a mobile device, it might as well not exist.
  - SoftwareMaven 14y ago
    Keepass has mobile applications that synchronize easily via webdav or Dropbox. Unfortunately, you can't create new records from the mobile device with Keepass (at least, with the app I'm using; there are others). My technique is to not create high-value accounts from my mobile and for low-value accounts, I'm OK with just using a semi-secure, temporary password that I update when I'm back in front of the desktop.
    - shiven 14y ago
      Unfortunately, you can't create new records from the mobile device with Keepass Perhaps pwSafe is the app you need? Works beautifully on iOS and syncs with Dropbox and/or iCloud too!
    - mock 14y ago
      https://play.google.com/store/apps/details?id=com.android.keepass&hl=en https://play.google.com/store/apps/details?id=com.android.ke... Works just fine with version 1.x files
re_todd 14y ago
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.

jayfuerstenberg 14y ago

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").

sp4rki 14y ago
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

casca 14y ago

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. TL;DR: make your passwords different.

newman314 14y ago
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.
- casca 14y ago
  Lock-outs are tricky to manage. I can flood 50 login requests and have the legitimate user quickly locked out. CAPTCHAs can help but they're annoying and it's cheap to pay people to solve them if necessary. Forcing a CAPTCHA for a new IP address or when a "you-have-logged-on-from-this-browser-before" cookie added to a lock-out would definitely be an improvement.
  - olalonde 14y ago
    Paying people to read the CAPTCHAs would not help you much with a naive brute force attack. Assuming you can break 1 CAPTCHA/second, you could hypothetically try 86400 passwords/day. Breaking a 6 character password would then take you 52^6/86400 = 228826.5 days ~= 627 years. But I bet you'd run out of money earlier! Of course, it's a different story if the CAPTCHA can be OCRed.

jfb 14y ago

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.

barrkel 14y ago
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.)
- jfb 14y ago
  This would be nice. Even better would be to do away with passwords entirely in favor of email + physical token. There's no getting away from the fact that crackers will always get access to a certain number of passwords; properly incentivizing people to pick excellent passwords seems like a fool's errand. Cue xkcd here. I hold out some hope that Apple (my computing vendor of choice) will roll 1Password-like functionality into the OS (both of them). Only a default-secure system will get the general public into a more secure state -- how long has the computer industry tried to strong-arm people into strong passwords, only to be defeated by 12password12 &c.? It's not that users are stupid, it's that the technology to secure computers is an utter failure.
  - egypturnash 14y ago
    Well, there's the Keychain. But its password generation is hidden deep in the program, not right there when you're asked to create one. And it doesn't synch to anything, not even iOS devices, so it's pretty much useless for generating passwords that are, say, 2k of line noise. It would be totally awesome if Apple acquihired 1PW or LastPass or somesuch, and set things up so that it's always right three, helpfully offering a new super-entropic password whenever you're joining a new site.

barrkel 14y ago

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.

rapind 14y ago
http://passwordmaker.org/ http://passwordmaker.org/ 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...
- uvdiv 14y ago

tedunangst 14y ago

"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...

olalonde 14y ago
I think it took him several months of figuring out the right technique to crack the password (it's not the actual computation time).
tlb 14y ago
26 million squared is 676 trillion, which would take about a day at 8 billion / sec.
- tedunangst 14y ago
  nice catch.

Wingman4l7 14y ago

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. * (what you have, what you are, what you know)

Wingman4l7 14y ago
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.
mckoss 14y ago
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.
jm3 14y ago
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).
K2h 14y ago
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' [1] http://helpdesk.lastpass.com/security-options/ http://helpdesk.lastpass.com/security-options/ [2] http://helpdesk.lastpass.com/security-options/grid-multifactor-authentication/ http://helpdesk.lastpass.com/security-options/grid-multifact...
- 14y ago

ethereal 14y ago

From the article: > 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 14y ago
The LM hash hasn't been stored by default for years now: http://en.wikipedia.org/wiki/LM_hash http://en.wikipedia.org/wiki/LM_hash. 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.

mckoss 14y ago

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.

damncabbage 14y ago
I lost my private key. Now what? 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 14y ago
  I believe, in an ideal world you'd have your private key stored safely on a private webserver, or maybe your mobile phone.
  - rjzzleep 14y ago
    you mean the mobile phone who's data can be accessed remotely by apple, google, htc and god knows who else?
  - greyboy 14y ago
    In an ideal world, we wouldn't need to worry about unauthorized access. Unfortunately, that world doesn't exist. But I sincerely hope a requirement for me to use the internet doesn't demand we have a private server instance or a smartphone of any variety (my Nokia candy bar variant serves me just fine). I can think of many problems we'd need to account for (lack of internet, dead/lost phone, corruption, older folks, etc).
    - sigkill 14y ago
      You know, sometimes the simplest problems are the hardest to solve. You'd think right? "What's the best way to know if this guy is who he is claiming to be?" 1. Shared secret/Password - He tells me something during registration and then I use that information to verify if he's saying the same thing when he want access the site. 2. PKI - Describes itself. 3. Something he claimed to have during sign-up, so let me check if he has it now. The problem is, every system is going to have a point of failure/point of absolute control. This is because, you want someone to be able to reset their password/public key/auth token if they forget/misplace/get stolen. Sure, things would be a lot easier if you left the liability on the user, by explicitly stating that if Acts of God (legal term) happen to him, you are not liable. But in this day and age where I see every service tending towards dummifying and hand-holding, I don't see this approach being popular at all. In the above approach, by pushing all liability onto the user, you tell him that HE and ONLY HE is responsible towards the safe storage of his credential. It's not like in real-life, people can't come up with a gun pointed at you and tell you to give up your auth token, assuming they MitM'ed your password.

egypturnash 14y ago

More and more I feel like passwords are a fundamentally broken system. We need a better system of locks and keys. 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 14y ago
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.

gghootch 14y ago

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?

sesqu 14y ago
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.

yummyfajitas 14y ago

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.)

adrianhoward 14y ago
Add a new bcrypted password column. 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 :)
- yummyfajitas 14y ago
  As I said: "I'd also replace the `bcrypt . md5` password with a regular bcrypt one after the user authenticates." The question is what to do to protect passwords starting today?
  - adrianhoward 14y ago
    Apologies. I'm an idiot who can't read a question :-) bcrypting the md5s sounds like a good approach.
CJefferson 14y ago
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.

TomGullen 14y ago

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.

gizmo686 14y ago
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.

mwww 14y ago

This is why websites should start to adopt solutions like Rublon (www.rublon.com). 7 reasons why you should add Rublon to your website http://blog.rublon.com/2012/why-add-rublon/ 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.

rogcg 14y ago

"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."