Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How To Safely Store A Password

codahale.com

Post reply on HN
Print view View original

51–60 of 110 posts

Re: How To Safely Store A Password

#51

Post by cperciva »

peterwwillis wrote: post #43

I am a crypto noob, so please excuse me if I sound stupid. But why not force your users to pick a password that is at least 8 characters and contains at least one digit, one capitalized letter, one lowercase letter and one special character, then gen a 16-byte salt and run it through SHA-512? The examples given in the article are for 6 lowercase alpha-only characters, which has always been relatively trivial to crack…

If you can force your users to pick strong passwords, good for you. But in practice, that's almost impossible.

Re: How To Safely Store A Password

#52

Post by [deleted] »

tptacek wrote: post #40
sordidarray wrote: post #33

Earlier quoted context omitted.

A poorly-written web app whose SQL database is compromised has bigger problems than protecting the integrity of poorly chosen passwords (especially if they store financial information). Losing such a collection of salted hashes does not render one "royally screwed." Those hashes (or HMACs) are still cryptographically secure, which means it's computationally infeasible to find a first preimage provided the password do…

Losing a Unix password file in the 1990s would have been newsworthy. Password files were "secured" using Unix crypt(3), an algorithm that at least made a nod towards resisting brute force attacks --- so much so that when PHK wrote FreeBSD's md5 scheme, he iterated it PBKDF-style, because even then it was clear that using cryptographic hashes "straight" was a bad idea. The biggest differences between Mindvox losing it…

[deleted]

Re: How To Safely Store A Password

#53

Post by sordidarray »

tptacek wrote: post #50
sordidarray wrote: post #47

Earlier quoted context omitted.

I never said SHA-1, a cryptographically insecure hash, was a good choice. It's important to note in your differences that, for the most part, cryptographic hash functions in current use have gotten much slower (e.g., SHA-256 vs MD5), but are also getting much better (SHA-3 competition). The argument I have is this: The passwords that are going to be hitting Rapidshare in your scenario are the crappy or short ones, wh…

You're arguing for the sake of arguing. The developing weaknesses in SHA-1 don't make it a poor password hash. That's an irrelevant factoid you threw in to cloud the argument. Pick a number of passwords to lose from a table. Hash them with any of the SHA-3 contestants and a "salt": you will lose more. Hash them with bcrypt, you will lose less. Again I'm left asking you: what's your point? What are you trying to prove…

I'm not "arguing for the sake of arguing." I'm trying to explain my point to you, and I'm doing so in a polite manner, which is exactly what I'd expect from you.

The weaknesses in SHA-1 make it a poor cryptographic hash, which make it a poor pseudorandom function, which has a significant potential to make it a poor password hash.

My point, for the second time, is that you're not "effed" if you use salted hashes.

I'm not trying to "prove" anything. I'm stating my opinion on the matter. This isn't a pissing contest, rather, a forum for discussion.

Re: How To Safely Store A Password

#54

Post by tptacek »

sordidarray wrote: post #53
tptacek wrote: post #50

Earlier quoted context omitted.

You're arguing for the sake of arguing. The developing weaknesses in SHA-1 don't make it a poor password hash. That's an irrelevant factoid you threw in to cloud the argument. Pick a number of passwords to lose from a table. Hash them with any of the SHA-3 contestants and a "salt": you will lose more. Hash them with bcrypt, you will lose less. Again I'm left asking you: what's your point? What are you trying to prove…

I'm not "arguing for the sake of arguing." I'm trying to explain my point to you, and I'm doing so in a polite manner, which is exactly what I'd expect from you. The weaknesses in SHA-1 make it a poor cryptographic hash, which make it a poor pseudorandom function, which has a significant potential to make it a poor password hash. My point, for the second time, is that you're not "effed" if you use salted hashes. I'm…

I'd like you to explain how you'd exploit a problem with SHA-1, or, to make it more interesting, MD5 or MD4, to attack a "typical" hashed password (say, Keychain.app "memorable") more quickly than via iterated brute force.

Re: How To Safely Store A Password

#55

Post by dfranke »

codahale wrote: post #22
sordidarray wrote: post #20

I disagree wholeheartedly. The article is based around the fallacy we've seen time and time again, of throwing more cryptography at a problem that cryptography alone cannot solve. In the end, a crappy password is a crappy password. Successfully discouraging your users from using a crappy password has much better repercussions (for the user, for you, and for the web in general) than switching from a hash-based authent…

I'm familiar with cperciva's scrypt, and I think it's a great solution. That said, I've only seen C and Ruby bindings for it. I'd love to recommend its use over bcrypt, as memory constraints are much more expensive than computational constraints, but recommending something most developers don't have access to would result in more weak hashing schemes in production.

In any language with sane FFI, scrypt is pretty easy to write new bindings for. At my previous job I wrote a complete scrypt plugin for Openfire in a weekend, and only a couple hours of that was for writing the JNI bindings.

Re: How To Safely Store A Password

#56

Post by codahale »

sordidarray wrote: post #47
tptacek wrote: post #40

Earlier quoted context omitted.

Losing a Unix password file in the 1990s would have been newsworthy. Password files were "secured" using Unix crypt(3), an algorithm that at least made a nod towards resisting brute force attacks --- so much so that when PHK wrote FreeBSD's md5 scheme, he iterated it PBKDF-style, because even then it was clear that using cryptographic hashes "straight" was a bad idea. The biggest differences between Mindvox losing it…

I never said SHA-1, a cryptographically insecure hash, was a good choice. It's important to note in your differences that, for the most part, cryptographic hash functions in current use have gotten much slower (e.g., SHA-256 vs MD5), but are also getting much better (SHA-3 competition). The argument I have is this: The passwords that are going to be hitting Rapidshare in your scenario are the crappy or short ones, wh…

Uh. All of the current SHA-3 candidates are as fast or faster than SHA-1. That's one of the contest's design goals:

NIST expects SHA–3 to have a security strength that is at least as good as the hash algorithms currently specified in FIPS 180–2, and that this security strength will be achieved with significantly improved efficiency.

http://csrc.nist.gov/groups/ST/hash/documents/FR_Notice_Nov0...

Re: How To Safely Store A Password

#57

Post by sordidarray »

tsally wrote: post #42
sordidarray wrote: post #33

Earlier quoted context omitted.

A poorly-written web app whose SQL database is compromised has bigger problems than protecting the integrity of poorly chosen passwords (especially if they store financial information). Losing such a collection of salted hashes does not render one "royally screwed." Those hashes (or HMACs) are still cryptographically secure, which means it's computationally infeasible to find a first preimage provided the password do…

A poorly-written web app whose SQL database is compromised has bigger problems than protecting the integrity of poorly chosen passwords (especially if they store financial information). Are you suggesting that because a comprise is bad, nothing should be done to reduce the magnitude of the impact? This argument does not hold up in general, and it is especially weak when arguing about using encryption algorithms with…

Of course I'm not suggesting such a thing.

The effort required to implement bcrypt in new systems is indeed small, and such a method is the suggested way to do, but depending on the amount of users, the effort required to port an existing database over to bcrypt (e.g., Facebook) could be immense, and the result disastrous if not done with great care.

Ptacek said, and I quote, "... a crappy web app ..." so why do you only cite me as making the "incorrect assumption that only poorly written web apps have their databases compromised?"

Again, I agree that is the case in new systems, but I disagree that one is "effed," as the article puts it, if they have a large database of salted hashes.

Re: How To Safely Store A Password

#58

Post by codahale »

dfranke wrote: post #55
codahale wrote: post #22

Earlier quoted context omitted.

I'm familiar with cperciva's scrypt, and I think it's a great solution. That said, I've only seen C and Ruby bindings for it. I'd love to recommend its use over bcrypt, as memory constraints are much more expensive than computational constraints, but recommending something most developers don't have access to would result in more weak hashing schemes in production.

In any language with sane FFI, scrypt is pretty easy to write new bindings for. At my previous job I wrote a complete scrypt plugin for Openfire in a weekend, and only a couple hours of that was for writing the JNI bindings.

Toss it up on GitHub, man.

Re: How To Safely Store A Password

#59

Post by bmj »

steveplace wrote: post #36
codahale wrote: post #28

Earlier quoted context omitted.

Also, you point out that "successfully discouraging your users from using a crappy password has much better repercussions." This is true, and I'm curious to know how you personally achieve this with your users, given that the vast majority[1] of users choose spectacularly crap passwords. [1] http://www.imperva.com/docs/WP_Consumer_Password_Worst_Pract...

https://twitter.com/signup Start typing in the pw box, if it's not strong enough, they'll let you know. Also, try "123456" or "password"

Ah, but "1password" is good.

Re: How To Safely Store A Password

#60

Post by dfranke »

codahale wrote: post #58
dfranke wrote: post #55

Earlier quoted context omitted.

In any language with sane FFI, scrypt is pretty easy to write new bindings for. At my previous job I wrote a complete scrypt plugin for Openfire in a weekend, and only a couple hours of that was for writing the JNI bindings.

Toss it up on GitHub, man.

I wasn't able to convince my boss to let me open-source it.
Post reply on HN