10 ms·
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
by lucasgonze 9y ago
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.
- prostoalex 9y agoMake it blockchain-based, and you'll likely have some VC funding by tomorrow morning.
- tertius 9y agoCollisions?
- MereInterest 9y agoA non-issue with salts.
- velox_io 9y agoIn theory it could happen.. but something like this is strengthened through password stretching. I think this is good practice anyway as it makes them much harder to brute force/ dictionary attack if the data compromised.
- kogepathic 9y ago> make all password databases public, in an encrypted form That is a terrible idea because agencies like the NSA or GCHQ with unfathomable resources and techniques will crack them and never tell anyone. Then you'll have a compromised account, the provider won't know, the user won't know. Then the agency would be able to compromise the account a publish whatever they wanted as that identity. Given there are tricks to mask an IP address, or they straight up tap the wires, that's a #1 way to character assassinate any dissident or someone who they dislike. > This is to get rid of the fiction that these are ever private and to eliminate an incentive to break in. And why do you assume criminals wouldn't also try to gain access to the systems? Passwords aren't typically the valuable information in a system, they're there to protect the more valuable data.
- ceejayoz 9y ago> That is a terrible idea because agencies like the NSA or GCHQ with unfathomable resources and techniques will crack them and never tell anyone. Chances are they already have 'em, from a compromised employee, a zero-day exploit, or a SQL injection hole. Far more likely than them having cracked bcrypt.
- throwaway2048 9y agoI doubt they have exploited every single password DB in existence.
- tbodt 9y agoIf they want it, they can get it.
- sirclueless 9y agoThat's still a better status quo than passively having access to all of it.
- bdamm 9y agoGiven what we know about older techniques, it's safe to assume that many intelligence agencies hold zero-days for most popular network and server gear. From my personal experience interacting with some of the people who use these tools, exploiting networks is neither free nor particularly difficult.
- LinuxBender 9y agoThey were being sarcastic.
- ben_jones 9y agoThe foundation of modern ecommerce rests on the belief that your credit card information won't be stolen and used to cause great harm. Similar belief systems exist for online dating, social media, etc.
- deleted 9y ago[deleted]
- saulrh 9y agoThat's what I thought when I read the title. There's probably some reason it wouldn't work. Dictionary attacks are an obvious possibility; if your password is "password" the only thing you're depending on is nobody being able to get at the hashes. It might also expose password reuse, though nonces/salts might solve that. Hrm. This smells a bit like public crypto - public database of public keys (hashes), on login you're challenged to produce proof that you have the private key (the password), and the transformation provides you a means to do that without exposing the private key itself.
- recursive 9y agoIf you're using a keyed hash, then dictionary attacks can't be parallelized.
- Terr_ 9y agoWouldn't you want to use a salt instead?
- rocqua 9y agoYou 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.
- Terr_ 9y ago> You use the 'salt' as the key in the keyed hash. 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.
- Glyptodon 9y agoIsn'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.
- orblivion 9y agoIsn'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 https://www.grc.com/sqrl/sqrl.htm
- ficklepickle 9y agoSQRL ftw! It's gonna take off any day now. That guy is prolific! Seriously though, that's the first un-ironic reference to SQRL that I've ever seen.
- CiPHPerCoder 9y agoInstead 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 ;)
- tedunangst 9y agoNeeds more FIPS to be enterprise ready.
- tentaTherapist 9y agoNeeds more IPFS to board the hype train.
- CiPHPerCoder 9y agoOkay, let's throw in an invalid curve attack vulnerability and call it even. I'll contact NIST for a grant. Let's get this ball rolling!
- nathancahill 9y agoAs long as you call it a blockchain, I'm in!
- homakov 9y agoYes, KDF->pubkey seems like only sane way forward. Any discussion over old school passwords is a waste of time.
- snakeanus 9y agoWhy Argon2id? Isn't Argon2i what the creators suggest?
- CiPHPerCoder 9y agoSufficient 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.
- deleted 9y ago[deleted]
- Buge 9y agoThat's essentially what brainwallet did. Your bitcoin private key was deterministicly generated by your password. So using a list of common passwords, private keys could be pregenerated by attackers. So anyone who "created" a brainwallet with a weak password would get their money stolen the second they deposited it. Brainwallet got so much hate from people that used weak passwords and got their money stolen that it was shut down.