Live data from Hacker News

"Pwned Passwords" V2 With Half a Billion Passwords

troyhunt.com

301–310 of 369 posts

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

#301
post #264

Earlier quoted context omitted.

"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.

This is absurd and impossible to remember, you should instead have at least 3 levels of password strenght, one high strenght for base services that are used to retrieve other accounts like facebook and e-mail, other for important services, and another for crap.

Except that my 3 level system failed ages ago. Originally I had one, then with more sites coming - several with bogus or recless implementation - it was extended to the aforementioned 3 tier one just to get f*cked up by 'knowing it better' god complex but stupid enforcers requesting or forbidding (!! how stupid is that!) characters. Not to mention leaks forcing me to introduce new ones, having eventually 5 layers with variations on each level because of the highly arbitrary rules of enforcers blocking my well thought of secure passwords.

All led to the situation that I have an encoded file on my computer with passwords (most just referrals/reminders/instructions not the actual password characters).

How stupid is that! Writing down passwords!

Even into secured files, still, increased level of risk. A method with doubtful protection when someone is targeted for his/her secrets personally. Stupid but that is reality. Made necessary by recless developers.

The whole password infrastructure is dead as means of protection. It does not work against serious attackers, only agains random wanderers. And more and more against rightful users!

And the most was done to ruin it by those enforced the users to solve the problem on the user side that in fact lying in the system side.

Passwords will not fullfill their task if: - allowing parties without permission to enter - locking out righful parties Very strict enforcers corrupt the system through the second point. Narrowmindedly focusing on not letting in unwanted elements cause the whole system to case working as intended, locking out and disallowing users to use it, defying the very purpose of existence.

Encouraging users not to use passwords that ever used by someone is just an extremely very radical level of enforcing and again trying to make users fix the inadequacy of the system developers.....

This is not solving systematic problems just conserving a bad habit plus making a bad situation even worse.

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

#302

do not skip the section on "Cloudflare, Privacy and k-Anonymity" ... it is a great summary of an elegant privacy solution. And check out Cloudflare's detail post too: https://blog.cloudflare.com/validating-leaked-passwords-with...

Does anyone else not get results when searching for 'asdf' and 'hunter2', and 'lauragpe'(which appears in the article) not return results using the shell script provided? edit: Ok, so my `openssl sha1` (version 1.0.x) outputs '(stdin) ', whereas the script expects just . add ' | cut -f2 -d" "' after the 'openssl sha1' call to fix this if you have the same problem.

Here's how I tested:

    echo -n 'hunter2' | sha1sum

    f3bbbd66a63d4bf1747940578ec3d0103530e21d -
https://api.pwnedpasswords.com/range/f3bbb

C-f d66a6 finds

    D66A63D4BF1747940578EC3D0103530E21D:16092

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

#303

do not skip the section on "Cloudflare, Privacy and k-Anonymity" ... it is a great summary of an elegant privacy solution. And check out Cloudflare's detail post too: https://blog.cloudflare.com/validating-leaked-passwords-with...

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

Both 00000 and 4A4E8 contain the largest number of hashes so it could just be coincidental that the former looks recognisable.

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

#306
I love that simple API! Here's a bash one-liner that checks if 'hello' is compromised:

curl -s https://api.pwnedpasswords.com/range/$(echo -n hello | shasum | cut -b 1-5) | grep $(echo -n hello | shasum | cut -b 6-40 | tr /a-f/ /A-F/)

Edit: Improved one-liner that only requires typing the password once and avoids storing it in the bash history:

(echo -n "Password: "; read pw; curl -s https://api.pwnedpasswords.com/range/$(echo -n $pw | shasum | cut -b 1-5) | grep $(echo -n $pw | shasum | cut -b 6-40 | tr /a-f/ /A-F/))

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

#309
post #98

do not skip the section on "Cloudflare, Privacy and k-Anonymity" ... it is a great summary of an elegant privacy solution. And check out Cloudflare's detail post too: https://blog.cloudflare.com/validating-leaked-passwords-with...

Just added an extra line to the bash wrapper to print how many time the given password appears in the dump: https://gist.github.com/mino98/8aa240fa55a8182198fba58fb810b...

If you prefer a one-liner like me, the following line works for me:

VARPWD=P@ssw0rd; HASH=`echo -n $VARPWD | sha1sum`; curl --silent https://api.pwnedpasswords.com/range/`cut -b 1-5 If it doesn't return anything than your password isn't in the list. You should probably start your line with a space so that it isn't recorded in your bash_history.

If someone else can make it better or shorter, be my guest.

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

#310
post #261

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.

^ above is pretty damn simple.

I also never said “write your own hashing algorithm” I said abstract it so it’s not sitting around in your ecommerce app code.

That is a simple security system. It’s just not baked into your flagship ecommerce, blog or whatever else your storing the credentials to protect.

Post reply on HN