81–90 of 167 posts
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…
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 ;)
Needs more FIPS to be enterprise ready.
I was kind of disturbed that GitHub publishes every user's public key. https://developer.github.com/v3/users/keys/ This is a different situation and public keys are not directly analogous to password hashes: there isn't a reliable way of cracking public keys in the same sense that there's a semi-reliable way of cracking hashes. But it was still strange and uncomfortable to me that they would reveal this "target" (and…
If you prefer plain-text format, this is available at: https://github.com/ .keys
Earlier quoted context omitted.
I disagree. The design intention of public keys is not that they should be published along with a mapping to the user's identity, without the user's consent. It's that they may be published, or eavesdropped, without breaking the cryptography itself. See here[0] for the privacy-violating consequences of publishing public keys and identities wholesale. [0] https://news.ycombinator.com/item?id=10004678
That's not a failure of public key cryptography, that's a failure of the SSH protocol. As you say, public keys were designed to solve a key distribution problem. Inherent to that problem is the idea that a public key could become, well, public. They solve that problem very well, and there is no intrinsic reason why you shouldn't just publish them because they were intended to be defensible against that very eventuali…
But Github is using public key cryptography as implemented in SSH - if that has a failure, Github should take some blame for not working around it, especially when they are going out of their way to expose data that has little benefit IMO.
Anyway, SSH is orthogonal to one of my points, which, phrased another way, is that publishing the link between two identities (the key itself, and the key-owner's Github profile) without consent or need is unethical because it violates the privacy of the owner. I believe there is precedent in the PGP world (e.g., "I believe it's poor etiquette to upload someone else's key to a keyserver as you deny them that choice."[0])
I sort of get the "detrimental to other protocols" and "lazy security for the SSH protocol" points, but when you talk about publishing public keys, do you acknowledge a difference between "key XYZ is in use on Github" and "key XYZ identifies user ABC on Github"? I'm saying the latter is unwise and unkind, and it would be even if the SSH protocol didn't have this particular failure.
PSA to everyone responding to the title: please RTFA, it's sarcasm.
No, by all means share the MD5 hash of your passwords. After all it's a one way hash. /S
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 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 ;)