Hacker News Reader

Comment by benmmurphy | Hacker News Reader

It means passwords like dadada can be reversed from hashes.

It's not exactly happening in a vacuum. Emails and usernames from previous dumps help people figure out passwords for new accounts when many people are reusing the same silly password everywhere.

For example someone else may have had dadada as a password and isuckat@passwords.com as their email, and their password was discovered via a separate breach on some other site. That other site used shit technology for securing people's passwords. isuckat@passwords.com was in the linkedin dump.

People can probably guess that any hash for isuckat@passwords.com will probably be 'dadada'. Now based on this information figuring out the hash for other users also using 'dadada' as their password is simpler. Multiply by many thousands of people reusing the same stupid password on all their sites.

In other words use a unique password and use a different unique password for each site and service you use. Use a password manager.

It bothered me more than it should have that you used isuckat@passwords.com instead of isuck@passwords.com for your example :)

Oh god. I'm so sorry. :(

Not if it's salted, no?

It wasn't salted, but even then a targeted effort could almost certainly crack a password as bad as dadada almost immediately for a fast hash like sha1.

That's what I find hard to believe though. LinkedIn, a $20B giant, doesn't salt its passwords and uses something as weak as sha1? I would expect even a 1-person startup to do better than that.

That doesn't need to be true for this to have happened. Zuck is a high profile target, probably the hackers just prioritised cracking his account and such a weak password would be found reasonably quickly even using bcrypt

Can you prevent targeted attacks, or is salting the state of the art?

What if the salt was derived from a key the user had to supply and wasn't stored anywhere?

> What if the salt was derived from a key the user had to supply and wasn't stored anywhere?

If I understood you that is the same as demanding the user to input two strings for password authentication, one for salt and one for password, in which case you might just as well require the user to use a longer password.

Good point. Why do we have passwords anyway? Just to authenticate at unanticipated access points? We could always just do two-factor authentication for that. A code would be sent to Google Authenticator on your phone or something like that, encrypted with your public key, and you'd just decrypt it with your private key. The phone would be secured with your password or fingerprint, which is never sent anywhere. The code would allow you to auth with the new access point. If the cellphone was connected to the internet, it could send the key directly and the site would log you in. If not connected to the net, it could use bluetooth or optical or sound to communicate with the access point (eg web browser running on a computer) to send the code. Only in the worst case would you have to type anything in yourself.

Since most people walk around with their cellphones, you could even precompute a couple keys to unlock a site, for those times when there is no internet connection. Of course, your phone should be secured with a password and you should be able to revoke the keys if anything gets lost.

We use passwords both to authenticate (assert identity) and to authorize (declare intent). The problem with automated logins is that you cannot infer intent (i.e. you have no assurance that the user actually meant to log in to your service).

Because usernames and passwords can be implemented without reliance on 3rd party infrastructure and they are culturally accepted and understood - however poorly - by everyone. We're still using 80 character lines in programming because of IBM punch card design from 1928. Similarly, I doubt the password will completely go away within our grandchildren's lifetimes. That said, our mobile devices are likely to play an increasing role in authentication for everyday activities.

Google authenticator is only one-factor, possession of the shared secret in the phone. That's why it requires 'two-steps'.

Well, the password on the phone is the other factor. No need to send the password anywhere.

You can hash something like password+email+salt. If they don't know the email or salt it makes it hard to crack and even if they do it slows things down as they have to crack each password individually rather than making a rainbow table. Also using a slower hash like bcrypt rather than sha1 helps slow things down.

Salting has zero effect on the targeted cracking of a single password. Salting protects against rainbow tables - sets of pre-calculated hashes plain-text to passwords. These are dangerous because an attacker has a large amount of time to pre-calculate hashes, but (hopefully) only a small amount of time to calculate after a dump before the password is changed. However, if you are starting from scratch and have a single password to crack, there's no difference between a salted and unsalted password.

Modern state of the art for targeted attacks is to use slow hash algorithms, such as bcrypt. They have little effect on normal operations, as most users will get the right password within a few tries, so you're adding a negligible amount of time per user. But the extra time has a huge effect when an attacker is trying to calculate millions of hashes for a single user.

Just out of curiosity, how is sha composed with itself 1023 times worse than bcrypt? Is it because bcrypt is also memory bound?

In 2003, when linkedin was founded SHA1 probably made sense. GPU password cracking was mostly non-existent at this point and most machines had a single core processor.

Depends if they know the salt. If not and the salt is like 40 random characters it's going to be pretty much uncrackable.

Salting protects against rainbow tables, which is just a pre-calculated mapping of hashes to plain-text. Salting does not effect the difficulty of cracking any one single password.

Reply on news.ycombinator.com