Hacker News Reader

Comment by sordidarray | Hacker News Reader

A poorly-written web app whose SQL database is compromised has bigger problems than protecting the integrity of poorly chosen passwords (especially if they store financial information).

Losing such a collection of salted hashes does not render one "royally screwed." Those hashes (or HMACs) are still cryptographically secure, which means it's computationally infeasible to find a first preimage provided the password doesn't suck. You seem to think (or are at least implying) that bcrypt is impervious to standard iterative bruteforce attacks, but that's just not the case. Much like PBKDF2, and other iterative hashing techniques, bcrypt is more resistant, but still "vulnerable" to such an "attack." bcrypt's main advantage over other iterative techniques, in my opinion, is the 4KiB of s-boxes used by Blowfish.

View on HN

A poorly-written web app whose SQL database is compromised has bigger problems than protecting the integrity of poorly chosen passwords (especially if they store financial information).

Are you suggesting that because a comprise is bad, nothing should be done to reduce the magnitude of the impact? This argument does not hold up in general, and it is especially weak when arguing about using encryption algorithms with freely available, high quality implementations. The developer effort required to use bcrypt is minimal.

Also, you seem to be making the incorrect assumption that only poorly written web applications get their databases compromised. Web applications with excellent security get their databases stolen for a variety of other reasons. Even if the programmers do everything right, a careless employee might get his/her password sniffed or stolen by a key logger. If a company uses external hosting, its database could get stolen because of a mistake by the hosting providers.

In summary, the risk of your database being stolen is always present, regardless of the diligence of the the programmers who implemented the web application. The fact that a compromise is bad is not justification for ignoring simple security measures that take minimal effort to implement.

Of course I'm not suggesting such a thing.

The effort required to implement bcrypt in new systems is indeed small, and such a method is the suggested way to do, but depending on the amount of users, the effort required to port an existing database over to bcrypt (e.g., Facebook) could be immense, and the result disastrous if not done with great care.

Ptacek said, and I quote, "... a crappy web app ..." so why do you only cite me as making the "incorrect assumption that only poorly written web apps have their databases compromised?"

Again, I agree that is the case in new systems, but I disagree that one is "effed," as the article puts it, if they have a large database of salted hashes.

I should have been more precise in the article. Here:

A system which uses an adaptive hash function like bcrypt is ~6 orders of magnitude less effed in the event of a compromised database than a system which uses a standard hash algorithm and a salt, ceteris paribus.

I would hope you agree that those ~6 orders of magnitude could well be the difference between "not noticeably effed" and "profoundly effed."

He's implying that using bcrypt (and other iterative hash functions like PBKDF2 and scrypt) raises the cost of mounting a dictionary attack compared to commonly-used and -recommended hash algorithms like SHA256.

Which, uh, is an objectively verifiable fact.

Losing a Unix password file in the 1990s would have been newsworthy. Password files were "secured" using Unix crypt(3), an algorithm that at least made a nod towards resisting brute force attacks --- so much so that when PHK wrote FreeBSD's md5 scheme, he iterated it PBKDF-style, because even then it was clear that using cryptographic hashes "straight" was a bad idea.

The biggest differences between Mindvox losing it's password file in 1995 and a webapp losing its user table in 2010 are:

* Web apps are getting fielded with straight SHA1 hashes, which is inferior even to FreeBSD's original MD5 hash scheme.

* Brute force attacks have gotten much faster.

The main advantage to bcrypt over, say, AES, is that the key setup is really slow. Mazieres spotted a weakness in Blowfish and turned it into a benefit.

Is there some real argument you have with me? I agree: if you lose your user table, you have real problems apart from losing password hashes --- though we could bicker about which of those problems is worse. Where are you disagreeing with me?

I never said SHA-1, a cryptographically insecure hash, was a good choice. It's important to note in your differences that, for the most part, cryptographic hash functions in current use have gotten much slower (e.g., SHA-256 vs MD5), but are also getting much better (SHA-3 competition).

The argument I have is this: The passwords that are going to be hitting Rapidshare in your scenario are the crappy or short ones, whether you use bcrypt, scrypt, PBKDF2, salted hashes or HMAC. Encourage them to use bcrypt or some other iterative technique for the security benefits, but don't exaggerate and tell them that they're "effed" if they have salted hashes. They're still a long way away from storing passwords in plaintext.

You're arguing for the sake of arguing. The developing weaknesses in SHA-1 don't make it a poor password hash. That's an irrelevant factoid you threw in to cloud the argument.

Pick a number of passwords to lose from a table. Hash them with any of the SHA-3 contestants and a "salt": you will lose more. Hash them with bcrypt, you will lose less.

Again I'm left asking you: what's your point? What are you trying to prove? That you know that there's a SHA-3 contest? You haven't refuted anything this article says; in fact, you keep accidentally managing to validate it.

I'm not "arguing for the sake of arguing." I'm trying to explain my point to you, and I'm doing so in a polite manner, which is exactly what I'd expect from you.

The weaknesses in SHA-1 make it a poor cryptographic hash, which make it a poor pseudorandom function, which has a significant potential to make it a poor password hash.

My point, for the second time, is that you're not "effed" if you use salted hashes.

I'm not trying to "prove" anything. I'm stating my opinion on the matter. This isn't a pissing contest, rather, a forum for discussion.

I'd like you to explain how you'd exploit a problem with SHA-1, or, to make it more interesting, MD5 or MD4, to attack a "typical" hashed password (say, Keychain.app "memorable") more quickly than via iterated brute force.

Currently such attacks are infeasible, but there are some very interesting, and very promising families of collision-based attacks (such as herding) which may yield results in that area, although such attacks may only work in specific cases.

All public results against SHA-1 are collision attacks. Password hashing doesn't rely on collision-resistance, only one-wayness. Not even MD5 has any published preimage attacks against it. The known weaknesses in these functions have nothing to do with why they're poor choices for password storage.

Uh. All of the current SHA-3 candidates are as fast or faster than SHA-1. That's one of the contest's design goals:

NIST expects SHA–3 to have a security strength that is at least as good as the hash algorithms currently specified in FIPS 180–2, and that this security strength will be achieved with significantly improved efficiency.

http://csrc.nist.gov/groups/ST/hash/documents/FR_Notice_Nov0...

Yes, that's why I specifically said, "in current use." No one should be using SHA-3 hash functions. SHA-256 and SHA-1 are much slower than MD5 and very much slower than MD4. The "Getting much better" comment was in reference to speed improvements as well as security improvements (such as removal of vulnerability to length-extension attacks).

Reply on news.ycombinator.com