11–20 of 110 posts
The article is using a definition of "store" of which I was previously unaware. If you'd like to store passwords (eg, in a keyring or password manager), use GPG.
The problem with using a scheme designed to be computationally intensive is that it doesn't scale. How can I justify 0.3 seconds of computation time if I'm dealing with tens of thousands of connections per second?
Second, plenty of apps that are far bigger than yours have scaled bcrypt without event. 37signals is a public example. Other larger apps are using it without talking about it.
Third, in the spectacularly unlikely event that password hashing became a scalability obstacle, it's pure compute and scales horizontally without a problem. Note: I've never heard of someone having to do this.
Finally, the whole point of bcrypt is that it's tuneable. You dial it up to your pain threshold, and in the process cripple brute force attackers.
But wait. What if I use a 64 bit salt and then AES-encrypt the password with a key I store half on my server and half in a cookie I send to the user and then they'd have to break AES to get my passwords? How about that , Coda Hale?
So say we tone it down to a more feasible 0.01 seconds per hash, or to put it another way, 100 requests per second. That's only 4.8 months to crack that password. There'll certainly be future hardware advances, plus GPUs could be used to bring that down. And you can be sure someone used "password" or "123456". Moral of the story: use long and multiple passwords.
But wait. What if I use a 64 bit salt and then AES-encrypt the password with a key I store half on my server and half in a cookie I send to the user and then they'd have to break AES to get my passwords? How about that , Coda Hale?
We certainly don't want people in the software engineering industry to come up with new ideas, implement them, and see how they work in real life. That could lead to advancement in the field, and that would be bad, because I might have to learn something new. Shudder.
But wait. What if I use a 64 bit salt and then AES-encrypt the password with a key I store half on my server and half in a cookie I send to the user and then they'd have to break AES to get my passwords? How about that , Coda Hale?
Only experts should be allowed to innovate in the security domain. Passwords on lolcats are serious business! We certainly don't want people in the software engineering industry to come up with new ideas, implement them, and see how they work in real life. That could lead to advancement in the field, and that would be bad, because I might have to learn something new. Shudder.
But wait. What if I use a 64 bit salt and then AES-encrypt the password with a key I store half on my server and half in a cookie I send to the user and then they'd have to break AES to get my passwords? How about that , Coda Hale?
Only experts should be allowed to innovate in the security domain. Passwords on lolcats are serious business! We certainly don't want people in the software engineering industry to come up with new ideas, implement them, and see how they work in real life. That could lead to advancement in the field, and that would be bad, because I might have to learn something new. Shudder.
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.pd... if you're interested in reading further.