http://plaintextoffenders.com/faq/non-devs
"We explain in everything our About page." - doesn't read right, maybe 'we explain everything on our About page"?
"your post was deleted with prejudice" ?? needs rephrasing
But why can't I send people their passwords?
51–60 of 181 posts
Re: But why can't I send people their passwords?
#52The dev FAQ should contain information on how to safely (and painlessly) migrate from plain-text/MD5/SHA1 to a more secure algorithm.
I think Django's method is a good one to emulate:
https://docs.djangoproject.com/en/dev/topics/auth/passwords/
A list of password hashers, on successful login the user is upgraded to the top password hasher. Makes it very simple to switch to a new scheme or work factor.
Re: But why can't I send people their passwords?
#53Earlier quoted context omitted.
Another thing to consider is if your email provider's offline backups get jacked in transit would you rather your emails contain your plain text passwords or links to a password reset with expired tokens?
I have never thought of that, ever. I'm not being sarcastic. Usually I think of email as existing on some secure server, I never thought that backups are kept, maybe in a different medium which is then open to vulnerabilities.
This is why, for example, Amazon S3 has a little checkbox on each bucket to encrypt the contents of the bucket.
At first glance this might seem a little silly. Amazon has the key. (You don't even get to see the key yourself.) So Amazon can read all your data. And every time you read from the bucket it's automatically decrypted, so the encryption won't protect you from anyone who has somehow achieved permission to read your data.
But that's not the point. The point is to protect against attacks like "I found this pile of dusty drives stacked in the maintenance closet at Amazon," or "I went digging in the local dump near an Amazon data center and unearthed this hard drive, and look what I found backed up on it."
Re: But why can't I send people their passwords?
#54I was a bit surprised by #9.2 - "Don’t put any limitations on the passwords people can use (maximum lengths, disallowing certain characters, etc.)". What's the thinking here?
As the password should be stored as a hash anyway the actual length of the password does not matter as the hash length will be constant.
In the old days, if you stored the unencrypted password, it had to have a maximum length because somebody decided to make the db column 16 chars....
Same goes for charset limitations (e.g. try storing unicode characters in a database set to US-ASCII charset...) - with a hash your input does not matter - it is just a sequence of bytes that are hashed.
Lastly, the source of disallowing certain characters is the laziness of the implementers that couldn't be bothered to implement proper input encoding in their frontend
Re: But why can't I send people their passwords?
#55Earlier quoted context omitted.
As a huge supporter of Persona, I am intrigued. Can you sell me on how this may be better?
Also, Persona still relies on passwords which are usually too weak and re-used across the web
No, Persona does not rely on passwords. Persona has authentication providers that rely on passwords.
Re: But why can't I send people their passwords?
#56Earlier quoted context omitted.
A lot of people use only one password for everywhere... You'd be giving the attacker the keys to the kingdom.
Which is still true if you don't know their passwords but if you have their email. You can reset the passwords for just about every conceivable account they have.
If the password is in the email in cleartext, you don't need an active login for their email. All you need to do is be looking over their shoulder in the cafe, once, when they bring up the email on their iPad.
Re: But why can't I send people their passwords?
#57Earlier quoted context omitted.
As a huge supporter of Persona, I am intrigued. Can you sell me on how this may be better?
Also, Persona still relies on passwords which are usually too weak and re-used across the web
Depends on the email address you use :-) Gmail, etc. are directly supported - for any other email provider (or your self-hosted one) you'll need a password.
Re: But why can't I send people their passwords?
#58Earlier quoted context omitted.
A lot of people use only one password for everywhere... You'd be giving the attacker the keys to the kingdom.
Which is still true if you don't know their passwords but if you have their email. You can reset the passwords for just about every conceivable account they have.
Given an uncertain amount of time. Your process requires access to their email account while you go through and reset all their passwords. Whereas if the passwords are in plaintext, you can download all their email and get access at your leisure.
Re: But why can't I send people their passwords?
#59Earlier quoted context omitted.
Another thing to consider is if your email provider's offline backups get jacked in transit would you rather your emails contain your plain text passwords or links to a password reset with expired tokens?
I have never thought of that, ever. I'm not being sarcastic. Usually I think of email as existing on some secure server, I never thought that backups are kept, maybe in a different medium which is then open to vulnerabilities.
I'm not even giving a hypothetical scenario. It's no longer fresh in the minds of most people but years ago Reddit used to store their passwords plain text for the convenience of being able to send them to the user, instead of implementing a password reset mechanism. One day their hosts backup tapes were stolen out of the back of a truck. Now they salt+hash their passwords.
Re: But why can't I send people their passwords?
#60Thanks for doing this, it is greatly appreciated. The list of offenders with screenshots is nice, but what would be really useful is a table that is sortable and filterable so that people (i.e. me) can find out if any of our vendors are offenders. Also, a JSON API would be slick too. Just ideas.