9 ms·
I mean, why not tell everyone our password hashes?
- lucasgonze 9y agoThat 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.
- justin_vanw 9y agoNah, why even give an inch? Yes, if you properly deal with passwords, the artifact you store gives virtually no information to an attacker, but on the other hand, why give them even almost nothing?
- ThePhysicist 9y agoNice, they even have a rest API and web form to update the information: https://www.ripe.net/manage-ips-and-asns/db/support/updating-the-ripe-database https://www.ripe.net/manage-ips-and-asns/db/support/updating...
- eveningcoffee 9y agoBecause your password is part of your identity and is actually used to cross check during identity matching.
- ceejayoz 9y agoLeaving aside the fact that changing my password doesn't mean I have a new identity, having the hash $2y$10$/Aglzm2zpHO7m1dIv5vSp.GHPUd1D8uODn/jtBv3gpe8yS5e/D9PW doesn't tell you my password is "tinkerbell".
- Ajedi32 9y agoIf your password is "tinkerbell", even an attacker with very few resources can probably crack the hash for it in seconds on their desktop PC.
- eveningcoffee 9y agoIn these kind of checks nobody cares what your password is. Only if it is the same as you are using somewhere else. So hash, unless properly salted, works works very fine. Many people actually use a single password everywhere. Or at least for similar things.
- w8rbt 9y agoIt depends on the hash type. Cryptographic hashes (MD4, SHA1, SHA256, etc.) are made to be efficient and fast to compute while password hashes (bcrypt, scrypt, etc.) are much more difficult to compute. The difference is staggering. john --test --format=nt Benchmarking: NT [MD4 128/128 X2 SSE2-16]... DONE Raw: 29037K c/s real, 29037K c/s virtual john --test --format=bcrypt Will run 16 OpenMP threads Benchmarking: bcrypt ("$2a$05", 32 iterations) [Blowfish 32/64 X3]... (16xOMP) DONE Raw: 5472 c/s real, 490 c/s virtual Edit: NT hashes are one round of MD4. These are Microsoft Active Directory hashes. OpenBSD uses Blowfish hashes by default.
- LinuxBender 9y agoWhat numbers does your rig give using hashcat and your video card?
- deleted 9y ago[deleted]
- tobyjsullivan 9y agoPassword "hashes" are generally just cryptographic hashes run multiple times (known as key stretching). Cryptographic hashes are also designed to be slow. A key stretching algorithm will only be slow if the underlying cryptographic hashes are sufficiently slow.
- dsacco 9y ago> 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 properties than regular hash functions. It's not like 3DES and DES: a secure password hashing function requires more than just a higher iteration count. 2. "Key stretching" does not refer to running cryptographic hash functions multiple times. Key stretching refers to the act of generating a secret key from an otherwise weak passphrase or input, generally supplied by a user. You use the user's passphrase to (in effect) seed a function that outputs something much more resistant to brute-forcing. Key stretching is used in key derivation functions, but what you described is not key stretching. 3. General purpose (as opposed to password) hashing functions are designed to be fast, not slow. Take a look at BLAKE2's homepage for speed comparisons - speed is a selling point: https://blake2.net/ https://blake2.net/. In addition you can read the following from the handy FAQ: You want your hash function to be fast if you are using it to compute the secure hash of a large amount of data, such as in distributed filesystems (e.g. Tahoe-LAFS), cloud storage systems (e.g. OpenStack Swift), intrusion detection systems (e.g. Samhain), integrity-checking local filesystems (e.g. ZFS), peer-to-peer file-sharing tools (e.g. BitTorrent), or version control systems (e.g. git). You only want your hash function to be slow if you're using it to "stretch" user-supplied passwords, in which case see the next question.
- pmarreck 9y agoa 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)
- ht85 9y agoThat's why you always want to generate a different salt for each password, which fully prevents rainbow table attacks.
- mort96 9y agoThere'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.
- developer2 9y agoOne 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 passwords is leaked, then an attacker doesn't even have to crack the hashes - the hash itself is a valid version of the password. Yet I've seen this behavior at multiple companies; only one of them pushed back against my request to remove that "feature", and I didn't stay with them much longer after that.
- cestith 9y agoWhat would it take to get you to name and shame? That whistle pretty likely needs to be blown on the one that didn't agree to abandon such a policy.
- developer2 9y agoSmall private company, nobody's ever heard of it. There are a lot of shady ones out there.
- toss1829654 9y agoMicrosoft Windows does this. NT hashes are password equivalent: https://en.wikipedia.org/wiki/Pass_the_hash https://en.wikipedia.org/wiki/Pass_the_hash
- basseq 9y agoSure, in an ideal world: post the hashes, the salts, the hash algorithm, everything. If it's done "right" (e.g., the hash function has enough complexity), then brute force cracking, rainbow tables, etc. would take so long that it wouldn't be feasible to crack them with any volume. Of course, you could still crack some (problem), so keeping multiple secrets hidden through obscurity (the hashes, the salts, etc.) is another layer of security. This doesn't guarantee security, but it's certainly more secure. But it is additive: there's no reason to just use MD5 (or plaintext) because "my hashes are secret".
- jackjeff 9y agoIt's hard to imagine worse, except maybe putting the passwords in the clear... Single unsalted broken MD5 is a far cry from scrypt... and even scrypt is probably a bad idea with all this crypto currency hashing hardware out there, unless you have a seriously strong password. Just don't publish hashes.
- quickthrower 9y agoThe article agrees with you.
- delegate 9y agoIt's also nice enough to mention the hashing algorithm used - MD5, just so you don't have waste time guessing.
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- jjguy 9y agoPSA to everyone responding to the title: please RTFA, it's sarcasm.
- nickh9000 9y agoNo, by all means share the MD5 hash of your passwords. After all it's a one way hash. /S
- LinuxBender 9y agoEven SHA512 and bcrypt, totally uncrackable! /S
- Qub3d 9y agoEvery time someone says or writes "bcrypt", the GPU prices go up $10.
- LinuxBender 9y agoGotta keep those hashcat farms in business :-)
- LeoPanthera 9y agoIt'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
- throwaway76543 9y agoYes, that is incorrect. A GPU accelerated tool like HashCat can crack that password with a fairly small hardware footprint. Here's an article involving a 25 machine cluster which would reverse your hash in about 12 minutes -- regardless of your password features. http://www.zdnet.com/article/25-gpus-devour-password-hashes-at-up-to-348-billion-per-second/ http://www.zdnet.com/article/25-gpus-devour-password-hashes-... This isn't nation-state level cost. Individuals could afford this level of hardware. Many individuals have access to systems of this size, for example through botnets, schools, spare junk in the local IT department closet, etc. It's very reversible.
- schoen 9y agoI was kind of disturbed that GitHub publishes every user's public key. https://developer.github.com/v3/users/keys/ 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 there were specific key generation bugs, like RNG seeding errors, people might actually be able to crack a few of them and know that they had suceeded). Relatedly, I was thinking about the magic crypto-cracking device in the movie Sneakers. Once they had it, they could immediately use it to log on to random network-connected services, defeating the authentication. So, how is that supposed to work? How do they automatically know what credentials would be accepted for a particular service? Are there common network authentication protocols based on public-key cryptography that have the property that the verifier tells the prover the public keys that it trusts?
- problems 9y agoI wouldn't really say this is significant in an attack sense - you need to reveal your public key to engage in many types of secure communication, SSL throws these around all day as does any private messaging app, PGP, SSH servers, etc. The entire point of a public key is that it is public, password material on the other hand is not, it's meant to be a shared key between you and the other party. The only bad thing about the GitHub issue there is that a de-anonymization attack is possible as an SSH server will tell you if it accepts a given public key... if, say you had the same SSH key on your GitHub account and a server you wanted to keep private, this could be bad to say the least. And SSH clients offer every id_* key to every server they connect to, so if you connect to an untrustworthy server, even over an anonymity network like Tor your client may offer a key that identifies you (use your ssh config!).
- etaty 9y agoIf I remember, SSH server don't share the public key it accepts. Your SSH agent will try all your key one by one (you can change this behaviour with custom config)
- zpallin 9y agoShots fired. That ending was an incredibly well delivered stab at Deutsche Telekom. This is why I love vigilante security.
- cerved 9y agoELI5
- dentemple 9y agoTL;DR Don't tell people your passwords, even if they're "obscured" by a hashing algorithm.
- komali2 9y ago>whois -h whois.ripe.net DTAG-NIC Wait, was that just a straight bash command? Is this installed on my computer? >$ whois usage: whois [-aAbdgiIlmQrR6] [-c country-code | -h hostname] [-p port] name ... Holy shit lol, that's neat.
- clarry 9y ago> Wait, was that just a straight bash command? Is this installed on my computer? Welcome to 1982..1985. This command predates bash. https://tools.ietf.org/html/rfc812 https://tools.ietf.org/html/rfc812 http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/src/ucb/whois.c http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/src/ucb...
- deleted 9y ago[deleted]
- ewzimm 9y agoAs you might have guessed, my password hash is password.
- ademarre 9y agoWere this true, you would have achieved a pre-image attack.
- yjftsjthsd-h 9y agoI 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.
- igonvalue 9y agoWhat exactly are these passwords used for? The post mentions "controlling this object in the RIPE database" but I'm missing some context necessary to understand that.
- someone_elses 9y agoBasically you can take ownership of their IP ranges, modify routing information, etc. Even if you took a small percentage of the IP addresses in Europe, this could have a snowball effect. You take the IP addresses belonging to a popular mail service used by other domains, then you use admin email addresses to reset and eventually Europes internet is stolen.
- jbg_ 9y agoIt's not quite that simple. The RIPE database stores mostly administrative information, and doesn't _directly_ affect Internet routing. In order to "steal" IP addresses (get them routed to you) you would need to buy a connection to at least one exchange point, probably several if you want all the traffic for the target to route to you and not just some traffic from some networks. You'd need to buy rackspace somewhere with a connection to the exchange point, install routers, establish BGP peerings with the exchange point (if they're doing route reflection) or with all the other major networks at the exchange. There are multiple steps along the way where humans would look at the prefixes you were going to be announcing. This would include looking them up in RIPE, but anything more than a cursory inspection would likely reveal your ruse. At this point it becomes more of a social engineering attack, and even if you got as far as announcing it, there are things like BGPMon that would pick up the fraudulent announcement pretty quickly and you'd likely find that the cable was pulled out of your router pretty fast.
- someone_elses 9y agoThank you!
- pishpash 9y agoPasswords are broken for precisely this reason. You are operating under the fiction that permanently handing over entropy from a limited source to an untrusted party, even through a (for a time) one-way function, is ever a good idea. Please do make all password hashes public. It will finally force the move away from passwords.
- rdl 9y agoThe PGP option has been the preferred option for as long as I can remember (circa 2000).
- joshfraser 9y agoStupid question, but what does this particular password hash unlock?
- code_duck 9y agoI 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.
- royce 9y agoThreads discussing rainbow tables are not applicable. These hashes are not unsalted MD5. They are md5crypt ($1$[salt]$[hash]), as found in many Unix-likes and some Cisco IOS.