81–90 of 215 posts
But the alternative seems to be to make every request very slow, because it would require bcrypting the password with every request.
Earlier quoted context omitted.
Reuse is a problem, but weak passwords are the biggest problem. If you have a strong password that never gets cracked/leaked/intercepted but you use it everywhere you're still fine, but that's not recommended. Generating server-side passwords is horrible as well since you're counting on the user to write it down and/or let the browser's password manager save it. What if the user wants to log in with a different machi…
Eight characters for a password seems plenty long to me, if you're truly using a random password. You have [A-Za-z] = 52 chars, [0-9] = 10, [!@#$%^& ()_-+=;':",. /?\|[]{}] = 30, for a total of 92 possibilities. Then you have an 8 character password. Even if the attacker knows you're using 8 characters, you've got ((92^8) 0.3)/60/60/60/24/365/100 = 271 centuries if it takes 0.01 seconds a try. And we're really talking…
For instance, a plain alphanum password of length 9 is stronger than a password of length 8 that allows for special characters. (because 62^9 > 94^8)
In other words, adding one character to your password is as good as choosing from a bigger character set.
Okay, beginning at length 10, you'd need to add two characters, but that's really all you need to do up to length 20. (which is an insane length for a random password anyway)
Earlier quoted context omitted.
Reuse is a problem, but weak passwords are the biggest problem. If you have a strong password that never gets cracked/leaked/intercepted but you use it everywhere you're still fine, but that's not recommended. Generating server-side passwords is horrible as well since you're counting on the user to write it down and/or let the browser's password manager save it. What if the user wants to log in with a different machi…
Eight characters for a password seems plenty long to me, if you're truly using a random password. You have [A-Za-z] = 52 chars, [0-9] = 10, [!@#$%^& ()_-+=;':",. /?\|[]{}] = 30, for a total of 92 possibilities. Then you have an 8 character password. Even if the attacker knows you're using 8 characters, you've got ((92^8) 0.3)/60/60/60/24/365/100 = 271 centuries if it takes 0.01 seconds a try. And we're really talking…
Using punctuation does not make a password "more random", it only makes the random choice set slightly larger. Bumping the length is much more significant than bumping the set as it's exponential.
The debate is whether it's easier for a user to both pick and remember a "random-enough" - i.e not easily bruteforce-able, regardless of hashing technology - [A-Za-z]{10} password or a [A-Za-z0-9!@#$%^&()_-+=;':",./?\|[\]{}]{8} password.
For the record, Google's 2-factor auth generated app-specific passwords are [a-z]{16}, which gives 1E22, or 230 billion years with bcrypt at 0.3s.
I'd like to see sites offer the option of not using password-based authentication. Instead I'd like to see public key based authentication as an option. Basically, the site would have a copy of my public key (say my GPG key or an ssh key), and to authenticate I prove that I have access to the corresponding private key.
You've just described SSL with client certificates. Works perfectly well, is extremely secure, and has an extremely bad GUI in pretty much every browser ever. (It's somewhat difficult to use "on the road", but that's arguably a security feature.)
There's an addon for Firefox called Enigform (I've not tried it out yet) which uses PGP for web authentication:
Earlier quoted context omitted.
Timing attacks are not a problem if you're using it to hash passwords. Also, Javascript implementations don't use doubles for pure integer arithmetic.
If I can observe your (SSL-encrypted) login session, I can time how long the server takes to process your (presumably real) password. What makes you think password hashes don't need to worry about this?
The article claims it takes bcrypt 0.3 seconds to hash a 4 char password on a laptop. How does a server authenticate users in high volume with bcrypt? ~0.25 secs per auth request might warrant having a separate server just for authentication.
Several of the largest sites in the world have scaled bcrypt. There are longer answers as to why this is not a big deal, but if it helps to kill the red herring that bcrypt might not scale: Twitter uses it.
I'm sold on bcrypt but like to hear scaling stories :)
Earlier quoted context omitted.
What do you do when you loose the keys? And the default behavior or enabling keys whenever your computer is open? One click bank account access?
What do you do when you loose the keys? You don't. And ideally you have a single key. If you can be trusted to keep a social security card and a passport, you can just as easily keep a key safe. Print it out. Store it in a safe place. We've been doing that for centuries. And the default behavior or enabling keys whenever your computer is open? You can password protect your keys.
If someone steals your passport, you'll know: you won't be able to find it.
Digital keys have no such properties. If someone steals your private key, you will have no idea until you see them steal all your money and accounts.
Physical items also need to be carried to a destination to be used. If someone steals your passport, they may be able to take over your bank accounts, etc. For that, they have to actually go in person to meet a bank manager and pretend to be you. People do that fairly successfully, but it's hardly an efficient process.
A digital passport/key, on the other hand, could be abused immediately after it's been stolen, and could be used across all your accounts within the hour, before you've even realised you've been robbed.
Finally, you can only use one passport at a time. Not only it takes time, but you need a career criminal dedicated to each "process".
A digital key robbery, however, requires no human element, and thus can be done in parallel at a large scale. One could use Trojans to capture the keys of a large number of people and steal their money in an automated manner without ever showing up at a bank.
All those problems can perhaps be solved, but they are not easy and they have nothing to do with keeping the key safe - more to do with keeping the process of using the key as inefficient as possible. The best way to ensure your digital key cannot be abused is to make sure that you can only use it in person in front of other human beings, on authorised hardware.
So, pretty much like the way our bank cards work, then.
Earlier quoted context omitted.
Timing attacks are not a problem if you're using it to hash passwords. Also, Javascript implementations don't use doubles for pure integer arithmetic.
If I can observe your (SSL-encrypted) login session, I can time how long the server takes to process your (presumably real) password. What makes you think password hashes don't need to worry about this?
the weaknews is actually storing the salt or code or key with the password. using bcrypt helps a bit but doesnt truly solve the issue. i think thats important to point out. sha1 with a salt u cant find beats bcrypt with a key u know any day
No. Not at all. If someone managed to break in to your website and get the password hashes, chances are they also have your "secret" salt. There is no reason to separate the salt from the hash, and, in fact, there are no implementations which do that. However, if I can't convince you of that, then if you ever make a website that takes passwords, please use bcrypt. You can do your super-special-salt-separation-scheme,…
I believe the GP was referring to the scheme where you don't store the salts at all (or only store some bits of each salt.) The verification needs to brute-force the salt (or the missing bits) each time it verifies the password.
The missing bits are quite similar to the bcrypt workfactor - the more you leave out the harder it is for both the attacker and the legitimate verification to verify passwords.