81–90 of 184 posts
Can Troy or someone contact Google (bq-public-data@google.com) and push this to the GCP's BigQuery public dataset[1] for hosting and easier look up your password via SQL in BigQuery rather than some 3rd party site? [1] https://cloud.google.com/bigquery/public-data/
I 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?
Someone made an Chrome extension to enable password pasting again. Don't Fuck With Paste: https://chrome.google.com/webstore/detail/dont-fuck-with-pas...
I 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?
Someone made an Chrome extension to enable password pasting again. Don't Fuck With Paste: https://chrome.google.com/webstore/detail/dont-fuck-with-pas...
Going 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.
>Do not send any password you actively us to a third-party service - even this one.
So I can only test password that I am not using (and by extension that I am not going to use in the future).
>oh no - pwned!
>This password has previously appeared in a data breach and should never be used. If you've ever used it anywhere before, change it immediately!
If I cannot (shouldn't) submit any password I am actively using, what does it matter if I used it before? Now I already changed it.
I 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?
That is enough characters that if you restrict yourself to the ~95 normal printable characters you can obtain around 175 bits worth of password (as in, more than enough to store a SHA1 sum). Is that really not enough entropy for your use case?
With a limitation of 27 characters it's not possible to make my password be "if i forget this i'm in a lot of trouble".
Wait, so I test my password to see if it's "good" and now you have a copy of a password I will be using. Am I just being paranoid?
Earlier quoted context omitted.
That's simply not true.
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.
"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.
Earlier 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.
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.