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

131–140 of 167 posts

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

#131

Post by morecoffee »

Godel_unicode wrote: post #130
morecoffee wrote: post #126

Earlier quoted context omitted.

Any medium really. Rainbow tables are compressed (by throwing away most of the hashes). The amount you throw away determines how long it takes to crack. For example, A rainbow table might use chain lengths of 10,000. This means that for every 10,000 hashes calculated, only 1 (really 2) are kept. Each chain ends up as a row in the table, which is then sorted. When cracking, the target hash is hashed and reversed up to…

An md5 rainbow table for lower alphanumeric which covers passwords of length 9 is 63gb. Length 10 is 316gb. You can see where this is going. It's important to note the caveat upfront; lower case-only plus numbers. No upper case, no symbols. http://project-rainbowcrack.com/table.htm

That is just a rainbow table, but there are many others. By modifying the chain length, you can make the table as arbitrarily small. The example commands on that site use a chain length of 3800, but it could be raised to 1 million.

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

#132

Post by Jakawao »

LeoPanthera wrote: post #88
nickh9000 wrote: post #64

Earlier quoted context omitted.

No, by all means share the MD5 hash of your passwords. After all it's a one way hash. /S

It's my understanding that even an MD5 hash of a not-terrible password is still virtually impossible to crack, is that wrong? Here's an md5 sum of a not-that-great password I just made up. It's 14 characters long, but has plenty of guessable features. Is it crackable? 1cf016ea3cb1f2aa2ccb59c196d0e704

hunter2hunter2

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

#133

Post by mort96 »

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)

There's not really such a thing as "gaining unauthorized access to the salt" when you already have the hash; the salt is just as secret as the hash, and the hash is useless as a means of authentication without the salt, so obtaining the hash, unauthorized or not, generally also means you obtain the salt. Libraries for algorithms like scrypt even usually give you one string which contains both a random salt and a hash.

You can regenerate a rainbow table which uses that salt, but you'd have to generate a rainbow table for every password, since each password has its own random salt. I don't know how rainbow tables work exactly, but I'd assume an old fashioned brute force attack or dictionary attack is cheaper than making a rainbow table for each password.

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

#134

Post by CiPHPerCoder »

tatersolid wrote: post #125
CiPHPerCoder wrote: post #39

Earlier quoted context omitted.

Instead of password hashes, why don't we just use Argon2id as a KDF to produce an Ed25519 keypair, and then publish the (salt, memcost, opscost, Ed25519 public key)? I can throw this into a structure indistinguishable from a blockchain if any VCs want to invest ;)

You've just described SQRL

No I haven't. I didn't invent PBKDF2-Scrypt along the way.

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

#135

Post by [deleted] »

nhumrich wrote: post #110
seiferteric wrote: post #99

Earlier quoted context omitted.

Don't forget spinning up an AWS cluster for 12 mins would not cost too much.

Well, you would pay for the full hour regardless of how long the machines were up. GCP would give you too the minute pricing however. But your right, even a full hour is really cheap

[deleted]

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

#136

Post by CiPHPerCoder »

snakeanus wrote: post #116
CiPHPerCoder wrote: post #39

Earlier quoted context omitted.

Instead of password hashes, why don't we just use Argon2id as a KDF to produce an Ed25519 keypair, and then publish the (salt, memcost, opscost, Ed25519 public key)? I can throw this into a structure indistinguishable from a blockchain if any VCs want to invest ;)

Why Argon2id? Isn't Argon2i what the creators suggest?

Sufficient side-channel resistance for real world uses, sufficient GPU resistance. It's the best of both worlds. It's also going to be the libsodium default in the next release.

It's literally two passes that are memory independent, then two that are memory dependent, when r = 4.

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

#137

Post by yjftsjthsd-h »

ademarre wrote: post #98
ewzimm wrote: post #82

As you might have guessed, my password hash is password.

Were this true, you would have achieved a pre-image attack.

I like to think that if I ever gained the ability to execute preimage attacks, solve P=NP, etc. I would use it to troll everyone by making my passwords hash into "password", grabbing heylookicrackedpublickeyencryption.onion, and emailing prominent security researchers messages signed with their own keys.

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

#138

Post by LeoPanthera »

Jakawao wrote: post #132
LeoPanthera wrote: post #88

Earlier quoted context omitted.

It's my understanding that even an MD5 hash of a not-terrible password is still virtually impossible to crack, is that wrong? Here's an md5 sum of a not-that-great password I just made up. It's 14 characters long, but has plenty of guessable features. Is it crackable? 1cf016ea3cb1f2aa2ccb59c196d0e704

hunter2hunter2

No. Just for reference. :)

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

#139

Post by analogist »

LeoPanthera wrote: post #88
nickh9000 wrote: post #64

Earlier quoted context omitted.

No, by all means share the MD5 hash of your passwords. After all it's a one way hash. /S

It's my understanding that even an MD5 hash of a not-terrible password is still virtually impossible to crack, is that wrong? Here's an md5 sum of a not-that-great password I just made up. It's 14 characters long, but has plenty of guessable features. Is it crackable? 1cf016ea3cb1f2aa2ccb59c196d0e704

That's pretty much correct, yeah. Due to exponentiation, length is almost everything in password security. Which means there's going to be a bunch of lengths at which brute force cracking is trivial, and then a very sharp rise in complexity, after which brute force cracking quickly becomes astronomical, and then absolutely impossible.

If you look at the current cracking benchmarks of GPUs (https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...), there is an easily quantifiable difference between bcrypt and MD5: 21 bits. (https://www.wolframalpha.com/input/?i=log2(200*%5E9)-log2(10...)

That means under current GPU architecture, bcrypt is basically like "adding 3-4 characters (or 1.5 diceware words)" for free to your password. Can you basically just add 3-4 characters to your password? Sure, but not without user friction, and certainly you can't think that way as the developer of the system, because you're trying to give a small leg up to even the most vulnerable by salting and bcrypt/PBKDF2/Argon hashing.

What about theoretical limits? Well, there is another way to approach this: Landauer's principle (https://en.wikipedia.org/wiki/Landauer%27s_principle), which considers the theoretical minimum energy of a bit flip of information - so this even covers future computing technologies. Even if you used up all available mass-energy in the entire sun, it is only theoretically possible to perform 2^225.2 operations (https://security.stackexchange.com/questions/6141/amount-of-...). 225 bits of entropy is roughly a 35-character (printable ASCII) password.

(Note that you can't do this with MD5 - it has only a 128-bit hash space, before preimage attacks, the best of which lowers it to 123 bits).

So the lesson is: use slow hashes to give some protection to the vulnerable and people whose password complexity is "on the edge". Use a password manager so that the rest of your passwords can be comfortably > 128 bits in complexity, without reuse. And then forget about passwords because after that, every other part of the security system becomes more important.

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

#140

Post by code_duck »

joshfraser wrote: post #120

Stupid question, but what does this particular password hash unlock?

I was wondering, too. From the article,

>"I hope like me you were immediately drawn to the ‘auth’ fields. As the name implies this field contains authentication information for controlling this object in the RIPE database. RIPE supports a couple of different auth types like Single Sign On (SSO), public key cryptography, and of course md5."

It's authentication to manage that entry in the RIPE database.

Post reply on HN