But why can't I send people their passwords?

https://news.ycombinator.com/item?id=7943365

by omervk • 12 years ago

201 174 12 years ago

news.ycombinator.com

Hi all, this is @omervk, one of the co-founders and maintainer of Plain-Text Offenders [1].

I've just finished creating two FAQs: One for developers who come to the site and don't understand what's wrong with what they're doing [2] and another for the laymen who want to understand what we're all about and how to protect themselves [3]. The idea is that people could also send these links around to educate others.

As HN is one of our main supporting communities, I'd love to hear your thoughts about both of these new pages.

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

omervk27• 12 years ago

Clickable links:

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

awsh• 12 years ago

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

vadvi• 12 years ago

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

omervk27• 12 years ago

Fixed. Thanks :)

couchand• 12 years ago

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?

omervk27• 12 years ago

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

jere3• 12 years ago

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.

weaksauce4• 12 years ago

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

jere3• 12 years ago

This is certainly a good point.

kenny_r• 12 years ago

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.

MrTortoise• 12 years ago

in which case they wouldnt be using the password reset mechanism

personZ6• 12 years ago

You'd be giving the attacker the keys to the kingdom.

No, the people who use a common password gave out the keys.

There is simply no excusing it. The apologism for it has to stop. NEVER use the same password across multiple services. If one service gets compromised, the extent of their culpability is their own service. Anyone whose password exposes other things was the cause of their own demise.

EDIT: I will not back down from this (and you shouldn't feel too ashamed for reusing passwords and falling in the above buckets, desperately hitting down arrow. Just correct your mistakes). It is utter idiocy to constantly defend the habit of shared passwords, when people give it to services of zero trust, and with unknown habits and practices. When some service of no consequence stores your password in plaintext, that is them being dumb. If you then complain because it's the same password used elsewhere, that is you being dumb.

Mithaldu2• 12 years ago

"Man In The Middle (MITM)" is the important bit. For example by sniffing the wireless traffic on an unencrypted wlan you can capture entire emails being sent or received, without ever compromising the account.

slight• 12 years ago

  - Request password reset.
  - Sniff email with reset link.
  - Go to reset link before user does and change password.

Rapzid• 12 years ago

Entire clear text emails. Everyone SHOULD be using TLS wrapped email protocols. That doesn't mean they are, but gmail is https all the way and many providers now require TLS connections to the mail servers.

Still, one time use password reset links with explicit instructions and set expectations to reset the password immediately is the way to go if you're emailing anything IMO.

jaredmcateer2• 12 years ago

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?

x86_64Ubuntu• 12 years ago

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.

omervk27• 12 years ago

Thanks, I've added that to the FAQ. :)

biggerfisch• 12 years ago

The FAQ isn't saying that the only bad thing is that email accounts might be compromised, simply that that's one reason to not email passwords. While you're right about email comprises allowing an attacker to simply reset a password, the first few sentences are still very important.

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.

Email by default right not isn't encrypted. Anyone (eg, a 3-letter government agency or a malicous actor on an unencrypted wifi network) who can intercept your traffic can read that password - and you can't even tell. At least with a password reset there's the "notification" of "my password doesn't work anymore". That's mitigated by SSL/TLS, but it's still an important point to consider.

pmjordan2• 12 years ago

If someone hacks into your email account, they can just trawl through the email archive and harvest passwords from past password reminder emails. With a temporary reset token, they have to initiate a password reset request, which you should notice: (a) you might notice the email if you have e.g. push notifications enabled, or if the attacker doesn't delete it quickly enough, and (b) your real password will suddenly stop working.

Additionally, even if your reset request is harvested via MITM, if you use a single-use reset token, and an attacker uses it before you can, you know something is up. Even if it's not single-use, your password suddenly no longer working should ring alarm bells.

hackuser• 12 years ago

And if someone hacks the system administrator's account, they may find everyone's passwords (for systems where the admin sets the pw and emails it).

bartwe• 12 years ago

You're current password shouldn't stop working because otherwise that can be used as a denial of service without otherwise compromising the security of either the user or the site if the email address is known.

ajanuary3• 12 years ago

I agree; this point shouldn't be about password reset emails being more secure, it should be about the fact you don't need to be able to email them their password to have a successful account recovery process.

That said, it can be more secure. Firstly, people reuse passwords, so intercepting a plaintext password gives you access not only to the account on that site, but also several others.

Secondly, if the link expires you can't use old account recovery emails to find out passwords. If you manage to compromise an account (rather than mitm), you can search through for old "here is your password" emails and use those without even having to initiate a new password recovery process, which in this age of mobile devices and push notifications risks the victim seeing the email and getting suspicious.

pbreit• 12 years ago

Exactly. This action is so obviously horrendous it's had to believe it still happens. Once a password hits your inbox, you can almost count on it living forever. And Basically with one 5 second search of my inbox for "password" a thief could easily discover my password that I use for almost every web site.

It's totally irresponsible for a service provider to essentially reveal a secret like that (without asking or really, ever).

powatom• 12 years ago

True - but you can add an additional layer of security to the password reset request if this is a concern, such as personal questions.

gpvos• 12 years ago

Using personal questions for security is the worst thing ever.

Whenever I encounter them, I paste the output of "dd if=/dev/random bs=1k count=1 |uuencode x" into the field.

6d0debc071• 12 years ago

I can never remember the answers to those damned things.

3pt14159• 12 years ago

The main reason not to do it is that people don't always have control over their email, for example, school, work, etc. Also, some courts can force you to give up an encryption password, but many can't. By sending a password in the clear you can be inadvertently giving the court a password that they otherwise wouldn't have had.

blkhawk• 12 years ago

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

Not really the main issue - if you always send the password the Thief controlling the email does not even need to reset the password. he can get in without leaving any trace at any time. It also allows the collection of all the Passwords from all the users in bulk. And if your users are reusing their passwords everything else is open too.

Sending the Password is just a stupid policy. Its up there with restrictive Password requirements and Server-side unhashed Password storage.

jcampbell1• 12 years ago

In 2007, Gmail had a XSRF vulnerability for setting up filters. It was exploited by attackers that would create a filter 'Contains "password"', 'Forward to: evil@example.com', 'Run on all messages'.

Basically you could visit a malicious webpage, and all emails containing the word "password", would be sent to the attacker.

krambs• 12 years ago

You shouldn't send the password because you shouldn't be storing the password. Worries about email security, etc. are secondary.

larrybrid• 12 years ago

Yeah, I was surprised to see that this bit wasn't mentioned anywhere. If you are emailing someone their password in plaintext, that means you know their password in plaintext -- which you should not.

cookingrobot• 12 years ago

Gmail should make you type your password again in order to open password-reset emails sent by other services.

This would close the "I accidentally left my account logged in" hole.

xyproto• 12 years ago

The "log in again to do something secure" is a rabbit hole, where suddenly you have to log in again to do anything it all. It could become a login nightmare.

ademarre• 12 years ago

I expect people would not understand this. They would start to get confused between their Google password and that of the service they are trying to access.

Also, after users learn the new process, it opens up a new phishing attack vector for Gmail.

chacham15• 12 years ago

Most of the other points, while correct miss the big issue: the server should not store the password in case they themselves get hacked. If an attacker gains access to one persons email then he gets 1 password. If he gains access to a server then he can potentially gain access to thousands of passwords. Therefore, having plaintext passwords makes you a target for attackers.

Sami_Lehtinen• 12 years ago

True, email shouldn't be used for password recovery nor user authentication anyway. But guess what, many sites still do it. Even if site security is otherwise flawless, password recovery using email ruins everything.

SkyMarshal• 12 years ago

Would you send your user's password to them on a postcard? If so, by all means feel free to send it in email.

LukeB_UK• 12 years ago

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

troels2• 12 years ago

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• 12 years ago

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

adwn2• 12 years ago

Actually, that FAQ entry itself already counters your argument: "Treat it like you would payment - you wouldn’t write a whole payment gateway like PayPal - but instead use a 3rd party." Where's the difference?

By the way, you can always allow users to connect several OpenIDs to a single account – this way, worried users can provide redundancy themselves, if desired.

thesumofall4• 12 years ago

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

scrollaway7• 12 years ago

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

thesumofall4• 12 years ago

I think Persona is great and can be the right choice for many scenarios. Browser support, the JS requirement, and the reliance on email (whereas tokens can e.g. be distributed via text message) might however be points that convince developers to go with one-time passwords.

thesumofall4• 12 years ago

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

omervk27• 12 years ago

Added. Thanks :)

blueatlas• 12 years ago

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?

scrollaway7• 12 years ago

What is the thinking behind disallowing certain characters? When you create artificial limitations you have to justify them, not the other way around.

pdpi• 12 years ago

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.

user24• 12 years ago

Can't speak for OP, but surely putting restrictions on your password just makes people choose weird, eminently forgettable passwords, a la xkcd's complaint http://xkcd.com/936/

adwn2• 12 years ago

What's the thinking here?

I sucks for people that generate individual passwords based on a common password and site-specific data.

furyg3• 12 years ago

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.

nly• 12 years ago

While it's true their changes made the key space smaller and, even with a good KDF, 8 chars was never long enough to begin with, the reduction is negligible. Assume 36 char (alphanumeric, case insensitive) passwords:

Originally:

    36^8 + 36^7 + 36^6 + 36^5 + 36^4 + 36^3 + 36^2 + 36
    2,901,713,047,668 possible passwords
    ~41.4 bits

After:

    (36^8 - 26^2 * (8*7)/2) + (36^7 - 26^2 * (7*6)/2) + (36^6 - 26^2 * (6*5)/2)
    2,901,650,810,624 possible passwords
    still ~41.4 bits

Only 62,237,044 possibilities eliminated. Length is the most important factor, so this was probably a good decision if most of their users were using <= 6 char passwords, or not using numbers at all. And frankly, the financial sector should be using HSMs anyway, making weak KDFs irrelevant.

moistgorilla2• 12 years ago

Making the minimum password length 6 characters reduces the possible outcomes by a negligible ammount.

stonemetal2• 12 years ago

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.

jabbrwcky• 12 years ago

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

Grue3• 12 years ago

In fact, very long passwords can be successfully used to DDOS some setups (i.e Django used to have such vulnerability). It's much simpler to put a sane upper limit, like 1024 characters.

omervk27• 12 years ago

Thanks, I used your number, too. :)

scrollaway7• 12 years ago

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

omervk27• 12 years ago

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

scrollaway7• 12 years ago

I had already replied to that comment.

_mulder_• 12 years ago

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

omervk27• 12 years ago

Good idea. Implemented.

vomitcuddle• 12 years ago

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

thefreeman• 12 years ago

Ack, I accidentally down-voted this comment, someone please right my wrong

huxley• 12 years ago

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.

masklinn2• 12 years ago

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/

[1] https://pythonhosted.org/passlib/lib/passlib.context.html?hi...

omervk27• 12 years ago

That's a good point, but I think it goes a bit over what I was getting at.

peterwwillis• 12 years ago

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/ as an example of how many more places are implementing 2FA. Passwords are dead; long live passwords with 2FA.

omervk27• 12 years ago

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• 12 years ago

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

philk10• 12 years ago

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

omervk27• 12 years ago

1. You're right. Fixed.

2. Rephrased.

ten7• 12 years ago

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.

omervk27• 12 years ago

Soon :)

john2x• 12 years ago

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

omervk27• 12 years ago

Soon :)

eldelshell• 12 years ago

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• 12 years ago

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.

omervk27• 12 years ago

Because then users would lose faith in your service? Also, your service can then be abused. Think about a hacker ramping up charges on a credit card, only to have fraud detection activated and you losing money (and getting worse rates in the process).

cincinnatus2• 12 years ago

And when your server is inevitably compromised and your users passwords stolen from you due to your lack of dillgence and used to compromise logins on other services, what then? Still their problem?

omervk27• 12 years ago

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.

makmanalp• 12 years ago

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.

omervk27• 12 years ago

Thanks, I've added wording for that.

ufo• 12 years ago

I prefer makmanalp's explanation to the wording you are using right now. It emphasizes that hashing is an one-way operation and "encryption" or "scrambling" are more familiar and less abstract than "representation". I know its not an accurate usage of the terms but this is the layman FAQ and we could always add a link to a more in-depth explanation using the correct terminology (hashing, salts & key strength).

ajanuary3• 12 years ago

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.

prawks• 12 years ago

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)

drewcrawford• 12 years ago

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.

bdg• 12 years ago

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

omervk27• 12 years ago

What would you suggest?

jchung• 12 years ago

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.

jscheel• 12 years ago

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

moistgorilla2• 12 years ago

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.

Jemaclus• 12 years ago

My 401K company, Kibble & Prentice, does the same thing. They make you call a phone number if you forget your password, and then the operator reads the password out loud to you over the phone. Freakin' amazing. I told HR and they said they'll change companies, but that was six months ago, so... who the hell knows.

daddykotex• 12 years ago

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.

omervk27• 12 years ago

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

aturek• 12 years ago

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

omervk27• 12 years ago

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

TallGuyShort3• 12 years ago

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.

omervk27• 12 years ago

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

TallGuyShort3• 12 years ago

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?

bwy• 12 years ago

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.

7952• 12 years ago

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.

peg_leg• 12 years ago

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.

a1a• 12 years ago

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

mcovey• 12 years ago

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.

omervk27• 12 years ago

Good point.

pornel• 12 years ago

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

Frozenlock• 12 years ago

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• 12 years ago

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.

tptacek• 12 years ago

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.

omervk27• 12 years ago

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.

geoffsanders• 12 years ago

Or don't use passwords? https://launchkey.com

omervk27• 12 years ago

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

But why can't I send people their passwords?

Related Stories