Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Passwords in plain text

plaintextoffenders.com

Post reply on HN
Print view View original

71–80 of 116 posts

Re: Passwords in plain text

#71

Post by oneeyedpigeon »

uulbiy wrote: post #54
fooyc wrote: post #46

Earlier quoted context omitted.

That's really trivial, and many web applications work this way: email = input.email plainPassword = input.password hashed = hash(plainPassword) saveToDb(email, hashed) sendGreetingEmail(email, plainPassword) Emailing a plain text password during registration is not the same as storing it forever in a database.

It's not the same but there are other security issues. The server to server transfer of the email message might not be encrypted (it might be if both have TLS extensions enabled). So, emailing plain text passwords is always a bad idea even if it's not stored as such.

Having the user send their password over a non-SSL connection when they choose it in the very first place is also less-than-perfect security. Having the user ever type in their full exact password is less-than perfect, because of key-loggers; when asked to choose a password the very first time, the system should ask how long it is, then ask for random characters from it until the whole thing has been supplied.

OR, we should just accept that there's a whole magnitude of difference between sending a password by email on a single occasion, and storing it in plain-text, and focus on the latter problem first.

Re: Passwords in plain text

#72

Post by aianus »

oneeyedpigeon wrote: post #71
uulbiy wrote: post #54

Earlier quoted context omitted.

It's not the same but there are other security issues. The server to server transfer of the email message might not be encrypted (it might be if both have TLS extensions enabled). So, emailing plain text passwords is always a bad idea even if it's not stored as such.

Having the user send their password over a non-SSL connection when they choose it in the very first place is also less-than-perfect security. Having the user ever type in their full exact password is less-than perfect, because of key-loggers; when asked to choose a password the very first time, the system should ask how long it is, then ask for random characters from it until the whole thing has been supplied. OR, we…

> Having the user send their password over a non-SSL connection when they choose it in the very first place is also less-than-perfect security.

Who does that? That's even worse than storing it in plain text on the backend.

Re: Passwords in plain text

#73

Post by jeltz »

mrcdima wrote: post #70
p8952 wrote: post #63

Earlier quoted context omitted.

You should be sending a token and/or reset link which will allow the user to choose a new password. This is much better than just sending a new password because: * It can have a TTL. * The user has to change it, they can't just keep using the plaintext one forever. * You can perform some kind of verification, was the request for a new password sent from the same country/IP/device as the person generating a new passwo…

But can't you implement all three with a temporary password as well? Make the password valid for 24 hours only and when the user logs in with their temporary password perform any kind of extra verification and if that's passed then also force the user to change their password. Seems like the same thing. The website I noticed on the front page (sunsuper.com.au) was doing precisely this (although their TTL was 90 days…

Yes, but using a token is better for usability and trust since that wont make it possible to lock out other users by clicking the forgot password link, and I as a user will think it is more likely someone doing token based resets has done security correctly.

Re: Passwords in plain text

#74

Post by jackalope »

jivid wrote: post #53
salimane wrote: post #20

digitalocean.com stored your password in plaintext!!!

I am a Digital Ocean customer and the only password they've ever emailed me is the root password for the server I just bought. Arguably this isn't as safe as AWS' process of making you download a kaypair and only letting you login with that. However, VPS owners should get in the habit of logging on to any server they buy and immediately disabling password auth and root login via SSH, which helps negate the root passw…

How is downloading a key pair generated by someone else safer? If this is only for login purposes (I don't use AWS, so maybe there is another reason), you should generate your own key pair and send them only your public key (which doesn't require an encrypted transfer, BTW). If AWS knows your private key and can view it or provide it to you at anytime, that's no different than storing passwords in plaintext.

Re: Passwords in plain text

#75

Post by oneeyedpigeon »

aianus wrote: post #72
oneeyedpigeon wrote: post #71

Earlier quoted context omitted.

Having the user send their password over a non-SSL connection when they choose it in the very first place is also less-than-perfect security. Having the user ever type in their full exact password is less-than perfect, because of key-loggers; when asked to choose a password the very first time, the system should ask how long it is, then ask for random characters from it until the whole thing has been supplied. OR, we…

> Having the user send their password over a non-SSL connection when they choose it in the very first place is also less-than-perfect security. Who does that? That's even worse than storing it in plain text on the backend.

The first site [1] on the blog in question, for example.

[1] http://www.assosfactoryoutlet.com/customer/account/create/

Re: Passwords in plain text

#76

Post by joesb »

__david__ wrote: post #31
rimantas wrote: post #29

Earlier quoted context omitted.

Well, what would you do with an encrypted password sent to you by email? How do you propose to solve this? Using password reset links instead changes very little.

> Using password reset links instead changes very little. Actually it changes a lot. Password reset links are one time only, and they get sent before you change your password. Mailing your password in plaintext after you've just changed it means it's good even if someone gets a hold of it months or years later. That's significantly worse.

Password can be one time password, too. Require user to change their password the first they login is not an advance feature.

Re: Passwords in plain text

#77

Post by jivid »

jackalope wrote: post #74
jivid wrote: post #53

Earlier quoted context omitted.

I am a Digital Ocean customer and the only password they've ever emailed me is the root password for the server I just bought. Arguably this isn't as safe as AWS' process of making you download a kaypair and only letting you login with that. However, VPS owners should get in the habit of logging on to any server they buy and immediately disabling password auth and root login via SSH, which helps negate the root passw…

How is downloading a key pair generated by someone else safer? If this is only for login purposes (I don't use AWS, so maybe there is another reason), you should generate your own key pair and send them only your public key (which doesn't require an encrypted transfer, BTW). If AWS knows your private key and can view it or provide it to you at anytime, that's no different than storing passwords in plaintext.

The keypair AWS generates can only be downloaded once, at the time of instance creation. Beyond that, they expect you to be in possession of the keypair when launching another instance that uses the same keypair. If you happen to lose the file, you're basically out of luck.

So to directly address your concern, you can't download the keypair at any point in time, it's just a one time thing. To me that seems much more secure than emailing out a root password and enabling password authentication by default.

Re: Passwords in plain text

#78

Post by jacobparker »

watwut wrote: post #58
TomGullen wrote: post #57

Earlier quoted context omitted.

> as using them is barely above plain text in terms of security these days How so?

If I recall right, those functions are too fast. It is too easy to iterate through all kinds of possible passwords and you are likely to find plenty of matches. At minimum, you need to add unique salt to each password. It forces the attacker to run dictionary on each account separately. It is also recommended to use different slower hash function or iterate MD5/SHA1 thousands times, so he will be much slower.

Try to avoid directly invoking "SHA256" in your own security-related code.

good: http://en.wikipedia.org/wiki/PBKDF2

gooder: http://en.wikipedia.org/wiki/Scrypt

Maybe avoid using SHA256 with them because of Bitcoin ASICs. If your passwords get leaked in hashed form, even with these, you'll still want to tell your users and advise/force them to change their passwords. Forcing makes more sense if you have 2FA to something not likely to be accessible with their previous password (SMS maybe?)

Re: Passwords in plain text

#79

Post by marcosdumay »

kremlin wrote: post #26
pjscott wrote: post #8

Earlier quoted context omitted.

There are some ways to do that sort of thing safely, for some value of 'safe', but they're non-trivial. Sticking the plaintext passwords in a database row is trivial. Which do you think is more common? :-(

There's a fairly trivial way to do it in Django I think (whether it's still safe to send an email with pw in plaintext is still questionable at best): Say a user forgot their password and they click some link to reset their password: Generate the password text, then create an email with that password, send the email, and then store the password, connected to the User object, in the default Django way, which is SHA'd.

The Django builtin functionality is more secure than that. Do not send passwords in email.

You should create a token, and mark the account with it, send the token to the user, and if the user sends the token back to you (at the URL, normally), you let him replace his password. The password itself is never communicated back to the user.

Re: Passwords in plain text

#80

Post by HarrietJones »

A lot of talk of passwording concentrates on threats at the technology end, and they ignore threats at the user end.

Emailed Passwords are a failure from a tech point of view, but they allow users to create more complex passwords without punishing them when they forget that password.

As it is, I have situations now when the complexity requirements of a password combined with the fact that I need to sign in to a separate mobile App and I'm given no way of seeing what the password was when I created it that I just throw my metaphorical hands in the air, and reset it to generic password "Green!12Letmein." on yet another account.

This is wrong of me. I know it's wrong, I'm aware of password remembering services and I'm technical but I still do it.

If I'm doing this, and you're doing this, then most of the world is doing it. By discounting passwords sent through email, then we may be making overall security worse instead of better.

Post reply on HN