
But why can't I send people their passwords? - omervk
Hi all, this is @omervk, one of the co-founders and maintainer of Plain-Text Offenders [1].<p>I&#x27;ve just finished creating two FAQs: One for developers who come to the site and don&#x27;t understand what&#x27;s wrong with what they&#x27;re doing [2] and another for the laymen who want to understand what we&#x27;re all about and how to protect themselves [3].
The idea is that people could also send these links around to educate others.<p>As HN is one of our main supporting communities, I&#x27;d love to hear your thoughts about both of these new pages.<p>[1] http:&#x2F;&#x2F;plaintextoffenders.com&#x2F;
[2] http:&#x2F;&#x2F;plaintextoffenders.com&#x2F;faq&#x2F;devs
[3] http:&#x2F;&#x2F;plaintextoffenders.com&#x2F;faq&#x2F;non-devs
======
jere
> _7\. Fine, but I still get to send users their passwords once they created
> them so they don’t forget them, right?_ Email is not a secure medium. It was
> never designed to be one. It’s susceptible to Man In The Middle (MITM)
> attacks and a slew of other issues. Also, users might have their email
> accounts abused or hacked into (how many people do you know who have left
> their GMail logged in on a public computer?). Would you really like someone
> to gain credentials to your product when this happens?

This is one I always struggled to understand. If email is compromised, the
attacker can request and immediately intercept a password reset anyway.

[edit: Many excellent points below. I think some of these should be in the
FAQ.

~~~
weaksauce
A lot of people use only one password for everywhere... You'd be giving the
attacker the keys to the kingdom.

~~~
kenny_r
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.

~~~
throwaway48372
Back when I was a teen I used to fraud people and scam ebay sellers through
paypal. If I were to somehow gain access to an email (via RAT, Cookie
hijacking), one of the easiest ways to recover a password was to look for a
provider that sent out a plaintext password. Chances are the unfortunate
target used the same password on every site (or if it was lowercase and alpha,
that password + "1").

That would grant continued access to the email, and other sites that took
protection a little more seriously like Paypal and Bank Logins (you can't
reset a Paypal password with just an email, and if you could, such an action
would make Paypal fraud detection software go nuts).

~~~
praneshp
"Back when I was a teen I used to fraud people and scam ebay sellers through
paypal".

Cool!

------
omervk
Clickable links:

[1] [http://plaintextoffenders.com/](http://plaintextoffenders.com/) [2]
[http://plaintextoffenders.com/faq/devs](http://plaintextoffenders.com/faq/devs)
[3] [http://plaintextoffenders.com/faq/non-
devs](http://plaintextoffenders.com/faq/non-devs)

------
_mulder_
I'd suggest starting the answer to each question with a clear Yes or No, Right
or Wrong so people can skim through.

Example:

>7\. Fine, but I still get to send users their passwords once they created
them so they don’t forget them, right?

No, Email is not a secure medium.....

~~~
omervk
Good idea. Implemented.

------
vomitcuddle
The dev FAQ should contain information on how to safely (and painlessly)
migrate from plain-text/MD5/SHA1 to a more secure algorithm.

~~~
huxley
I think Django's method is a good one to emulate:

[https://docs.djangoproject.com/en/dev/topics/auth/passwords/](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.

~~~
masklinn
Outside Django, if you're using Python, there's no excuse to not use
passlib[0] whose cryptcontext object[1] handles this situation fantastically:
create a cryptcontext with all the hash types you accept as input, and put any
"old" hash in the `deprecated` list (or just set `deprecated=['auto']` in 1.6,
it'll deprecate any non-default hash — the default hash is the first of the
list, or the one passed as the `default` parameter). Then you can just use the
relevant method to know that the authentication was successful _and_ you
should update the in-db hash:

    
    
        hash = CryptContext(
            # upgrading from an md5_crypted system
            ["sha256_crypt", "md5_crypt"],
            deprecated=['auto'])
        
        # in auth code
        valid, updated = hash.verify_and_update(password, current_hash)
        if not valid:
            # error out
        if updated is not None:
            # updated is the new hash to set in database
    

[0] [https://pythonhosted.org/passlib/](https://pythonhosted.org/passlib/)

[1]
[https://pythonhosted.org/passlib/lib/passlib.context.html?hi...](https://pythonhosted.org/passlib/lib/passlib.context.html?highlight=cryptcontext#passlib.context.CryptContext)

------
jscheel
Our healthcare provider is storing passwords in plain text. When I went in for
my health screening, they had everyone's forms printed out, with our passwords
written on sticky notes attached to the front. Hundreds of people's health
data, wide open for the taking. I was beyond pissed. Then I found out that
they don't use ssl on their service, and the passsword can be retrieved at the
click of a button. Ended up speaking with a C-level about it. Her response was
that they are perfectly within HIPAA compliance, and that she would have to
talk to their CTO about any other problems with their data security. Looking
at the HIPAA, I have to say, it's not very clear on the need for hashing
passwords. Still, I reminded her of the massive liability they are opening
themselves to. She promised to get back in touch with me, but I haven't heard
anything since (imagine that).

~~~
moistgorilla
Lol, my dad is an endodontist and he hasn't made his website interactive
(patient accounts, interactive appointment scheduler, interactive referrals)
yet because he can't afford a webdev that would make it secure
(salting/encryption).

My dad is an endodontist with zero software/web experience and even he knows
not to keep passwords in plaintext and to use ssl.

I'm only a CS undergrad and I'm learning webdev so I can implement it for him
but I still know to hash and salt your passwords. The fact that people
implement these critical systems (and get paid for it) without knowing basic
practices makes me worry about the future.

------
makmanalp
Your 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 the password is never
> needed. The fact that a site stores the password in a decryptable format and
> decrypts it to show it to you means that an attacker could potentially
> decrypt the password in the exact same way. Or even worse, maybe they never
> encrypt it in the first place! This potentially compromises the safety of
> the password you use because it lets an attacker steal your password.

~~~
ajanuary
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.

~~~
drewcrawford
I think this is easier than it sounds. To a layman, when they type in their
password, they are not thinking about how it would be implemented. The idea
that "oh, somebody is doing a string compare against a password in the
database" is not something that would enter their mind. That is baggage that
software developers may have, but ordinary people have not been primed in that
way.

Ordinary people are going to be thinking about a key in a lock. Does the lock
on your house store the key inside? Maybe in some kind of information-
theoretic sense but in the ordinary meaning of the word, no, it has a
representation (that may not even be sufficiently specific to recover your key
exactly). And if you lose your key you don't break into the lock to recover it
--you call a locksmith to replace the lock, and get new keys.

That right there is an intuitive understanding of both hashing and good
security principles that goes surprisingly far.

~~~
ajanuary
Absolutely. I wasn't really clear. I didn't mean it needs an explanation of
hashing. I meant there needs to be some short answer to the question of "if
they can't pull out my password, how do the check it?"

I don't think people are thinking about keys and locks. Passwords are a thing
that existed before computers and that people understand perfectly outside of
an IT context. Spies in films use secret phrases to prove they're the contact,
kids use passwords to gain access to the clubhouse. But in all these non IT
contexts the person checking the authentication knows the shared secret, so
it's obvious how they check it.

If my mental model is "I've arranged a secret password with this website that
proves I'm really me", then my first question when told the website doesn't
know what secret password is "well how does it know that the password is
correct?".

The best I've been able to come up with today is a somewhat lengthy metaphone
with color mixing.

[Edit] Having said that, I just went and talked to my technical literate non
programmer wife and she used the key and door analogy.

------
tptacek
The "Don't Use Bcrypt" article isn't a good source; the headline message
you've taken from it isn't accurate. In fact, bcrypt is significantly better
than PBKDF2, and PBKDF2 (with normal parameters) is probably the "least best"
of the mainstream options for password hashing.

By citing an inside-baseball controversy, you're making it harder for
developers to do a good job storing passwords, because you're creating the
impression that developers need to carefully choose which password hashing
algorithm they use, and be careful about making the wrong choice.

In reality, what developers need to be careful about is choosing _a password
hashing algorithm_ , and not a general-purpose cryptographic hash. The right
message is that PBKDF2, bcrypt, and scrypt are all fine options.

So my feedback is that your developer FAQ is trying to be a little too clever
for its own good. I'd revise it.

~~~
omervk
Thanks for the feedback. I went back to the article (which we started linking
to a couple of years ago) and saw the comments and, along with what you wrote
here, removed the preference of scrypt and PBKDF2 over bcrypt.

------
couchand
Question #8 on the non-dev FAQ really should be higher up, like #3. That way
the early questions mirror their own thoughts: 1. what is this, 2. but I
thought it was secure, 3. what can I do?

~~~
omervk
It's a good thought, but the FAQ starts with what we are, why and how to
contribute.

------
peterwwillis
Question 8 on the dev faq should emphasize using multiple layers when doing a
password reset, partially to avoid the inherent problems with e-mail security
(especially as your last bastion of security). Security questions, browser
heuristics, login attempts, out-of-band communication (SMS confirmation code,
secondary e-mail account, etc).

Question 9 should include a sub-section .3 which explains that if you
unrestrict the password field, you need to include a basic password cracker or
strength requirement, usually along with a client-side "strength" meter. The
backend should reject all simple passwords and the frontend should help the
user pick a simple yet strong password.

And ideally this page would also link the dev to
[http://twofactorauth.org/](http://twofactorauth.org/) as an example of how
many more places are implementing 2FA. Passwords are dead; long live passwords
with 2FA.

~~~
omervk
Re: Q8. Security questions are an anti-pattern and the rest are outside our
mandate. I do not claim to have written the penultimate guide to password
security :)

Re: Q9. Again, that's a great pattern, but is not a requirement to not be on
our list.

This is linked to from the non-dev FAQ, but I'll make sure to add a section
about 2FA to the dev section.

Thanks!

~~~
Flenser
Re: Q9, you could at least put in a link to zxcvb[1] so that they can be aware
that it's an issue and that there's libraries for implementing it.

[1] [https://tech.dropbox.com/2012/04/zxcvbn-realistic-
password-s...](https://tech.dropbox.com/2012/04/zxcvbn-realistic-password-
strength-estimation/)

------
awsh
You've got a typo in the link in dev FAQ #7. Main-In-The-Middle

~~~
vadvi
also this: "[...] or on how the can use them [...]"

------
a1a
>>(Question 5) What? No! _Why use algorithms that have been broken for years?_
It’s ridiculously fast to break both, along with many other simple algorithms.

I'd remove the emphasized text. Yes they are vulnerable to collision attacks
but that's completely irrelevant in this context.

------
aturek
I've been trying to learn the best practices on password "storage" and
verification lately. I thought this was a really good step-by-step technical
breakdown of the __right __way to hash passwords (I have no opinion /knowledge
of the hashing algorithms in the article, but I've found a lot of other
positive mentions of PBKDF2, bcrypt, and scrypt)

[http://nakedsecurity.sophos.com/2013/11/20/serious-
security-...](http://nakedsecurity.sophos.com/2013/11/20/serious-security-how-
to-store-your-users-passwords-safely/)

~~~
omervk
I'd appreciate it if you could post this as a comment to the Dev FAQ page :)

------
blueatlas
I 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?

~~~
furyg3
If someone wants to use a 250 character truly random password with crazy
characters, let them do it. If they used a long password with an excellent mix
of upper-case, lower-case, and special characters, but no numbers, it's a good
password, take it.

I had a password for a credit card account which could not be more than 8
characters and couldn't contain 'special' characters or punctuation. This was
probably done to either make the password human readable (over-the-phone,
horrible idea), or because of some legacy system on their end. At some point
the organization got smart and made a minimum of 6 characters, of which two
needed to be numbers (but kept the other restrictions). This effectively
narrows down pool the possible passwords for an attacker to guess, the
opposite of what you want to do.

~~~
stonemetal
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.

~~~
omervk
What would you suggest as a sane upper bound?

~~~
stonemetal
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.

------
7952
It is worth remembering that reset links should also be hashed. If the
database is compromised the reset ID can be retrieved without needing access
to the users email.

------
bwy
This 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.

------
TallGuyShort
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.

~~~
omervk
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 :)

~~~
TallGuyShort
Probably. What about something to the effect of just adding, "The
representation is created by shuffling and encrypting the password over and
over so there's no way to reverse the process" or something like that?

------
pornel
The dev FAQ perpetuates a common misconception about "broken" MD5 and SHA1.

MD5 and SHA1 are bad for password hashing indeed, but that's because they're
fast, not because they have known collisions.

Collision attack has nothing to do with password security. For passwords the
relevant attack is the preimage attack, which is a different thing and there
are no feasible preimage attacks against these hashes ( _yet_ , of course).

------
scrollaway
Can you please look into Persona and recommend that instead of openid connect?
It is a much better approach at decentralized authentication.

~~~
omervk
I have. Please take a look at another comment that explains the issues with it
here:
[https://news.ycombinator.com/item?id=7943695](https://news.ycombinator.com/item?id=7943695)

~~~
scrollaway
I had already replied to that comment.

------
mcovey
instead of "shittysecurity.com" you might want to use something like
"example.com", for one because some people will see it as inflammatory, and
because some eager devs might be presenting this to bosses who will take
offense, and based on that emotion, decide the whole thing is bullshit.

~~~
omervk
Good point.

------
philk10
[http://plaintextoffenders.com/faq/non-
devs](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

~~~
omervk
1\. You're right. Fixed.

2\. Rephrased.

------
ten7
Thanks 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.

~~~
omervk
Soon :)

------
daddykotex
Let's say I register for a Web Hosting solution. And then I receive a email
containing a username built upon the information I gave them and a generated
password to access the cPanel.

Is this offending? Let's also pretend that I have to change this password upon
my first login.

~~~
omervk
Yes, because you might not be the first to use that password.

------
thesumofall
For [11]: I think it makes sense to also highlight other approaches than
OpenID such as [https://passwordless.net](https://passwordless.net) which is a
sort of way in the middle (disclaimer: I'm the author)

~~~
scrollaway
As a huge supporter of Persona, I am intrigued. Can you sell me on how this
may be better?

~~~
thesumofall
Also, Persona still relies on passwords which are usually too weak and re-used
across the web

~~~
thesumofall
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.

------
bdg
Creating 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."

~~~
omervk
What would you suggest?

~~~
jchung
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.

~~~
omervk
That's a great idea! I'll add "I've been listed! What do I do?" to the FAQ.
Thanks!

------
omervk
Wow, thanks for all of your points and suggestions! Unfortunately, I'll only
be able to attend to them in an hour or so, so please bear with me and I
promise personal attention to each any every point made here.

------
eldelshell
This is something that came to mind while reading the comments: Why should me,
the owner/developer of some service, care if somehow your password is
stolen/guessed by any mean?

I'm not saying we shouldn't take care of our users, but how's our fault that
their email is hacked? We can't do anything to protect against this and
placing more complex policies would hurt users who have enough common sense to
this properly and expecting the same from us.

P.S. I'm in no way saying to to ditch all security procedures we can, but to
one point security is about trust, and if you can't trust your users to keep
their freaking passwords and email accounts secured, then hell with them. Put
it in plain text in your TOS and be done with it.

~~~
marcosdumay
Do you have any idea how email works?

You could as well just publish your users passwords at your front page, and
claim that if a user has a password compromissed because of that, it's his own
fault, you should be able to trust them not to use insecure services.

------
peg_leg
You shouldn't be able to see their passwords in the first place, let alone
send it to them. You should only store a one-way encrypted string based on the
password they typed.

------
Frozenlock
I don't see how sending a reset link is secure.

Wouldn't anyone intercepting the email be able to use the reset link
themselves and gain access to the account?

~~~
lotyrin
Reset links can at least time out, passwords generally don't.

Providers should send you notifications when you reset your password, they
generally don't when you just log-in like normal.

------
geoffsanders
Or don't use passwords? [https://launchkey.com](https://launchkey.com)

:)

~~~
omervk
I'd appreciate it if you could post this as a comment on the page itself. :)

------
john2x
Is a plaintext (heh) list of all the sites available?

~~~
omervk
Soon :)

------
LukeB_UK
I disagree with point 11. You shouldn't rely on someone else's service to be
the way for users to access yours.

~~~
troels
It's pretty hard not to though. You rely on your hosting provider for service
and probably on a multitude of software services too. Of course you have to
weigh the value of each further point of failure in your setup, but it's a
tradeoff and may well be worth it.

~~~
sp332
Yeah, but I can switch hosting providers. What happens when I switch login
providers?

~~~
troels
Valid point. Still - that doesn't categorically make it a bad choice. It just
weighs a bit heavier on the con side. There are some positive effects of that
dependency as well (User trust and convenience).

