Live data from Hacker News

I mean, why not tell everyone our password hashes?

theobsidiantower.com

151–160 of 167 posts

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

#151

Earlier quoted context omitted.

In reality while that would be really easy to crack (measured in minutes as others pointed out). However, any possible password with a standard printable ASCII character set will typically be found in Rainbow tables up to 10 characters long making expensive cracking unnecessary. [not quite right see edit] Rainbow tables are just giant tables where the key is the hash and the value is the string that generated it. How…

If you know the md5 hash, why not login with another password that generates the same hash value? Does it actually need to be the same passord?

That's called a collision

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

#152
post #114

Earlier quoted context omitted.

We can't really store that many passwords. It's even just 30^14 = 500 exabytes per byte and MD5 is 16 bytes at a minimum so you need 8000+ exabytes = 8,000,000,000+ Terabytes. Note: only "In the third quarter of 2016, approximately 144.6 million hard disk drives were shipped worldwide" aka something like all HDD ever produced might fit that much data. PS: Plus that 30 was low balling for a full search space it's 26 (…

There's no need to store anything. You have a list of hashes you'd like to reverse. You compute the entire search space and compare each. No storage, other than the hashes you're attempting to reverse -- which for a data dump from even a large site like Yahoo wouldn't be very large at all. Megabytes.

Not at the same hash rate. Sure you can do binary search, but 100^14 or even 30^14 such searches is not fast. So, it's about as fast if you want 2 passwords but not 2 billion passwords.

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

#153
post #114

Earlier quoted context omitted.

We can't really store that many passwords. It's even just 30^14 = 500 exabytes per byte and MD5 is 16 bytes at a minimum so you need 8000+ exabytes = 8,000,000,000+ Terabytes. Note: only "In the third quarter of 2016, approximately 144.6 million hard disk drives were shipped worldwide" aka something like all HDD ever produced might fit that much data. PS: Plus that 30 was low balling for a full search space it's 26 (…

You don't have to store all of the possible passwords, just the hashes for all of the real passwords that you are trying to crack.

If you mean after generating a hash you can compare it to your list of hashes then that saves time for cracking every password, but it's slower than cracking one password. Assuming you wanted to crack every Facebook password this way, that's not going to fit into cache and a binary search into RAM is actually rather slow. Yea, you could have more computers doing just this, but it's much slower than computing the hash in the first place.

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

#154

Earlier quoted context omitted.

For now. https://www.keylength.com/en/compare/ Why risk it when generating an ed25519 or rsa4096 keypair is cheap?

The same logic would apply to an 8192 bit key. One more bit doubles the key space. Someone who is be able to crack 2048 bit keys, probably also has the opportunity to crack 4096 bit keys. It may not be cheap for your communication partners to use your 4096 bit key. Smartphones and embedded devices want to use as less energy as possible. With an 4096 bit key, you force your communication partners to spent an unnecessa…

[deleted]

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

#155

One reason: you'd be surprised how many companies allow entering the hash as an alternative password to login to customers' accounts in production. Lazy method for customer support teams who don't have support tools to access customer information. Also frequently done to allow developers to debug problems on a customer's account when a bug cannot be reproduced elsewhere. If such a company's database of hashed passwor…

[deleted]

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

#156

Earlier quoted context omitted.

"Very easy to crack this! You just need a bajillion dollars, 5000 AWS instances and a couple minutes!" Not surprised why no one tried yet.

I think it's a reasonable point. There's lots of armchair experts saying that md5 is broken, unusable, and anyone can reverse it, and here we are 14 hours later and nobody has proven it. Given that the claim was 12 minutes on a 25 machine cluster, that would imply 300 minutes of compute time which is 6 hours. This is hacker news, if it's not going to be done here, then no armchair enthusiasts are going to do it. If s…

https://hashcat.net/hashcat/

I haven't used it, but FAQs, Forums, wikis, and tutorials are all out there.

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

#157
post #152

Earlier quoted context omitted.

There's no need to store anything. You have a list of hashes you'd like to reverse. You compute the entire search space and compare each. No storage, other than the hashes you're attempting to reverse -- which for a data dump from even a large site like Yahoo wouldn't be very large at all. Megabytes.

Not at the same hash rate. Sure you can do binary search, but 100^14 or even 30^14 such searches is not fast. So, it's about as fast if you want 2 passwords but not 2 billion passwords.

[deleted]

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

#158
post #152

Earlier quoted context omitted.

There's no need to store anything. You have a list of hashes you'd like to reverse. You compute the entire search space and compare each. No storage, other than the hashes you're attempting to reverse -- which for a data dump from even a large site like Yahoo wouldn't be very large at all. Megabytes.

Not at the same hash rate. Sure you can do binary search, but 100^14 or even 30^14 such searches is not fast. So, it's about as fast if you want 2 passwords but not 2 billion passwords.

It wouldn't be a binary search, the values are already hashes, so you could do a hash table lookup very cheaply. MD5 isn't great by cryptological standards, but it is extremely robust by hash table standards.

While no extra resources might not have been strictly accurate, the lookup would be practically free compared to the time it takes to compute the hash.

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

#159
post #153

Earlier quoted context omitted.

You don't have to store all of the possible passwords, just the hashes for all of the real passwords that you are trying to crack.

If you mean after generating a hash you can compare it to your list of hashes then that saves time for cracking every password, but it's slower than cracking one password. Assuming you wanted to crack every Facebook password this way, that's not going to fit into cache and a binary search into RAM is actually rather slow. Yea, you could have more computers doing just this, but it's much slower than computing the hash…

You wouldn't need to do a binary search. The values are already MD5 hashes. You could do a hash table lookup in just a few CPU cycles since computing the hash is free.

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

#160

Earlier quoted context omitted.

In reality while that would be really easy to crack (measured in minutes as others pointed out). However, any possible password with a standard printable ASCII character set will typically be found in Rainbow tables up to 10 characters long making expensive cracking unnecessary. [not quite right see edit] Rainbow tables are just giant tables where the key is the hash and the value is the string that generated it. How…

If you know the md5 hash, why not login with another password that generates the same hash value? Does it actually need to be the same passord?

It will work but a common reason to crack passwords is because people use the same password on multiple sites. Getting the wrong value may work to log into that specific site but will not work where the user the real password elsewhere. (unless that other place is using the same hash algorithm)
Post reply on HN