ELI5
I mean, why not tell everyone our password hashes?
111–120 of 167 posts
Re: I mean, why not tell everyone our password hashes?
#112Earlier 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
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.
However, your example being 14 characters long is a bit long to be in most readily available rainbow tables.
This is why using salts and peppers are incredibly important regardless of what hash you use.
Edit: minor(ish) correction to the previous sentence. Full alphanumeric with punctuation and digits is available readily in smaller password lengths but the 10 character long datasets seem to be mostly only lower case characters and digits.
Re: I mean, why not tell everyone our password hashes?
#113Earlier quoted context omitted.
Small private company, nobody's ever heard of it. There are a lot of shady ones out there.
Agree. MANY small development shops will build these kinds of backdoors into systems because they don't have the skill or the resources to build proper customer support features.
Re: I mean, why not tell everyone our password hashes?
#114Earlier quoted context omitted.
Uhh, 14 characters long. Call it even ~30^14 / 348 billion per second = 1,374,416,379 seconds. So, they can break passwords with some pattern to them, but not really brute force em.
That's only 43 years and it was only 25 GPUs. Bump that up to 12000 GPUs and you could do it in about a month. It's also an unsalted hash, so you could brute force an unlimited number of passwords at the same time without additional resources. Someone with a budget of a few million dollars could break every password in the world in a month. So in other words, definitely don't publicize unsalted MD5 hashes of your pas…
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 (lower case letters) + 26 (upper case letters) + 10 (numbers) + some number of special characters. So, ~100^14 or ~20,907,515x as large aka 10^17 TB.
Re: I mean, why not tell everyone our password hashes?
#115Earlier quoted context omitted.
Uhh, 14 characters long. Call it even ~30^14 / 348 billion per second = 1,374,416,379 seconds. So, they can break passwords with some pattern to them, but not really brute force em.
Keep in mind article is from 5 years ago.
Re: I mean, why not tell everyone our password hashes?
#116That 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.
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 ;)
Re: I mean, why not tell everyone our password hashes?
#117Earlier quoted context omitted.
> Password "hashes" are generally just cryptographic hashes run multiple times (known as key stretching) 1. Password hashing functions are not regular hash functions run multiple times. This is not only false at a macro level (i.e. we don't just run SHA-2 several times to get something resembling PBKDF2), it's false in terms of core construction. Password hashing functions rely on fundamentally different mathematical…
Well that was embarrassing. Thanks for the corrections! There's a Wikipedia line that could use your input (unless I'm missing why this would still be accurate). > Key stretching functions, such as PBKDF2, Bcrypt or Scrypt, typically use repeated invocations of a cryptographic hash to increase the time required to perform brute force attacks on stored password digests. https://en.wikipedia.org/wiki/Cryptographic_hash…
This is not false, it is indeed one of the techniques that they use.
Re: I mean, why not tell everyone our password hashes?
#118Earlier quoted context omitted.
Wouldn't you want to use a salt instead?
You use the 'salt' as the key in the keyed hash. The difference occurs mostly when you start chaining hashes. In that case, a salt is only relevant in the first hash, whereas the keyed hash needs the key at every hash round.
I thought the two schemes were conceptually different, leading to different engineering tradeoffs: With salts, you assume the attacker can gain access to it. With keyed-hashing, you simply have a second piece of equally-secret information, and you hope it doesn't get leaked.
Re: I mean, why not tell everyone our password hashes?
#119Earlier quoted context omitted.
You can have a GitHub specific ssh key. ssh-keygen -q -t rsa -b 4096 -N "passphrase" -C "mygithub@someaddress.org" -f ${HOME}/.ssh/.ghub then in your ${HOME}/.ssh/config IdentitiesOnly yes Host github.com Hostname ssh.github.com Port 443 User git IdentityFile /home/username/.ssh/.ghub ForwardAgent no Not that it matters in this case, just sayin'.
2048 is enough.
Why risk it when generating an ed25519 or rsa4096 keypair is cheap?