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

I mean, why not tell everyone our password hashes?

theobsidiantower.com

Post reply on HN
Print view View original

21–30 of 167 posts

Re: I mean, why not tell everyone our password hashes?

#21

Post by basseq »

Sure, in an ideal world: post the hashes, the salts, the hash algorithm, everything. If it's done "right" (e.g., the hash function has enough complexity), then brute force cracking, rainbow tables, etc. would take so long that it wouldn't be feasible to crack them with any volume.

Of course, you could still crack some (problem), so keeping multiple secrets hidden through obscurity (the hashes, the salts, etc.) is another layer of security.

This doesn't guarantee security, but it's certainly more secure. But it is additive: there's no reason to just use MD5 (or plaintext) because "my hashes are secret".

Re: I mean, why not tell everyone our password hashes?

#22

Post by ceejayoz »

eveningcoffee wrote: post #8

Because your password is part of your identity and is actually used to cross check during identity matching.

Leaving aside the fact that changing my password doesn't mean I have a new identity, having the hash $2y$10$/Aglzm2zpHO7m1dIv5vSp.GHPUd1D8uODn/jtBv3gpe8yS5e/D9PW doesn't tell you my password is "tinkerbell".

Re: I mean, why not tell everyone our password hashes?

#23

Post by Glyptodon »

lucasgonze wrote: post #2

That inspired this idea: make all password databases public, in an encrypted form. Just post them in a standard location. This is to get rid of the fiction that these are ever private and to eliminate an incentive to break in.

Isn't that more or less what blockchain-based encrypted storage is? I feel like I saw an HN post on something like that within the last couple months.

Re: I mean, why not tell everyone our password hashes?

#24

Post by jackjeff »

It's hard to imagine worse, except maybe putting the passwords in the clear...

Single unsalted broken MD5 is a far cry from scrypt... and even scrypt is probably a bad idea with all this crypto currency hashing hardware out there, unless you have a seriously strong password.

Just don't publish hashes.

Re: I mean, why not tell everyone our password hashes?

#25

Post by ht85 »

pmarreck wrote: post #13

a simple unsalted hash wouldn't work due to rainbow-tabling, and even a salted hash would be vulnerable to someone gaining unauthorized access to the salt and regenerating a rainbow table with it (although if one used bcrypt, that might be practically impossible)

That's why you always want to generate a different salt for each password, which fully prevents rainbow table attacks.

Re: I mean, why not tell everyone our password hashes?

#27

Post by orblivion »

Glyptodon wrote: post #23
lucasgonze wrote: post #2

That inspired this idea: make all password databases public, in an encrypted form. Just post them in a standard location. This is to get rid of the fiction that these are ever private and to eliminate an incentive to break in.

Isn't that more or less what blockchain-based encrypted storage is? I feel like I saw an HN post on something like that within the last couple months.

Isn't that more of public key crypto? So the secret isn't just a password, but also a key. I think it'd be a lot harder to crack.

Really it points to the idea that we should be moving in that direction for auth. Here's one project I've heard about: https://www.grc.com/sqrl/sqrl.htm

Re: I mean, why not tell everyone our password hashes?

#28

Post by tobyjsullivan »

w8rbt wrote: post #11

It depends on the hash type. Cryptographic hashes (MD4, SHA1, SHA256, etc.) are made to be efficient and fast to compute while password hashes (bcrypt, scrypt, etc.) are much more difficult to compute. The difference is staggering. john --test --format=nt Benchmarking: NT [MD4 128/128 X2 SSE2-16]... DONE Raw: 29037K c/s real, 29037K c/s virtual john --test --format=bcrypt Will run 16 OpenMP threads Benchmarking: bcry…

Password "hashes" are generally just cryptographic hashes run multiple times (known as key stretching). Cryptographic hashes are also designed to be slow. A key stretching algorithm will only be slow if the underlying cryptographic hashes are sufficiently slow.
Post reply on HN