Does anyone know how Djangos built-in password hashing fares?
How To Safely Store A Password
71–80 of 215 posts
Re: How To Safely Store A Password
#72I'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.
That's already possible with SSL sites - sign up for an account at www.startssl.com if you want to see a real-life example.
Oops! StartSSL was compromised this month, although they say the issue is remediated now. http://news.netcraft.com/archives/2011/06/22/startssl-suspen...
Re: How To Safely Store A Password
#73What 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…
There are a lot of misconceptions on what makes a "secure" password— fluffy is puffy takes longer to crack than J4fS . http://www.baekdal.com/tips/password-security-usability
"fluffy is puffy takes longer to crack than J4fS
Assuming the attacker brute-forces all 3 word combinations, maybe. But "fluffy is puffy" is a valid English sentence and language is a rather poor source of entropy.
Re: How To Safely Store A Password
#74I am surprised nobody had already talked about scrypt yet. Here is an old hackernews entry about it. http://news.ycombinator.com/item?id=601408 I would have loved to use scrypt, but there is only a C implementation. I would had loved to have at least a javascript one.
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.
Re: How To Safely Store A Password
#75What 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…
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…
You can also initialize the words in more pythonic way:
with open('/usr/share/dict/words') as wordlist:
words = set(line[:-1] for line in wordlist)
import sys
lookup = '%s\n' % sys.argv[1]
with open('/usr/share/dict/words') as wordlist:
[ sys.stdout.write('Dictionary password: %s' % lookup) or sys.exit(1) for line in wordlist if line == lookup ]
Re: How To Safely Store A Password
#76I recently put together a commentary + code on how to upgrade passwords hashed insecurely in your DB without user intervention. This was in response to MtGox talking about "slowly migrating users", which presumably means upgrading passwords at the point of login: https://gist.github.com/1051238
If I'm not misunderstanding your purpose, why not just:
1) Take those md5 unsalted passwords and 2) bcrypt them
Then upgrade the users to non-pre-hashed bcrypt as they log in?
?
Re: How To Safely Store A Password
#77I recently put together a commentary + code on how to upgrade passwords hashed insecurely in your DB without user intervention. This was in response to MtGox talking about "slowly migrating users", which presumably means upgrading passwords at the point of login: https://gist.github.com/1051238
If I'm not misunderstanding your purpose, why not just: 1) Take those md5 unsalted passwords and 2) bcrypt them Then upgrade the users to non-pre-hashed bcrypt as they log in? ?
Why do you think that isn't what this is doing, only with fault tolerance to allow more than one scheme upgrade?
Re: How To Safely Store A Password
#78Earlier 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…
You can also initialize the words in more pythonic way: with open('/usr/share/dict/words') as wordlist: words = set(line[:-1] for line in wordlist) Or, for one time check you can stop reading on match: import sys lookup = '%s\n' % sys.argv[1] with open('/usr/share/dict/words') as wordlist: [ sys.stdout.write('Dictionary password: %s' % lookup) or sys.exit(1) for line in wordlist if line == lookup ] As for the objecti…
While I agree that the first code is pythonic and nice, the second code is quite the opposite of that. Why forcing imperative code into a list comprehension? It is a lot easier to read as nested loop, as it doesn't build a dummy list with some strange "or" operation:
import sys
lookup = '%s\n' % sys.argv[1]
with open('/usr/share/dict/words') as wordlist:
for line in wordlist:
if line == lookup:
sys.stdout.write('Dictionary password: %s' % lookup)
sys.exit(1)Re: How To Safely Store A Password
#79Earlier quoted context omitted.
If I'm not misunderstanding your purpose, why not just: 1) Take those md5 unsalted passwords and 2) bcrypt them Then upgrade the users to non-pre-hashed bcrypt as they log in? ?
Why do you think that isn't what this is doing, only with fault tolerance to allow more than one scheme upgrade?
Because the juicy bits got cut off due to the way github is displayed on my phone. Sorry I couldn't see that portion!
Re: How To Safely Store A Password
#80Earlier 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.
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?