This is really good, and I applaud your efforts in that site in general! My one suggestion would be to explain the term "representation" a little better to non-devs so they understand why the secure technique is secure. I like to use the term "one-way encryption" so that it's clearly not some simple derivation of a password, but a mathematical process with proven difficulty and uncertainty when reversing.
But why can't I send people their passwords?
121–130 of 181 posts
Re: But why can't I send people their passwords?
#122Earlier quoted context omitted.
What is the thinking behind disallowing certain characters? When you create artificial limitations you have to justify them, not the other way around.
There was a discussion here a while back on this matter, where I held very much the same position as you. The other guy convincingly proved that adding the "must use at least one each of these character classes" barely reduces the password space, while promoting increased password complexity for those people who would pick the _really_ easy ones.
Perhaps it's better to suggest using at least one capital, one number and one symbol. You can warn a user that their password doesn't use those and remind them to make it long and not a mere short colocation of dictionary words but ultimately - unless it's risking other's security - you can let them set any password they like?
Re: But why can't I send people their passwords?
#123Earlier quoted context omitted.
Have fun running bcrypt on 100TB of /dev/urandom. Insanely large password limit? Sure sounds like good business to me. No password length limit? Sounds like a DOS attack waiting to happen.
What would you suggest as a sane upper bound?
No idea, especially as pass phrases have become more popular the max length of a password that you might see in the wild has gone up quite a bit. Lets say someone is willing to type for 1 min to login to a site. According to Google the fastest typing speed recorded is 216 words per min. According to the words per min Wikipedia entry a "word"(They give examples of "I run" counts as one word, but "rhinoceros" counts as 2) is 5 characters long so that gives us a max password length of 1080 characters. According to wikipedia War and Peace is just shy of 600 thousand words long or approximately 3 million characters.
Therefore 1000 is a good minimum max length but 3 million is way to long.
Re: But why can't I send people their passwords?
#124Creating an FAQ for these companies would be useful. Something to arm the devs who work at these places with something when they go to management who's reaction is "yeah I know it's bad.. but... like, we have important shit to do."
What would you suggest?
Assume the company is unaware that their developers have implemented the password this way. The FAQ for the company should highlight the exceptionally high cost of losing customer data, the distraction for their team from dealing with any breach, and the incredibly low cost of making the fix. The call to action could be for them to email their developer a link to your dev FAQ, demanding a fix.
Re: But why can't I send people their passwords?
#125Earlier quoted context omitted.
Have fun running bcrypt on 100TB of /dev/urandom. Insanely large password limit? Sure sounds like good business to me. No password length limit? Sounds like a DOS attack waiting to happen.
What would you suggest as a sane upper bound?
const int PW_MAX = strlen("correct horse battery staple")
Re: But why can't I send people their passwords?
#126This is really good, and I applaud your efforts in that site in general! My one suggestion would be to explain the term "representation" a little better to non-devs so they understand why the secure technique is secure. I like to use the term "one-way encryption" so that it's clearly not some simple derivation of a password, but a mathematical process with proven difficulty and uncertainty when reversing.
I thought of my mom and dad reading this and what they would best understand. I'm worried using something like "one-way encryption" would have their eyes glaze over :)
Re: But why can't I send people their passwords?
#127This isn't really addressing the main issue. You need to emphasize and just drive the point home that people should not even be STORING plain text passwords. Anywhere. Get them to understand that they don't want to, and shouldn't, know anyone's password in plain text, and how. It's a very counter-intuitive concept that makes sense once explained.
EDIT: Just saw @ajanuary's child comment on the top-voted parent. The point exactly.
Re: But why can't I send people their passwords?
#128Earlier quoted context omitted.
What would you suggest?
Assume the company is unaware that their developers have implemented the password this way. The FAQ for the company should highlight the exceptionally high cost of losing customer data, the distraction for their team from dealing with any breach, and the incredibly low cost of making the fix. The call to action could be for them to email their developer a link to your dev FAQ, demanding a fix.
That's a great idea! I'll add "I've been listed! What do I do?" to the FAQ. Thanks!
Re: But why can't I send people their passwords?
#129Earlier quoted context omitted.
Have fun running bcrypt on 100TB of /dev/urandom. Insanely large password limit? Sure sounds like good business to me. No password length limit? Sounds like a DOS attack waiting to happen.
What would you suggest as a sane upper bound?
You're probably good with 1k FWIW Django added a 4k limit (4096 bytes) last September: https://www.djangoproject.com/weblog/2013/sep/15/security/
Re: But why can't I send people their passwords?
#130Your non-devs FAQ is still not quite informative. You still don't explain to laymen /why/ what the sites are doing is wrong, you just say "You should never see your password". edit: Maybe something along the lines of: > Modern cryptography allows websites to save passwords in a form that is un-decryptable even to the site itself. This works because to check the validity of logins, the unencrypted (plain) version of t…
That's a pretty technical explanation. I think something like this would suffice: > If the website can pull out your password to show it to you, an attacker can pull out the password to steal it. As ever, the issue is explaining hashing.
I like this description. I don't know that you need to explain hashing to laymen, though. Hand-waving is acceptable when communicating to people who aren't skeptics (laymen). If they're really interested in fact-checking you, they can do so on their own time, or you can provide links to detailed explanations.
"It is possible to store passwords in a way that the website cannot see your password, but can still verify that a password entered by you checks out." (trust us, after all you're trusting that we know what we're talking about by reading this stuff)