Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Pwned Passwords" V2 With Half a Billion Passwords

troyhunt.com

Post reply on HN
Print view View original

221–230 of 369 posts

Re: "Pwned Passwords" V2 With Half a Billion Passwords

#221

Post by SlowRobotAhead »

scrollaway wrote: post #27

[Pasting an old comment of mine on password managers, since I see people talking about starting to use Keepass. I hope this helps someone] ---- If you're just starting, here's some guidance on setting up a password manager. First of all: Don't be afraid of using one. It's not just more secure, it's super convenient. Never again will you ask yourself: Did I make an account for this website/service? What email did I us…

That’s good info with one exception. You are probably ok with Keepass, but for most people I’d MUCH sooner recommend a solution that can not be done wrong.

LastPass is my go to for most people. It simply can not be set up wrong or confusing. The same can’t really be said for keepass.

Re: "Pwned Passwords" V2 With Half a Billion Passwords

#222

Post by odammit »

MBCook wrote: post #210
ravenstine wrote: post #165

Earlier quoted context omitted.

I think this is intended for the case where a database has been compromised, but then again, I thought that hash algorithms and salting were supposed to deal with that.

IF people actually do that correctly, yes. But history has proven many sites (big and small) are quite happy to send you your plaintext password.

Although it does happen that’s amature and unacceptable.

Either you have some EXTREME legacy or lazy engineers. Doing it right doesn’t take long.

Re: "Pwned Passwords" V2 With Half a Billion Passwords

#223

Post by odammit »

rphlx wrote: post #166
odammit wrote: post #162

If you spend the time building a system to search those half billion passwords when you’re users are signing up, you should focus on building a login rate limiting system so it’s not possible to brute force someone’s password.

Though I agree rate limiting should be done (and done carefully), it is not very effective in all cases. As just 1 example, a determined attacker who wants to pop any account can make 3 attempts on hundreds of thousands of accounts, using a unique IPv4 address per account, thanks to Windows & IoT botnets.

WAF, IP blacklists, naive bot detection[0] and why would a decent thresholding system allow for a single IP to fail multiple accounts in a short time period.

If you hit two valid accounts [1] with bad passwords in a few ACCEPTABLE_UNIT_OF_TIME, it’s captcha time.

Thresholding isn’t just action per IP it’s being smart about how people are going to attack your system. It requires thought and upkeep.

[0] Previous thoughts on bot detection: https://news.ycombinator.com/item?id=16182405

[1] Also, if your login identifier and your public “display names” (usernames) are the same thing, that is a disservice to your users’ security.

Re: "Pwned Passwords" V2 With Half a Billion Passwords

#224

Post by odammit »

royce wrote: post #164
odammit wrote: post #162

If you spend the time building a system to search those half billion passwords when you’re users are signing up, you should focus on building a login rate limiting system so it’s not possible to brute force someone’s password.

The purpose of a blacklist is multifold - to reduce the efficiency of an offline attack, in which the hashes are stolen and can be attacked at high speeds without rate limiting - as well as an online attack.

Sure and 10k will do fine otherwise “! I thh Cher;457?:25?//(5 we” is going to suck for you user login story.

Maybe salt your passwords, use some stretches, and a decent algorithm instead of MD5, SHA1, etc.

Also stay up on algorithms and roll your users over to new ones over time.

Re: "Pwned Passwords" V2 With Half a Billion Passwords

#225

Post by mikekchar »

mseebach wrote: post #101
scrollaway wrote: post #93

Earlier quoted context omitted.

> Don't do this. On the other hand, do do this, but be aware of the tradeoffs. I hate telling people not to do something. Most people just end up not turning 2FA on at all. My approach has converted many people from "one password reused everywhere, at best with variations" to KeepassXC unique passwords everywhere + 2FA and I classify that as a big win. The biggest benefit of TOTP 2FA isn't the "second factor" part, i…

I grant that it protects against phishing, but I would cautiously suggest that sites that are smart enough to enable 2FA are smart enough to salt/hash/bcrypt/whatever best practice their passwords, so leaks are neutered. It doesn't not protect, so to speak, but the protection is likely to be redundant. But it emphatically does not protect against keylogging, anyone who can install a keylogger on your computer can gra…

I'm not sure that 2FA is going to give the average person as much protection as you assume. You have to keep your 2FA key somewhere. So instead of needing your master password and password DB, you need the master password, password DB and 2FA key. But the question is how hard is it really to get that key? Certainly harder than having it in the password DB, but in practice, not really any harder than getting the password DB in the first place.

There are lots of options: using memorable passwords/passphrases, using random passwords, using cloud based password managers, using password managers on your own devices, putting the 2FA on the same device, putting it on a different device, putting the 2FA on an air-gapped device.

IMHO, only putting your 2FA on an air-gapped separate device gives you dramatically better protection in the areas you are concerned about. The rest of the conversation is really about where "good enough" lies -- and that depends entirely on what you are doing.

Re: "Pwned Passwords" V2 With Half a Billion Passwords

#226

Post by nightcracker »

KMag wrote: post #119
skykooler wrote: post #61

Earlier quoted context omitted.

Why does 0000 have the largest number of hashes? Does SHA-1 not distribute hash values evenly?

Non-uniformity in SHA-1 would be major news. Note that in the description below, I refer to any keyed involution as a block cipher. One may make a semantic distinction, but any keyed involution could be used as a block cipher (though, of course, most involutions would contain trivial cryptographic weaknesses). SHA-1 is based around a 160-bit unbalanced Feistel block cipher. The input in broken into blocks, where the…

Salsa/ChaCha does not halve the output and XOR it together, they add the input block to the output to get non-invertability.

Salsa/ChaCha also does not have a block cipher, just an unkeyed permutation function which is applied to the key plus a constant and counter.

Re: "Pwned Passwords" V2 With Half a Billion Passwords

#227

Post by kirillkh »

irrational wrote: post #199
swiley wrote: post #192

Earlier quoted context omitted.

Or people who love their moms are 3 times more likely to choose a bad password.

People who love their moms are less intelligent than those who love their dads? There is a dissertation in psychoanalytics just waiting to be written.

> There is a dissertation in psychoanalytics just waiting to be written.

Just don't wear a Hawaiian shirt while giving interview about it on TV.

Re: "Pwned Passwords" V2 With Half a Billion Passwords

#228

Post by KMag »

fhenneke wrote: post #44
jkaptur wrote: post #33

Earlier quoted context omitted.

I'm a bit confused - why not distribute a serialized Bloom filter representing these passwords? That would seem to enable a compact representation (low Azure bill) and client-side querying (maximally preserving privacy).

A Bloom filter with >500M items, even when allowing for a comparatively high rate of false positives such as 1 in 100, is still in the hundreds of MBs, which would not be that much more accessible than the actual dump files.

The compressed archive here is over 8 GB. An uncompressed 2 GB Bloom filter with 24 hash functions and half a billion entries has a false positive rate of less than 1 in 14 million.

75% space savings, with no decompression necessary for use, and a 1 in 14 million false positive rate is nothing to sneeze at.

Re: "Pwned Passwords" V2 With Half a Billion Passwords

#229

Post by prewett »

rspeer wrote: post #203
royce wrote: post #156

Earlier quoted context omitted.

As a corpus to download for password research, this is indeed useful. But for providing a blacklist -- his stated purpose - it is not. The crucial tell: his API does not allow the implementor to specify a frequency threshold (by top X in the list, or by Y number of unique uses of the password or higher). By both API and explicit language in the announcement, he is promulgating the idea that checking the entire blackl…

This list is small for the purposes of password-cracking. Enumerating 500 million things is something a computer can do very quickly. Consider this: if you store the hash of one of these passwords in your login database, you have stored something that can quickly be turned back into the plaintext password, just by enumerating the list. Passwords that have been leaked can't become good passwords again.

> Passwords that have been leaked can't become good passwords again.

This doesn't make any sense. We already know all possible passwords: the set of all the permutations of the set of legal password characters of a given length. Your argument applies equally well to these. You can't just use these passwords and check the hash, since the database (hopefully) at least salted their hash to prevent rainbow attacks like that. But even if they didn't salt their passwords, nothing prevents you from hashing all possible passwords and checking. I think I read somewhere that making a rainbow table for all possible 8 character passwords took little time and space; thus all 8 character passwords are already broken. Need to crack a password? Generate the rainbow table and just look it up.

However, your assumption that computers can check passwords quickly is not necessarily correct: that's why bcrypt exists.

Re: "Pwned Passwords" V2 With Half a Billion Passwords

#230

Post by odammit »

Split brain your password storage.

Another table, another database or another storage system in general.

If an attacker SQL injections your database don’t go spilling every hashed or unhashed password you’ve got.

I tend to store passwords in a separate keyvalue store from where my authentication identifier is (email, “username”).

If someone gets into my network they need to get into my servers with the email addresses and then get into a secondary system where the passwords are stored.

I like my password systems to be a k/v store because there is no need to “query” it. I usually store the password under a key that isnt the identifier. Instead using something like a database surrogate key.

Have a secondary system (microservice, private subnet) that simply returns a boolean representing if the provided non-email (key) and password (value) match.

Have that secondary system take the plain text password so it can do the hashing without letting the dependent service know what algorithm, salt or stretches you’re doing. This will also allow you to easily roll over to new hashing algorithms over time without affecting the service that is doing th authenticating.

Edit: I’m not trying to be a know it all or a crabby old tinfoil hat a-hole. But it’s passwords, man. When you leak them you ruin people’s days/year/life. Building that system above takes a middle of the road engineer a day or two. Put the effort in. Every password leak makes all of our jobs harder. It’s your companies responsibility to keep that safe. If you know that already, be the annoying guy that brings it up in every stand up. Make that debt known.

Post reply on HN