291–300 of 369 posts
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.
It would be great if the many password managers out there like keepass for example, use this data to filter out any password that exists in the list. I know it would be very rare, but still, why not filter them out?
The UX of a blacklist with a half billion entries would be so crippling that it would cause a user revolt. Most people's password-selection strategies are similar enough to other people's (like kbenson's 4000+ hit) that they could spend hours trying to come up with a password that has never been leaked before. I tried to encourage Troy to suggest to implementors that blacklisting all passwords was a Bad Idea. Instead…
The situation doesn't need to get as bad as you think. If you suggest XKCD's four random common word method[1] to your users as part of the user interface, you'll be fine. As a test, I tried putting together 2 random, common, unrelated words together:
- yak elephant -> yakelephant
- crowd brown -> crowdbrown
- plastic envy -> plasticenvy
- colon spanish -> colonspanish
- jogging adhesive -> joggingadhesive
Even with two words, none of the above appear in the Pwned Passwords database of a half a billion passwords. It's not difficult to choose memorable passwords and avoid entries from Pwned Passwords if you suggest this method to your users (preferably recommending four words, but three might be OK depending on the threat model).
I think it would be interesting to do an art project with this data - some of these passwords are funny and/or revealing. Some examples: pooplasagna - 3 times eggsarebad - 3 times eggsaregood - 25 times myhusbandcheats - 4 times icheatonmywife - 1 time ihatemyneighbors - 2 times iamanalcoholic - 6 times 1yearsober - 31 times imissmykids - 51 times imissmyparents - 6 times
correcthorsebatterystaple - 103 times
Also I wonder if Randall Monroe knows this somewhat ironic fact? It would make a nice addendum to the alt text on https://xkcd.com/936/ (which BTW is the origin of correcthorsebatterystaple for those wondering).
I think it would be interesting to do an art project with this data - some of these passwords are funny and/or revealing. Some examples: pooplasagna - 3 times eggsarebad - 3 times eggsaregood - 25 times myhusbandcheats - 4 times icheatonmywife - 1 time ihatemyneighbors - 2 times iamanalcoholic - 6 times 1yearsober - 31 times imissmykids - 51 times imissmyparents - 6 times
correcthorsebatterystaple - 103 times
Earlier quoted context omitted.
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 t…
Many years ago Debian mistakenly shipped a version of openssl that didn't use good entropy to pick RSA keys. As a result, everybody with that Debian would get one from a relatively small pool of keys when they asked for a new one. There's nothing special about these RSA keys, other than the fact that Debian systems from a particular era would always pick them.
A good CA (e.g. Let's Encrypt) blacklists the public halves of those key pairs. Again, there's nothing special about them, no reason they're worse than any other random key _except_ Debian always picked those, and since it did bad guys can trivially find out the corresponding _private_ key for each value and so they're useless.
If you propose to use one of these blacklisted public keys, there is a near certainty that it's because you have a broken Debian system making the keys, and so refusing you keeps you safe. Even though there's nothing special about these keys.
Now, if I have a system that generates RSA keys in a known secure way, I needn't check for Debian weak keys myself. Why not? Because there is statistically no chance I'd ever pick one at random, it's a total waste of engineering effort to check. But if I ask somebody _else_ to make a key pair and send me the public half, I should check against the Debian weak keys, because I shouldn't trust that they're smart enough not to use the broken code.
These passwords are crap. They wouldn't necessarily be crap if nobody had ever known what they were, but now they do, so they're crap now. Pick a different password.
Earlier quoted context omitted.
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.
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.
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...
A warning about Cloudflare: You cannot access their support in any way without logging in. Trying to contact them via their contact/sales page won't work. They won't respond. This means that if you lose your phone (2FA) and can't log in, you're royally screwed and will have to go to your registrar to recover access to your domains/DNS.