Woha, wait a second:
> Each of the 306 million passwords is being provided as a SHA1 hash.
That's it? Without any salting? This would make it trivial to recover the plain text using rainbow tables.
300M Freely Downloadable Pwned Passwords
151–160 of 184 posts
Re: 300M Freely Downloadable Pwned Passwords
#152I wonder how we force change with individual companies? Today I had to sign up for a UPS account. The password length was set to max 27 characters, and the form had disabled paste in the password field. Who do we lobby to get them to fail their next PCI-DSS compliance test?
Even worse than disable paste, I've noticed a lot of iPhone apps now require you to set a non-pasteable 4-6 digit pin to login (sometimes this is required to use the app at all, sometimes only if you enable touch id). At least one bank says the pin is "for this device" but then accepts it on new iOS devices too (without ever prompting for the "real" password on the new device).
We've got a few apps where that's been a customer requirement. The thinking is that 1) there are enough people who either do not use a pin/fingerprint to secure their phone and 2) lots of people let other people use their phone (especially parents with kids) - sometimes the argument that securing the PII in the app is a reasonable choice.
(I occasionally worry that my phone's bitcoin wallet does not do this. There is occasionally a large enough balance in there that I'd really like to have to touchid to open it and transfer those bitcoin out... Not quite worried enough to investigate whether other wallet options do it, but sometimes I hand my phone to someone to show them a pic and think "Do I _really_ know this person well enough to trust they won't poke around my phone and try to distract me enough to swipe some bitcoin???")
Re: 300M Freely Downloadable Pwned Passwords
#153Earlier quoted context omitted.
Password hashes are specifically designed to be computationally intensive. You can feed any length of password into a hash, but the longer the password is, the more work you have to do. "No length restriction on passwords" is a common and valid report on HackerOne, because servers that do store passwords securely can be DoSed by someone providing a long password and forcing the server to hash it.
That is an important consideration, but it still sets reasonable password length limits in the hundreds or thousands of characters.
NIST's latest recommendations say "at least 64 characters".
I doubt there's anyone who can make a strong argument that "64 characters isn't enough", and I doubt even intentionally computationally expensive password hashing is going to end up with significant resource usage with 64 or 128 character strings. I wouldn't want my shared hosting WordPress site with a password plugin to need to calculate the bcrypt hash of the entire text of War And Peace, bit I suspect the difference between bcrypting "password123" and a random 64 or 128 character string is insignificant enough to be ignored (but I've never tried benchmarking it, so I'm open to changing my mind here if anyone has links to benchmarks that show otherwise...)
Re: 300M Freely Downloadable Pwned Passwords
#154Earlier quoted context omitted.
The argument is transitive - why are these other systems limiting the password length?
Because they're older?
I've was integrating with an application recently where some of the header file copyright dates are in the '80. Sometimes there are _very_ old but business critical systems that everybody knows need replacing, but which "just work" and for which the risk and/or opportunity cost of replacing the old system is so high it's not been done.
(This application has had three failed rewrite/replace projects over the last 10 years. They're now onto their fourth one, and they're running 32 months over deadline on a "2 year" project timeline...)
Re: 300M Freely Downloadable Pwned Passwords
#155Woha, wait a second: > Each of the 306 million passwords is being provided as a SHA1 hash. That's it? Without any salting? This would make it trivial to recover the plain text using rainbow tables.
Troy explains where the majority of them came from - it'd be even more trivial to Google for the dumps yourself.
It's not like everyone who is curious cant go findabout stuff like this doesn't have the Rockyou dump already, and there's easily enough links to start your own list here: https://www.google.com/search?q=password+lists
Re: 300M Freely Downloadable Pwned Passwords
#156Earlier quoted context omitted.
There are 9120 printable ASCII strings of 1-2 characters in length. Cunning, including that many to bulk out the list :)
;) OK. But there are a ton of 3 and 4 char passwords too. I mean, what sort of site would allow that? It's just hard to believe these were actually passwords. BTW, I upvoted your comment. It made me laugh. Point granted.
FWIW - I do that all the time.
If someone's website forces me to set up an account without me already being convinced there's enough benefit to me in return for my personal information, they're likely to get a signup for test@example.com with password "foo". (And if they then respond with "please click the confirmation link in the email we just sent", I'll sign up again with $sitename@$spare-domain-I-own.com and pick up the link from the spam filtered catchall account).
I probably do this at least once a month when there's hints something useful in a web forum I want to read, but I'm not (yet or ever) convinced I'll ever become a member of that forum's community...
Re: 300M Freely Downloadable Pwned Passwords
#157Earlier quoted context omitted.
sha1sum is giving different results. /tmp$ echo "p@55w0rd" | sha1sum 8633c4a8b38a8826132414d8861af7b6a8371976 - This is a different value from the one given in the blog post: "ce0b2b771f7d468c0141918daea704e0e5ad45db". The python sha-1 hexdigest comes out right, though: In [13]: import sha In [14]: sha.new('p@55w0rd').hexdigest() Out[14]: 'ce0b2b771f7d468c0141918daea704e0e5ad45db' In case anyone else has passwords th…
You need to use `echo -n` in order to not have `echo` generate a newline.
Ah, thanks.
Re: 300M Freely Downloadable Pwned Passwords
#158As others have pointed out, the use case for pasting plain text passwords is not quite clear. Maybe it would be a good idea to allow searching for hashes only, or at least hash the password in js on the client. Also, I'm genuinely curious as to why SHA-1 is used and not SHA-256. Surely the one-time additional cost of using SHA-256 would've been negligible for Troy? If at some point somebody manages to do preimage att…
I believe the sources for the data breaches were mentioned in the article, so if someone wanted to get those sources anyway, it wouldn't be a big deal.
He stops well short of saying "here's a link to the pastebin dumps!", but yeah - it wouldn't take too much google-fu to build your own version of this - perhaps not a 300M entry one, but I doubt it'd take more than a weekend to get halfway there if you wanted too.
Re: 300M Freely Downloadable Pwned Passwords
#159Earlier quoted context omitted.
sha1sum is giving different results. /tmp$ echo "p@55w0rd" | sha1sum 8633c4a8b38a8826132414d8861af7b6a8371976 - This is a different value from the one given in the blog post: "ce0b2b771f7d468c0141918daea704e0e5ad45db". The python sha-1 hexdigest comes out right, though: In [13]: import sha In [14]: sha.new('p@55w0rd').hexdigest() Out[14]: 'ce0b2b771f7d468c0141918daea704e0e5ad45db' In case anyone else has passwords th…
You can also binary search with "look -b". The version included with Debian Unstable doesn't support large files, but it will search multiple files at once, so you can split without breaking lines, eg. with "split -C 1999m", and search with "look -b SHASUM splitfile*".
Thanks, I knew there had to be an easier way, but couldn't find it.
Re: 300M Freely Downloadable Pwned Passwords
#160Earlier quoted context omitted.
Having used isatty in some of my CLI programs to alter the behavior depending on whether STDOUT is a TTY, I see the appeal. It allows the program to do the best thing depending on how it's being invoked. However, more recently I've grown skeptical. It leads to surprises, and if a person isn't familiar with the finer details of file descriptors, they may wonder why piping a program changes its behavior. I think this e…
Yeah, that's a hard one. Of course, there are strong arguments for "sensible defaults". But here is how it went : First, I used pwgen to generate temporary passwords for new unix users. I read the man page at that time, probably saw the mention about different behavior regarding output capabilities and thought : "nevermind, this is not my use case". Years later, when I decided to pipe it, I thought I already knew the…
You can use "simpler tools", such as `head -c 20 /dev/urandom | sha1`.
If head behaved differently when piped, you would probably know about that because it's a common thing to do.