41–50 of 215 posts
That isn't the problem. Reuse is. And the best way around that is to not let the user select the password, just generate it server side. Technically this is easier to get right than some complex password generation scheme and the end result is properly better too.
What always annoys me with the discussion of passwords is that everybody here focus on a technical solution that allows the user to continue to use insecure passwords. That isn't the problem. Reuse is. And the best way around that is to not let the user select the password, just generate it server side. Technically this is easier to get right than some complex password generation scheme and the end result is properly…
Earlier quoted context omitted.
Most of your traffic should be coming from people with logged in cookies. If you make people enter their password on every page, you won't have to worry about high volume. :) Note that bcrypt is basically insensitive to length of password. 4 chars, 8 chars, 32 chars, all take the same amount of time. And it's tunable. You could go down to only 0.01s per hash and still be a million times slower than plain MD5.
I don't think he's talking about users... I think he's talking about high volume web services.
What always annoys me with the discussion of passwords is that everybody here focus on a technical solution that allows the user to continue to use insecure passwords. That isn't the problem. Reuse is. And the best way around that is to not let the user select the password, just generate it server side. Technically this is easier to get right than some complex password generation scheme and the end result is properly…
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 machine/browser?
I think the best solution is to, first, forbid passwords under 10 characters. 8 is still relatively secure, but not really, 10 at least gives you a fighting chance. Second, run your own dictionary attack (you can load /usr/share/dict/words into a hashtable and check for membership in sub-second times..in fact, here:
import sys
f = open('/usr/share/dict/words')
words = {}
for line in f:
words[line.replace('\n','')] = None
if sys.argv[1] in words:
print 'You fail'
The infrastructure problem is places like Banks saying "Enter a password between 6 and 12 characters and only use alphanumeric characters!"
Looks like Rails 3.1 is using bcrypt: https://github.com/rails/rails/blob/master/activemodel/lib/a...
Why not PBKDF2?
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.
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 attack is done by getting a list of plain text passwords and then running them through the same hashing algorithm as was used originally (adding the salt value if present). Once the attacker has done that they just compare the hashed strings. If they match then it'll be the same password.
Commonly the attacker would start with a dictionary of common passwords and submit them along with common variants (eg, password, Password password1 passw0rd).
If that's not successful they can move onto pure brute force (eg, a , ab, ac, etc)
What always annoys me with the discussion of passwords is that everybody here focus on a technical solution that allows the user to continue to use insecure passwords. That isn't the problem. Reuse is. And the best way around that is to not let the user select the password, just generate it server side. Technically this is easier to get right than some complex password generation scheme and the end result is properly…
Depending on the attack scenarios, that may not actually be more risky than allowing users to choose their own password..
I'd say that the best compromise of these approaches would be to encourage the use of password safe programs which at least store the password list in an encrypted format on local machines (of course this still relies on the user choosing a strong password for the password safe..)