Earlier quoted context omitted.
and storing plaintext passwords is unacceptable.
They're not plaintext, we ROT-13 encode them first!
You should ROT-13 them twice for extra security.
300M Freely Downloadable Pwned Passwords
61–70 of 184 posts
Re: 300M Freely Downloadable Pwned Passwords
#62Going to generate a bloom-filter from this dataset tonight. Troy mentions some arguments against torrents, but it is better to have a authoritative torrent than none, imo.
It's also a bummer there are only sha1's in the file. It would be good to block things within hamming distance 2 of a leaked password (so p@ssw0rd€ would also be blacklisted...)
You could go the other way, and check likely candidates from the new password - e.g. if user enters "hunter2", you check hunter and hunter0 and hunter1 and hunter3 and hunt3r2.
Re: 300M Freely Downloadable Pwned Passwords
#63Earlier quoted context omitted.
If you only have one password to try, I'd say you have more important issues to tackle. Install a password manager, start using generated passwords, and stop using 'your password'.
Well, in that case, “your password” might be the only one you have – the one use for your password manager.
Well, in that case, it should already be something that's staggeringly improbable to be used by anyone else, and for your use, you should never ever ever send this password through any network interface at all (including this check page).
Re: 300M Freely Downloadable Pwned Passwords
#64Earlier quoted context omitted.
Well, in that case, “your password” might be the only one you have – the one use for your password manager.
salt "your password" with https://www.passwordcard.org/en
"Pick a password length. Eight is pretty secure and usually acceptable." Wait, what? Unless you're suggesting that I append this to a password.
Re: 300M Freely Downloadable Pwned Passwords
#65HIBP provides a REST API to check if a password has been found in a breach, Is there a disadvantage of using it in applications and restricting users not to use the breached password?
It's not ideal to send every new user's password to a 3rd party service.
Hence the downloadable file, and even a suggestion to use that as an in-house checker. It's in the article.
Re: 300M Freely Downloadable Pwned Passwords
#66I 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?
KeePass uses an auto-type feature; wouldn't that simulate individual key presses, and defeat anti-paste mechanisms?
I find that on some sites if I click in the username field and alt tab to keepass or any other function I'm suddenly not in the txt field on the site... thus I can't trigger auto type at times.
Re: 300M Freely Downloadable Pwned Passwords
#67Earlier quoted context omitted.
and storing plaintext passwords is unacceptable.
That's not true in every case. If you're just throwing it into a DB, then yes. But if you're encrypting it and storing it on an isolated server with the decryption keys on a separate server, it's not a huge deal. Look, people on HN make a massive deal about passwords. One of my most shocking discoveries starting as a pentester was that "storing passwords in plaintext" would be a low-severity finding at best . Medium…
> as a pentester was that "storing passwords in plaintext" would be a low-severity finding
I suspect that's because you're viewing the situation as a pentester not a user. A plaintext password (on its own) doesn't do a pentester much good until they've already gained control of the system. However, once someone has control of the system then plaintext passwords are a threat to users because a lot of people are vulnerable to common password reuse.
Re: 300M Freely Downloadable Pwned Passwords
#68An interesting element to this is how resistant some people are too using torrents for legitimate purposes, even as a backup mirror. It's something we've come to embrace in the Linux world. Much faster than a single server and saves bandwidth at individual sites. Surprised this pragmatism hasn't reached the rest of you yet.
Having an http option makes it better for those on restrictive work networks--I'm downloading the file because I want to experiment with it, but I certainly wouldn't want a call from Networking asking why I'm torrenting stuff.
Yes, I understand the reason for keeping a slow legacy option available.
Even in your situation, if you're doing this for work and IT calls you up, you just tell them what you're doing. "I'm downloading a very large file over Bittorrent because it's 50% faster than the HTTP download and I'd like to do some work today. Is that all? Thanks. Bye."
In some places you'd get that call from IT just for downloading a large file. Getting a call doesn't mean you're doing something wrong, they're just checking it's you, not malware, and that it's for work. If they haven't already blocked it, have at it.
Re: 300M Freely Downloadable Pwned Passwords
#69Going to generate a bloom-filter from this dataset tonight. Troy mentions some arguments against torrents, but it is better to have a authoritative torrent than none, imo.
Or better a cookoo filter:
Re: 300M Freely Downloadable Pwned Passwords
#70Earlier quoted context omitted.
Yes it totally is true. Hashes are a standard length, and you can feed any length passphrase into the hash algorithm. It wouldn't surprise me to see passphrases limited to e.g. 256 chars anyway, but 27 smells very bad. What system limitation leads to this particular number? It smells like a DB column width to me.
Just because there is a limitation on password length doesn't imply they store the password in clear text.
He never said anything about 'clear text' you did and yes that is usually how it is with this 'tell'. It might be some other weakness. Smells like homebrew security. Nice. They are doing it wrong and the wrong shows. That is definitely going in my initial survey.