91–100 of 215 posts
You can add the configurable slowness factor to any secure hash. Just use salts but leave out k bits from each when storing them. The more bits you leave out, the more work it takes to verify a password as the verification procedure needs to brute-force the missing k bits.
Earlier quoted context omitted.
Javascript? Have fun securing that one against timing attacks. Also, it's so much slower than the C implementation (remember that crypto algorithms are very carefully designed for 32- or 64-bit words or arbitrary-length integers; Javascript's doubles are a very poor match.)
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.
This means that you essentially have to make your KDF's workload much weaker than if you used C implementation to get an acceptable performance.
You can add the configurable slowness factor to any secure hash. Just use salts but leave out k bits from each when storing them. The more bits you leave out, the more work it takes to verify a password as the verification procedure needs to brute-force the missing k bits.
Why not PBKDF2?
On .Net this is definitely the way to go. http://msdn.microsoft.com/en-us/library/system.security.cryp... Make sure to use the defaults or better in terms of rounds. The salt provided when you don't supply one is cryptographically random.
Why not PBKDF2?
Earlier quoted context omitted.
In any kind of scheme where all the server stores is some kind of hash of the password, how are you going to verify a password without sending the plaintext password to the server, so the server can compute the hash and compare against the stored hash?
One possible option is challenge-response authentication. There a number of variations, but the simplest example is to hash both the hashed password and a nonce on both ends and check the resulting hash[1]. This means that the server only requires that the hashed password is stored, and the client never sends the password in plaintext as it generates the hash itself. As long as the nonce is unique each time, we can p…
Earlier quoted context omitted.
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?
Would you really be able to do timing attacks on a server from the client side? I thought you needed a much greater accuracy of measurement, sub-millisecond, than you would be able to achieve with network latency in the mix.
Earlier quoted context omitted.
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.
Passports and social security cards are physical items. Because of this, they have the inherent property of not being capable of ubiquity. 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…
Can someone help me understand what a password cracker does with a list of salted/hashed passwords? How do they know they've figured out the right plain text passwords without bouncing them against the authentication logic?
the salt is not "secret" - it is stored in plain text for each password. it does not need to be secret to do its job (defend against rainbow tables).