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

61–70 of 116 posts

Re: Passwords in plain text

#61

Post by omervk »

aunty_helen wrote: post #38
omervk wrote: post #12

Hey guys, I'm @omervk, one of the co-founders and the maintainer of PTO. Always a pleasure to be featured on the front page of HN. You're welcome to ask me questions, though we've covered most on our about page ( http://plaintextoffenders.com/about ). The one we haven't is usually "Is there an API/better search/new site coming?" to which the answer is that we're both doing this in our spare time and though we really…

A couple of simple client-server type graphics would do a lot in explaining why this is an issue to the layman.

That sounds lovely! Can you help us either in making it or recommending someone who might be able to?

Re: Passwords in plain text

#62

Post by fooyc »

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.

I agree that from a security standpoint it's better not to send the password in plain text at all.

But then you can start listing non-HTTPS sites, too. You disclose your password in plaintext to many servers every time you login on those.

Re: Passwords in plain text

#63

Post by p8952 »

mrcdima wrote: post #48

But how does one handle password resets without resorting in one form or another to sending some info in plain text to users? At least one website on the current front page is there because it sent a temporary password in plain text. I assume this happened because the user forgot his password. This says nothing about how they store passwords and after all how else would you handle a password reset? Send a password re…

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

Re: Passwords in plain text

#64

Post by omervk »

Daiz wrote: post #39

Should really start doing this for sites using MD5/SHA1 for password hashing too, as using them is barely above plain text in terms of security these days.

How would one gather that information? What form of evidence would you accept?

We'd like to refrain from asking people to hack into sites just to figure out their hashing scheme :)

Re: Passwords in plain text

#65

Post by scrollaway »

omervk wrote: post #12

Hey guys, I'm @omervk, one of the co-founders and the maintainer of PTO. Always a pleasure to be featured on the front page of HN. You're welcome to ask me questions, though we've covered most on our about page ( http://plaintextoffenders.com/about ). The one we haven't is usually "Is there an API/better search/new site coming?" to which the answer is that we're both doing this in our spare time and though we really…

Cool stuff. I was working on a similar site for a while which would give stars to site depending on their various security practices:

- HTTPS, HSTS support

- Password hashing (and type of hashing if available)

- Third party auth support (OpenID/Persona)

- 2FA

- ...

Is this something you would like to go towards? I would love to help (depending on the backend of the site, I may offer technical help too)

Re: Passwords in plain text

#66

Post by TimWolla »

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…

… or even better: Disable password authentication entirely.

Re: Passwords in plain text

#68

Post by omervk »

omervk wrote: post #12

Hey guys, I'm @omervk, one of the co-founders and the maintainer of PTO. Always a pleasure to be featured on the front page of HN. You're welcome to ask me questions, though we've covered most on our about page ( http://plaintextoffenders.com/about ). The one we haven't is usually "Is there an API/better search/new site coming?" to which the answer is that we're both doing this in our spare time and though we really…

One more very important thing that I neglected to mention is how you can help:

- Submit offenders - Spread the word (we're also on Facebook and Twitter (@plntxtoffenders) - Contact offending sites and let them know they're on the list

Re: Passwords in plain text

#69

Post by jonahx »

fooyc wrote: post #62
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.

I agree that from a security standpoint it's better not to send the password in plain text at all. But then you can start listing non-HTTPS sites, too. You disclose your password in plaintext to many servers every time you login on those.

Those should be listed too. I'm not sure I follow your point: Because there exists this other really bad but common practice, why are we harping on this bad practice?

Re: Passwords in plain text

#70

Post by mrcdima »

p8952 wrote: post #63
mrcdima wrote: post #48

But how does one handle password resets without resorting in one form or another to sending some info in plain text to users? At least one website on the current front page is there because it sent a temporary password in plain text. I assume this happened because the user forgot his password. This says nothing about how they store passwords and after all how else would you handle a password reset? Send a password re…

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 which is indeed far too long and it's impossible to tell whether they forced a password reset or simply recommended a password change).

Post reply on HN