6 ms·
I disagree wholeheartedly. The article is based around the fallacy we've seen time and time again, of throwing more cryptography at a problem that cryptography
by sordidarray 17y ago
I disagree wholeheartedly. The article is based around the fallacy we've seen time and time again, of throwing more cryptography at a problem that cryptography alone cannot solve. In the end, a crappy password is a crappy password. Successfully discouraging your users from using a crappy password has much better repercussions (for the user, for you, and for the web in general) than switching from a hash-based authentication system to bcrypt. Use bcrypt for additional security, but do not use it in an attempt to solve the problem of crappy passwords that the article falsely claims bcrypt solves.
To be more technical, bcrypt, like PBKDF2 and other schemes of that nature, add a significant amount of additional computation by iteratively applying a primitive, but still maintain a relatively small circuit size (in comparison to the primitive itself, which is usually designed to fit onto smart cards and the like). Creating and using algorithms which are "memory-hard" or require larger circuits reduces the number of circuits one can place on some area of silicon and drives up the cost of an attack. In other words, mounting an attack on bcrypt or PBKDF2 is still cheaper and potentially much faster than we'd like it to be (which is the reason those algorithms are "tunable"--you scale the number of iterations up as computers become faster). This, along with some example memory-hard functions was the topic of Percival's paper, "Stronger Key Derivation via Sequential Memory-Hard Functions," which correctly cites Bernstein as the source of emphasis on practicality in measuring an attack not by computational complexity, but the cost of launching the attack. See http://www.bsdcan.org/2009/schedule/attachments/87_scrypt.pdf http://www.bsdcan.org/2009/schedule/attachments/87_scrypt.pd... if you're interested in reading further.
- codahale 17y agoI'm familiar with cperciva's scrypt, and I think it's a great solution. That said, I've only seen C and Ruby bindings for it. I'd love to recommend its use over bcrypt, as memory constraints are much more expensive than computational constraints, but recommending something most developers don't have access to would result in more weak hashing schemes in production.
- dfranke 17y agoIn any language with sane FFI, scrypt is pretty easy to write new bindings for. At my previous job I wrote a complete scrypt plugin for Openfire in a weekend, and only a couple hours of that was for writing the JNI bindings.
- mock 17y agoI'm no cryptographer, so maybe this is a silly question... Any reason why I shouldn't just reimplement it in the high level language of my choice and release it open source?
- tptacek 17y agoThe mistake you're making is thinking of bcrypt as a protection for end-users and their passwords. It isn't. Bcrypt exists to protect application developers. A user with a crappy password is getting his account busted one way or another. You're right to point that out. Cryptography won't solve that problem. The problem crypto solves is this: a crappy web app that loses its user table is royally screwed if its devs settled for "salted hashes". At the whim of their attackers, hundreds or thousands of their user's passwords are going to hit Rapidshare. That's what the devs will be famous for. Bcrypt keeps that from happening. You'll get famous behind losing 1000 passwords. You won't get famous behind losing 20.
- sordidarray 17y agoA 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.
- tptacek 17y agoLosing 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?
- codahale 17y agoAlso, you point out that "successfully discouraging your users from using a crappy password has much better repercussions." This is true, and I'm curious to know how you personally achieve this with your users, given that the vast majority[1] of users choose spectacularly crap passwords. [1] http://www.imperva.com/docs/WP_Consumer_Password_Worst_Practices.pdf http://www.imperva.com/docs/WP_Consumer_Password_Worst_Pract...
- steveplace 17y agohttps://twitter.com/signup https://twitter.com/signup Start typing in the pw box, if it's not strong enough, they'll let you know. Also, try "123456" or "password"
- bmj 17y agoAh, but "1password" is good.
- moe 17y agoRule of thumb: If you're going to look for a good implementation of X (anything) then scratch twitter.com from your list before you start.
- run4yourlives 17y agoWhy? In this case, it's better than most. The details need work, but the idea is sound.
- kelnos 17y agoYou're talking about a completely different problem. Yes, many users pick crappy passwords. That's a social problem, one that is difficult to address with technology[1]. Storing passwords on the server is unrelated to whether or not the user picked a good password. If an attacker gets ahold of a copy of your database, they will have a much easier time of turning SHA1 hashes of passwords into actual passwords than of turning bcrypt-encrypted passwords into actual passwords (the latter being orders of magnitude more difficult, maybe to the point of being impractical as a target vector). [1] You can always do things like require certain types of password complexity: minimum length, choice of characters from different character classes and cases, etc. But then you end up just moving the problem elsewhere: instead of using the crappy password they remember, the user has to write down their complex password, or maybe even store it in a text file on their hard drive.
- sordidarray 17y agoI'm not talking about a different problem. The bruteforce attack described in the article primarily affects short and dictionary-based passwords. If the password is of sufficient length and complexity (the keyspace is large enough), then bruteforcing becomes computationally infeasible. What the article proposes is, essentially, to use a more computationally expensive algorithm for the benefit of protecting shorter, weaker, passwords. I disagree, and think that increasing the computational cost of the algorithm itself should be used to enhance the security of passwords, rather than having their security depend entirely on that increased cost. Good passwords stored as a salted hash, or preferably, as an HMAC, are in no way insecure. I feel that implying otherwise is a disservice.
- tptacek 17y agoYou sound like someone who has never run John the Ripper. There clearly are passwords that are impractical to crack. To get one, just "head /dev/random | openssl sha1". Nobody uses passwords like that. They're irrelevant. Instead, the smart ones use passwords that contain a combination of words, numbers, and punctuation. John the Ripper has been cracking those passwords for over a decade. "Salted hashes" are insecure. They'd have been rejected by the FreeBSD team in 1997. If you choose to make a religion out of not using bcrypt, do what the RFC says and use PBKDF.