How To Safely Store A Password • Hacker News Board

Re: How To Safely Store A Password

#191

Post by StavrosK » Wed, Dec 15, 2010, 10:55 AM UTC

Xk wrote: post #184

gxti wrote: post #163

Earlier quoted context omitted.

To nitpick, the topic at hand is pre-image attacks, not collision attacks. Pre-image is where you know the hash and want the plaintext, collision is where you create two plaintexts with the same hash but don't care about the actual hash value. The former is recovering information, the latter is falsifying trust and almost always involves signatures. Collision attacks don't apply to many situations but are much easier…

Wrong. Collisions can be found in MD5 in 2^21 time due to an attack by Xie and Feng. 2^64 is a very respectable number and is not practical for people to do on their home machines. 2^21 is.

Plus you only need a collision to break into a system that uses hashed passwords, not a preimage.

Re: How To Safely Store A Password

#192

Post by StavrosK » Wed, Dec 15, 2010, 11:09 AM UTC

nkurz wrote: post #84

tptacek wrote: post #49

Earlier quoted context omitted.

"Reversing" bcrypt? "Reversing" salted hashes? You're exactly the guy I'm talking about. "Oh, I use AES, but I don't just use AES; I store the secret IV for AES in a cookie so even my server can't decrypt it unless the client comes back with the IV so it's like two guys in the silo with the missile keys". Seriously, I just found that piece of code yesterday. Did you write it? Stop writing that stuff.

I can probably top you: some many years ago, I discovered that Network Solutions (the original domain name provider) was using the first two characters of the password as the salt for their user accounts, presumably so that the salt could also be secret. Of course, this had the side-effect of making the first two characters of the password visible in plain text if you looked at the hashes. I reported this as a bug an…

Using two-character salts might be as big of a wtf here.

Re: How To Safely Store A Password

#193

Post by StavrosK » Wed, Dec 15, 2010, 11:12 AM UTC

izak30 wrote: post #29

jmillikin wrote: post #12

"It’s important to note that salts are useless for preventing dictionary attacks or brute force attacks. You can use huge salts or many salts or hand-harvested, shade-grown, organic Himalayan pink salt. It doesn’t affect how fast an attacker can try a candidate password, given the hash and the salt from your database." Why are you storing the whole salt in your database? Isn't it much more common to keep half of it i…

I may be mistaken, as I was only browsing. I was looking at Django's auth system last night (as all of this had me curious about the backend). I don't think that SECRET_KEY is used for part of the salt at all, I think it's primarily used for validation of site-generated data, signing requests, and cookie encoding/decoding.

You are correct, Django's hashes are stored as salt$digest, or maybe salt$function$digest nowadays. It wouldn't be very good if all your password hashes became invalid because you changed the secret key.

Re: How To Safely Store A Password

#194

Post by StavrosK » Wed, Dec 15, 2010, 11:15 AM UTC

tptacek wrote: post #40

tzs wrote: post #31

Earlier quoted context omitted.

Salting was introduced long before rainbow tables were invented.

Salting was introduced in the 1970's to combat the underlying class of attacks that rainbow tables optimize. Think of rainbow tables as a compression scheme; the attack is precomputation.

That said, I don't know why, with today's computing power, people don't make rainbow table chains longer (or shorter, it's been a while since I read the paper) to save on disk space.

Re: How To Safely Store A Password

#195

Post by pmjordan » Wed, Dec 15, 2010, 11:54 AM UTC

The Java implementation linked from the article, jBCrypt, http://www.mindrot.org/files/jBCrypt/jBCrypt-0.2-doc/ uses java.lang.String's compareTo() function (lexicographical comparison) to validate the hashes of passwords. Is there cause for concern about this in practice, considering it will probably have varying runtimes for different match lengths? (I realise that running in a JITted VM means I can't predict the assembly language produced anyway)

Re: How To Safely Store A Password

#196

Post by boscomutunga » Wed, Dec 15, 2010, 12:56 PM UTC

I think sooner or later computing power is going to increase to the point of making bicrypt look like md5 or lesser,i think what matters is protecting the hash.

Re: How To Safely Store A Password

#197

Post by wladimir » Wed, Dec 15, 2010, 2:03 PM UTC

pavel_lishin wrote: post #62

bostonvaulter2 wrote: post #48

If you have a 5-year old database using a given bcrypt work factor, how difficult is it to transition to a new, higher work factor?

Follow-up question: I assume this also means that it would result in new hashes for the same passwords?

Yes. But from what I understand, that's even the case if you bcrypt() the same password with the same load factor multiple times, as it uses a random salt.

Re: How To Safely Store A Password

#198

Post by iana » Wed, Dec 15, 2010, 2:31 PM UTC

If an attacker steals a DB of passwords, it is only a matter of time before computing power catches up and is able to crack the list, regardless of the methods used to hash the values. Advances in cryptography are rare, advances in processor capabilities are not. bCrypt may be the best we can do at this point to delay this inevitability, but programmer's shouldn't come away from this thinking that using bCrypt "solves" this problem. An interesting question related to this is how long a time period is considered "safe" enough to protect a stolen list? If the list is protected from brute-force cracking for 3 years after theft, is that enough time to render the passwords unusable? 5 years? It seems like the answer to this question would be used to calculate an appropriate value for bCrypt "speed".

Re: How To Safely Store A Password

#199

Post by stcredzero » Wed, Dec 15, 2010, 2:39 PM UTC

Cushman wrote: post #70

tptacek wrote: post #55

Earlier quoted context omitted.

You're overthinking both the security aspect of this and the performance aspect of it. User-imperceptible hash times are adequate to make most conceivable brute force attacks intractable.

That's true of passwords over a certain strength, for sure. And it always has been; "6ab$TRa?" has never been counting on the difficulty of hashing for security, and probably won't for some time. But as computing power increases, that minimum strength is being pushed out. bcrypt lets us hold the line by keeping pace with computing power— couldn't it also give us the ability to push back? How many users are using the…

I think it would be enough to get hold of the 1,000,000 most common passwords and tell the user it's not allowed.

Re: How To Safely Store A Password

#200

Post by gxti » Wed, Dec 15, 2010, 2:43 PM UTC

Xk wrote: post #184

gxti wrote: post #163

Earlier quoted context omitted.

To nitpick, the topic at hand is pre-image attacks, not collision attacks. Pre-image is where you know the hash and want the plaintext, collision is where you create two plaintexts with the same hash but don't care about the actual hash value. The former is recovering information, the latter is falsifying trust and almost always involves signatures. Collision attacks don't apply to many situations but are much easier…

Wrong. Collisions can be found in MD5 in 2^21 time due to an attack by Xie and Feng. 2^64 is a very respectable number and is not practical for people to do on their home machines. 2^21 is.

You are right, of course. I wrote that as 'ideal digest' instead of MD5 then rewrote it. Specific digests always lose a few bits in real life, or in MD5's case, most of the bits...