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

261–270 of 369 posts

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

#261

Post by brazzy »

odammit wrote: post #230

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 addresse…

Sorry, but this is convoluted nonsense that can only achieve one thing: make yourself more vulnerable.

You want your security system to be as simple as possible, and to involve as little custom code as possible. Because you can and will fuck it up if you try to be clever.

Hash and salt your passwords using a library designed exactly for that purpose (which means it will use a slow hash). That's it, end of story.

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

#262

Post by brazzy »

odammit wrote: post #239
ksenzee wrote: post #237

Earlier quoted context omitted.

> don’t go spilling every hashed or unhashed password you’ve got. Please don't store unhashed passwords. By now even PHP gives us the tools to do this right. You truly don't need secondary systems, or separate tables, or separate anything. Just hash the passwords.

You need both. https://www.trustedsec.com/2016/06/introduction-gpu-password...

The takeaway from that (which has been known for a decade at least) is that your passwords need to be hashed and salted, and you need to use a hashing algorithm designed for security (meaning it is slow). Not that you should complicate your system architecture and create more potential points of attack.

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

#263

Post by ekingr »

dandare wrote: post #250

Am I the only one here who thinks typing your password to a stranger's website is a risk? How do you know he does not log it? how do you know he was not hacked and someone is not logging all passwords that are not on the list YET.

The article explains in the "Cloudflare, Privacy and k-Anonymity" section how you can use k-Anonymity to query the API with (at least some) privacy, by just submit the first 5 characters of your password's hash.

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

#264

Post by ajro »

maze-le wrote: post #251
dandare wrote: post #250

Am I the only one here who thinks typing your password to a stranger's website is a risk? How do you know he does not log it? how do you know he was not hacked and someone is not logging all passwords that are not on the list YET.

If you don't trust troy hunt / haveibeenpwned.com you can always download the data and analyze your password yourself. But if this is the case you should not trust any website with your password anwhere ever, and should not create accounts anywhere. Troy Hunt has shown himself a responsible security professional, and I trust him more to create a secure password query than some other security organizations.

"But if this is the case you should not trust any website with your password anwhere ever".

That is why you should use unique password for each site.

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

#265

Post by michaelt »

royce wrote: post #213
rspeer wrote: post #204

Earlier quoted context omitted.

Why would a password that occurs in this list, but rarely, be safer? Attackers aren't going to skip the rare ones.

Because: 1) In an online attack, against a properly-configured service, even if password spraying is used, only the first few thousand passwords can be tried before rate-limiting, CAPTCHAs, etc. kick in. Would a user with a known leaked password at a different site be vulnerable to an online correlation attack? Yes. And that's why some big services supplement their approach by proactively searching for those leaks an…

Eh, "We've got lots of users so it will take a long time to crack them all" isn't much of a defence.

I mean, if you've got Obama or Snowden or Taylor Swift or Logan Paul or whoever as a user, you think hackers wouldn't spent 2 hours of GPU time per account to crack their passwords?

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

#266

Post by rrobukef »

KMag wrote: post #228
fhenneke wrote: post #44

Earlier quoted context omitted.

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.

But no count of how often the hash is used. Counting bloom filters are till a bit harder to implement.

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

#270

Post by KMag »

rrobukef wrote: post #266
KMag wrote: post #228

Earlier quoted context omitted.

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.

But no count of how often the hash is used. Counting bloom filters are till a bit harder to implement.

Counting bloom filters are only marginally more difficult to implement. To increment a key, find the minimum value stored in all of the slots for the key, and then increment all of the stored values for that key that are equal to the minimum value. To read, return the minimum value for all of the values stored in slots for the key.

For these purposes, however, you probably instead want to store just separate Bloom filters for counts above different thresholds, since the common use case would be accept/reject decisions based upon a single threshold.

Post reply on HN