Plain Text Offenders - Did you just email me back my own password? | Hacker News Reader

Plain Text Offenders - Did you just email me back my own password?

plaintextoffenders.com

234 pointsomervk141 comments

"We’re tired of websites abusing our trust and storing our passwords in plain text, exposing us to danger. Here we put these websites to shame."

Open articleView on HN

Nothing new there! When we setup a new in-house account, we either telephone the user or go to see them with their password. If it's a senior Manager with a corporate phone they get their password texted to them - Ok, not ultimately as secure as possible but a darn sight more secure than a plaintext email.

In my previous job I was asked to FTP our full client list (with financial information) to a third party acting on behalf of the company that had just acquired us. The IT Director of our new owners kicked up a hell of a stink and accused me of being 'unhelpful' because I insisted on the third party signing an NDA and installing AxCrypt so that I could encrypt the data for transmission. In the end I just said that if they insisted I send everying without encryption, I wanted it in writing with a disclaimer that I was acting on their instructions and they would assume responsibility for any possible liabilities arising with respect to UK Data Protection Laws.

By the time the IT Director had deliberated the point, the third party (who fully appreciated my position) had sent me a stock NDA, installed AXCrypt and we'd completed the transfer.

You say you telephone the users.

What if they are traveling? How do you verify the other person on the phone is who they say they are?

Worse, GSM encryption is pretty broken, people could be listening in, etc. Phoning people is still sensible in that attackers have to be close to the target, though (or get a wiretap).

Surprisingly not, mostly due to some very strange bits of the GSM protocol.

Basically, as long as you have enough signal such that the victims handset can hear your commands, you can tell it that you are stronger then any other signal, and the handset will instantly switch to your cell.

What's worse is that there exist secure GSM encryption/etc. standards, however as the cell tower chooses what encryption to use, it is mostly pointless. (I remember watching a video about this. Apparently your phone is meant to show a massive warning if they are using unencrypted GSM. None do).

http://www.youtube.com/watch?v=rXVHPNhsOzo is a good video about this.

There is a lot wrong with GSM, and I didn't even know about this particular attack (thanks!), but you still have to be reasonably close to the victim - it's harder than "attack from anywhere on the internet".

Most certainly agree. Unfortunately, dropping the range limit from "Anywhere on earth" to "From a nearby mountain" doesn't fill me with all that much confidence.

>How do you verify the other person on the phone is who they say they are?

This came up in another thread some time ago, and it was suggested that one very simple way to do this is to have the person call you back.

Ultimately though there is no real solution to this problem except meeting the person face to face.

That pretty much covers it. We telephone them in house on their extension number and there's only 60-ish employees so we know their voices. Externally they have to call back.

In enabling my Gmail account to use 2 factor authentication, Google required me to hand over my text-enabled cell phone number, and they texted me a code which I was required to input in a form. Similar to having the client call you back, but this can be automated.

The worst offender I can recall was Wordpress.com. Not only do they email you your password back, but show it to both you and whoever might be sitting within a few metres in LARGE LETTERS in the webpage immediately after activating your account.

After I emailed to complain about this, they said:

"Security and usability is often a trade-off. We make two main ones:

* When you register at WordPress.com, we show you your password and email it to you. * When you log in we tell you whether the username or password was incorrect.

The accessibility and increased convenience for users in both cases has been deemed to be worth it."

Edit: I just checked, and it seems that they've changed this element of their policy. The situation above was March 2009.

At least it's some consolation that they don't store the password in plain text, unlike plentyoffish.com. Do they also email you your new password if you change it?

Sorry, I didn't clarify: they showed in plaintext the password that I supplied and emailed my password back to me.

Emailing a password after registration does not, in itself, indicate that passwords are being stored in plain text.

In addition to this, the open source distribution of Wordpress hashes passwords.

My secure password being sent across the open net in an e-mail is reason enough to shame the company doing that.

While much is made about passwords being sent across the open net, almost every site short of banks allow you to reset a password with an email, which is a close to identical problem.

Reset links can have an expiration time.

A secure website should be mathematically incapable of ever displaying your plaintext password in any form whatsoever, at any time, even during the registration process.

How so? You can easily send out an email with the plaintext password, hash it and store it securely from then on..

True, but this would imply that the plaintext password would be passed around the application's internal infrastructure. Instead of just going into the frontend server, being hashed and then discarded, it would have to be passed to the email server, probably via some sort of message queue. This means the plaintext passwords would have to reside in some kind of datastore temporarily, possibly for quite some time if there is a backlog of registration emails.

This means you have to encrypt that store, which means you have to decide if you want to force EVERY email sent through the queue to adhere to the same security standards or just registration emails. Then you have to manage the keys for that encryption, and you have to audit it, blah blah blah blah, it quickly adds up to many many man hours of work.

All this just makes the whole thing more insecure, it increases the attack surface, and increases the work needed to secure the system and keep it secure. As it is not really necessary, IMO it shouldn't be done.

This also includes displaying the password back to the user in the browser, the plaintext password should be gone from memory before the templating engine is even invoked. The best way to solve problems is to simply avoid them.

Maybe I'm being unnecessarily paranoid, I like to think of it as a "security mindset" :)

What if you log all sent e-mails?

Then you have a great big log full of passwords, pretty much negating any security benefit of hashing them in the first place.

By that logic, how should the website know what password it should be hashing?

The hashing should be done in the client's browser. The plaintext password should never reach the server (which is capable of sending emails).

wut.

Actually, I think "wut" was a reasonable response.

If the browser hashes the password, that just makes the hash the plaintext password. You've accomplished nothing.

Not necessarily, if I understand the situation correctly. In this notation, -> represents communication between components, and | represents the boundary between local and remote communication, which we assume is encrypted/decrypted appropriately.

On account creation,

  password -> hash -> | -> stored

Upon account creation, I provide my password, which is hashed locally. The hashed version of my password is passed over the network and stored on the other end.

Logging in,

  password -> | -> hash -> compare

Upon logging in, I provide my password and send it to the remote server. The remove server hashes my password and compares it to what it stored previously.

Hence, if someone intercepted my hash, it's the same situation as if they looked in /etc/passwd on a multi-user Unix system. That is, it's more information than nothing, but it's non-trivial to use that information to figure out my password.

Is there a flaw in my reasoning?

This increases the password space (assuming a cryptographically strong hash), but if the datastore is compromised, an attacker can just bypass the client hashing (by changing JavaScript, etc) and just pass in the hash itself.

Whoops. The protocol you described is actually secure against that, since your login passes the preimage to the server for hashing and then comparison.

Yes, if someone breaks into the server, and changes the code for the login process, they can get around this. But that's always true. The server is a higher priority target than a single account. If your scenario requires breaking a higher priority target than the one in question, it's not really a security hole.

Similarly, someone can compromise my account on a Linux box if they get root access. They won't know my password, but they can change my password or just replace the login program with their own. But we consider getting root access a higher target that compromising a single account.

In other words, this is begging the question.

edit: I must have responded to a different understanding.

That's an interesting idea, but I don't know what you're protecting against. You're still providing the plaintext to the remote end eventually, so I assume you trust them. You're assuming the communication is encrypted.

What does this scheme protect you against, compared to the normal technique (part #2 in your example)?

If your password is never stored in plaintext, it's less likely to be leaked, either maliciously or inadvertently. It's the same rational for not storing plaintext passwords on a Unix system.

Like on a Unix login, I have to provide the actual password to the service. But measures can be taken to ensure not only is the password itself never stored, but even that the memory that contains the password is appropriately zeroed after use. It's not a matter of the user trusting the service, it's a matter of the service being cautious with itself.

There's no need for a new protocol; lots of websites manage to never store passwords today. I guess your protocol does provide some assurance that the other end isn't going to store anything but the hash. Unfortunately, anyone competent enough to implement it is already probably doing the right thing, and the people doing the wrong thing frequently have business reasons for doing it wrong.

I think this actually does protect you from exposing your password to an attacker, but only at account creation time. If the attacker waits around for you to log in conventionally at some later time, then it's over.

That only protects you at account creation time. How about this:

Password hash function is h. Client creates password p, hashes it 1000 times.

Account creation: Client sends h^1000(p) to server in the clear. Server stores h^1000(p) in plain text. Attacker eavesdrops h^1000(p), which is useless.

Log in: Client either looks up h^999(p), or calculates it from scratch starting at p. Client sends h^999(p) to server in the clear. Server hashes this to get h^1000(p), which matches what it has stored. Server replaces stored value of h^1000(p) with h^999(p). Client is permitted to log in. Attacker eavesdrops h^999(p), which is now also useless.

Log in 2: Client either looks up h^998(p), or calculates it from scratch starting at p. Client sends h^998(p) to the server in the clear. Server hashes this to get h^999(p), which matches what it has stored. Server replaces stored value of h^999(p) with h^998(p). Client is permitted to log in. Attacker eavesdrops h^998(p), which, again, has become useless.

...

Once the client gets down to around h^100(p), server (which has also been keeping count) starts prompting client to create a new password before the hashes run out.

(If you run out of hashes, you're screwed. You can log in one last time by sending p in the clear and having it stored in plain text. Attacker eavesdrops p, which is useless here but may be extremely useful elsewhere for obvious reasons. After this, you can never log in again.)

NOTE: obviously this assumes the hash function is irreversible, mostly free from collisions and quick to execute. Also, the user should ideally NOT log in like 1000 times in a week. Both achievable goals, though.

The purpose of this is not to protect against eavesdropping - note I said that the communication with the server was encrypted and decrypted as appropriate. Really, I was just presenting an existence counter-example to the claim that if the browser performs the hash, the hash itself becomes the plaintext password. This is a scheme where the browser performs the initial hash, and the user still uses the same password.

That aside, the only thing it gets for you are less code-paths you have to worry about that handle the password in plaintext. It's an application of the principle to only communicate what is strictly necessary to function.

The only problem I see with this is in cases where you sign in from multiple devices. How would each device know which x (for h^x(p)) you are on? Is that something the server sends to each device at login time? Would that be a security risk? I don't know a lot about this so these may be stupid questions.

I believe you have just reinvented OTP, one time passwords.

Geez, you're right. I went all the way through the Wikipedia article on cryptographic hash functions looking for something similar to what I'd just described, but there was no link to THIS:

http://en.wikipedia.org/wiki/Hash_chain

The resemblence is actually spooky. I swear I've never read that article before now.

"Hence, if someone intercepted my hash, it's the same situation as if they looked in /etc/passwd on a multi-user Unix system."

Except that now the hash is your password, as far as the system is concerned. If someone intercepted your hash they could just pass the hash off to the site and they have full access. This isn't quite as bad as accessing the plain-text password (which potentially is shared across multiple sites) but it's still bad.

Also, there's an easy workaround for this problem, using SSL for login.

Go read http://en.wikipedia.org/wiki/Digest_access_authentication and become informed on how you can do hashing on the client's browser and actually gain something in the way of security.

Digest mode has the issue that you need the plaintext password on the server side in order to do the authentication.

You clearly didn't read the link I directed you at. If you had you'd have seen that you only need MD5(username:realm:password), and would have been pointed at JBoss's DIGESTAuth implementation as an example of an implementation that does this.

"You clearly didn't read the link I directed you at." I do believe your tone is rather counterproductive to the purpose of this forum.

I did in fact read the article, and I do now agree that you only need to send MD5(username:realm:password) to the remote server to do the authentication.

The problem that I do see is that it is trivial for a MITM to either intercept the transaction and force the client into a less secure mode (ie. basic auth), and then read in the password, or else just reuse the auth credentials for another transaction.

I would recommend that you look at http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol and the concept of a "zero knowledge password proof" which seems to be the concept you were looking for.

Riddle me this batman: how does one get MD5(username:realm:password) onto the server?

The normal way is to capture that information in a sign-up page that is served over https. The point of digest authentication is not to replace https for what it is necessary for. It is to allow http and authentication to be used more securely than plain text authentication can be.

Incidentally your snideness is not appreciated. Generally something doesn't get to be a widely implemented RFC without the obvious questions having been asked and answered.

Capturing that information in a sign-up page that is served over https sounds an awful lot like the plaintext password is going to reach the server at which point the server will be mathematically capable of displaying it. That happens to defeat the entire purpose of this little subthread.

Your understanding of this subthread is very different from mine. I'm talking about practical security options for practical websites. In that case you don't care about information that was transiently present in the server for a fraction of a second once, you care about information that has been persistently stored.

But if you want such a ridiculous requirement, you can have JavaScript on the signup form that computes the hash on the client and sends it to the server. That form still needs to go over a secure channel (eg https) because the information sent, while not including the plain text password, is sufficient information for a sufficiently motivated attacker to get access.

We may actually be in agreement. I don't want such a requirement, it came from here http://news.ycombinator.com/item?id=2414550 and the link I first replied to, http://news.ycombinator.com/item?id=2414859

Your reply, coming where it did in the thread, gave the impression you thought digest auth somehow avoided ever sending a plaintext password to the server.

I was skimming the whole discussion and had missed that context. In that case I think we are in agreement.

There's one big win here I can see: your passwords don't exist in a vacuum. Many users, whether you like it or not, are going to be using the same password for a number of other websites.

By sending the hash and never letting the plaintext password hit the air, the worst that can happen is breach of your login system, you will not be responsible for someone in a coffee shop with wireshark sniffing out people's passwords, which can be applied to multiple websites.

Or, you do the registration process over SSL.

Indeed, a scheme like hashing-in-the-browser to keep a plaintext password "off the air" is essentially a homebrewed effort to replicate a secure connection.

IE, doing this is a mistake because you may be smart but you probably haven't put your secure connection through everything that SSL has been put through.

Yep, Etsy used to do that back in their more incompetent days. The only site I've seen that had a 'md5.js' script, seemed kind of unusual...

Yes, but if we have hash(plaintext + site_specific_salt), then even if I use the same password for different sites and the hash from one of them is intercepted, it still takes a while until the others will also be compromised. I didn't say the system was perfect, but still better than sending the password in plain text.

I believe a similar idea (use hmac(url, password) as a password for websites) is used to great effect by a firefox plugin.

Also, please do not use hash(x + y), use hmacs. String concatenation in hashing breaks some of the complexity guarantees and will lead to your hashes getting cracked faster then you'd expect.

If you have a public key associated with your email address on a public keyserver, they could encrypt your password—using said key—when you set it, and then store only the encrypted copy. Then, even though they were holding it, the only person who could do anything with it is you :)

That should address their accessibility concerns :)

Uh...

The standard, minimal approach is to keep secure hash of each password and throw away the password itself. This has the same effect but doesn't require the average, unsophisticated user to have a public keep.

But that's just the bare minimum approach - from there, you add a "salt" and other things. Done well enough, you should have a system where downloading your entire system shouldn't compromise your users passwords. But that's only if this is done really well - the write-up for how hbgarey got hacked actually is a great intro to this kind of thing.

http://arstechnica.com/tech-policy/news/2011/02/anonymous-sp...

My point was that you can retain the ability to email the user their own password with no loss of security (provided the user has a public key—like, say, Github or Heroku require, as they use passwordless ssh for repository synchronization.) My point was not that keeping someone's password around, is any better an idea than just allowing them to reset it :)

How about this use case?

You need to assign a password to a specific user account (they aren't registered, but are seeded into your system). I work on 3 different projects right now with this requirement. In this case, we create accounts for people based on a data pull from another agency, then contact those folks.

I generally agree with you (and plenty of fish is scary how they mail your pass every week or so!), but there are use cases where displaying cleartext passwords is acceptable.

> but there are use cases where displaying cleartext passwords is acceptable.

The only use case where sending and displaying cleartext passwords is acceptable is when the password is auto-generated and very long.

In all other cases, especially if the password has been entered by the user, this behavior is not only unacceptable, but also unexpected and thus the exact opposite of user-friendliness.

If they use the same codebase that is on opensource wordpress they store the password as an md5 hash which isn't much better. Take a look at the wordpress source code one day, you'll be horrified.

I spent around two years working on some of the highest traffic Wordpress sites out there and I came to the Winston Churchill-like conclusion that Wordpress is the worst blogging platform out there, except for all of the others that have been tried.

I totally disagree, Habari's code base is far superior to wordpress in every regard it simply needs a larger user base. Try it if you are looking for a new blogging platform you'll be pleasantly surprised. http://habariproject.org

I wouldn't argue that Habari is probably better code than WordPress, but it doesn't seem fair to compare a 0.7 product to something as functional and battle-tested as WordPress.

http://passwordfail.com/ lets people register the offenders. If you have the passwordfail chrome extension installed, you will get a warning whenever you visit an offender. Highly recommended.

Mailman ...

My LUG uses it and mails me my password in plaintext every month; IIRC it is|was the default setting ... /me-rolls-eyes

To be fair the Mailman registration page explicitly tells you not to use a secure password as it'll be mailed back to you in plain text.

And to be fair, you can't really do anything with that password except change your subscription status. That said, version 3 is in the works and I read that "feature" is going away.

I don't know, do the admins not get sent the email too as they are subscribed? It's a loooong time since I used mailman.

If you log in to Mailman, you can at least tell it to stop sending those emails every month...

Codeweavers, the creators of Crossover for Linux and OS X, do this. I emailed them about it around a year ago and they never bothered to reply back, even though I've bought several licenses from them over the years.

https://www.codeweavers.com/login/

By far the worst example I can think of here is Yodlee, the bank aggregator.

Their product, Moneycenter, has this convenient "feature" which lets you display your bank password in plaintext! It's unthinkable that someone you trust with your bank credentials would let their website be a two-way street for plaintext bank passwords.

Things like this remove any confidence I may have had in their product. The fact that a feature like this exists at all is strong evidence that they're neither thinking in a security mindset nor paranoid on behalf of their users. If someone proposed this "feature" where I work they would be laughed out of the room.

If that wasn't bad enough their support folks politely ignored me when I raised the issue and pleaded with them to turn it off. They either don't get it, don't care, or don't know how to escalate issues to people who do:

  Please be assured that Yodlee considers account/data
  security as highly critical and hence will not be revealed
  to any other source. 

  We suggest you not to reveal your account login credentials
  i.e answers to security questions & password, to anybody.
  This will ensure your account will not be compromised. 

  Thank you for your feedback on the product. We appreciate it. 

  We are marking this Service Request as Resolved. Please let us
  know if you have any questions in this regard.

How are they supposed to log in your sub-accounts without the password? They have no choice except to store the plain text password.

And they don't just show you the password - they make you enter your login password first.

What exactly do you want them to do? You aren't thinking this issue through. Do you just want them to hide the password from you? What would be the point? They still have it.

They also have a one-click login to your subaccounts, so even if they don't show you your own password it wouldn't be enough. I suppose you want this feature disabled too?

The point of not storing plain text password is not to avoid displaying them, it's to make sure no one else can steal them.

But yodlee has no choice, they must store it plain text. And once they do, displaying it - only upon your explicit request (so it's not accidentally displayed), and after you enter your password, seems reasonable to me.

I'm sorry but you're really not (a) paranoid enough and (b) thinking defensively (c) accepting the reality that users will make poor security decisions (d) recognizing that a service should do everything in their power to mitigate threats to their customers. Yodlee does a good job in many areas (security questions, special phrases and images, secondary password prompt for "riskier" operations) but still falls short here.

I realize that my credentials need to be efficiently convertible to plaintext at runtime within their service. They still shouldn't be stored in plaintext (it shouldn't be easy for engineering and operations staff to see my bank password by just looking at a database dump) though. In any case, I took the leap of faith that I trust Yodlee to keep my bank credentials secret when I signed up for their service in the first place. This is not what I was talking about.

I realize they force you to enter your password first. This is good but doesn't mitigate the threat I had in mind in the first place. It's Yodlee's responsibility to minimize the risk their service poses to their customers. Unless they can be 100% sure that the person signing in with my Yodlee credentials actually is me they need to consider the implications if it's not. Off the top of my head here are two obvious situations where Yodlee's "display plaintext password" feature puts users at higher risk:

1. User accesses Yodlee from a computer (maybe theirs, maybe their friend's, maybe a public terminal) which has a keylogger installed on it.

2. User is not security-conscious and doesn't realize the implications of this feature. Thinking Yodlee is read-only (like most other competing services) they use a weaker password than they should or even use the same password for Yodlee as on other sites. They shouldn't but it's a fact of life that they do.

In both cases the attacker can get the user's Yodlee password and then all of their bank passwords. They steal all of the user's money. Banks are generally willing to play ball and cover users for their losses if their account at that bank is hacked. Will they step up in the same way if they're hacked via Yodlee? I'm inclined to believe the answer is no. I don't even know if the bank should be expected to.

When choosing whether or not to build a feature, you need to consider whether its benefits outweigh its risks.

Trusting Yodlee with my bank credentials to aggregate financial data is a risk but doing so is the entire basis for their service and provides me with a huge amount of value. It enables scenarios which are otherwise completely impossible.

This "show plaintext password" feature is a small convenience which doesn't enable any new scenarios and has some pretty significant risks.

EDIT: I'm aware of the auto-login feature but didn't bring it up because it's almost the same as displaying plaintext passwords. Practically speaking it's a tiny bit less bad because an attacker can't directly view the password and use it on other services (assuming again that users make poor decisions and use the same password everywhere). Either way I think both should be gone.

> They still shouldn't be stored in plaintext

So how are they supposed to get your data from your bank if they can't login to it?

> User accesses Yodlee from a computer (maybe theirs, maybe their friend's, maybe a public terminal) which has a keylogger installed on it.

Just change "Yodlee" to "your bank" and the same exact problems happen. There is nothing special about Yodlee here.

> User is not security-conscious ..... they use a weaker password than they should [on Yodlee]

And when Yodlee asks them for their bank's password they don't realize what's going on?

I personally _like_ that Yodlee is explicit in saying to you "We have your bank password, be careful with your login". As opposed to making it seem like they have some backdoor, or authentication token to your bank, which they don't.

It's exactly the opposite of what you think - by letting you know they have the password you will be more security conscious with them. If that feature did not exist you might think that they were a "read only view".

> .... auto-login feature .... Practically speaking it's a tiny bit less bad because an attacker can't directly view the password and use it on other services

Do you think it works by magic? How do you think it logs you in to the other site? It uses your password! It makes an auto submitting form that has your password in it, in plain text, right there in the javascript!

> So how are they supposed to get your data from your bank if they can't login to it?

Like I said, there's no requirement for credentials to be STORED in plaintext. They just need to be readily convertible to plaintext when they pull your data. I'm thinking about a system where credentials are encrypted and access to the keys are locked down (either via software or hardware) so that engineers and operations don't have unimpeded access.

> Just change "Yodlee" to "your bank" and the same exact problems happen. There is nothing special about Yodlee here.

Two things:

1a. Like I already said, many banks protect their users from losses incurred if someone gets hacked while using the bank's online portal. They'll bail me out if someone gets access to my account and takes all my money. Will they bail me out if Yodlee is used as an attack vector? That would be nice but I'm not convinced that banks/brokerages/etc. will step up and help me out in that situation. Ideologically I don't even know if banks should be expected to.

1b. Will Yodlee bail me out if an attacker uses them to steal all my money? Nothing on their website indicates that they will. Even if they did, implementing these risky features just adds more risk and uncertainty to their business for a feature which isn't ultimately that worthwhile.

2. Yodlee is special because they're an aggregator. That makes them a significantly more valuable target than one bank alone. I have various accounts at various places, if someone got access to one of them at least the damage is contained. With Yodlee they get everything at once.

> And when Yodlee asks them for their bank's password they don't realize what's going on?

You'd hope so but can't assume, you're not just selling to technical and security-conscious users. Most of Moneycenter is looks like it's dedicated to read operations. There are just a few innocuous-looking links in the account management section which opens up this whole can of worms. I came to Yodlee from Mint, who doesn't expose anything in their UI which would allow writes. That was my expectation because write access via this kind of service is unthinkable to me. After I explored a bit and realized this I removed all my accounts.

> It's exactly the opposite of what you think - by letting you know they have the password you will be more security conscious with them. If that feature did not exist you might think that they were a "read only view".

I get where you're coming from but I think this is a stretch. If they're really trying to be upfront with their users about what can and can't be done they would be more explicit than two links for "auto-login" and "show my password".

Maybe the disconnect is that I want a read-only financial aggregator (i.e. Mint) whereas Yodlee tries to do more... but from my brief experience with Yodlee I didn't really even see many things that directly did writes. Most of the value I saw was in the reading/reporting.

> Do you think it works by magic? How do you think it logs you in to the other site? It uses your password! It makes an auto submitting form that has your password in it, in plain text, right there in the javascript!

Sorry, I wasn't really clear in my haste to edit the last reply. I know auto-login is only trivially and superficially different from showing a plaintext password. That's why I didn't even mention it at first.

EDIT: Actually I think the current implementation of auto-login may be worse than showing the password in cleartext. IIRC the user doesn't have to provide Yodlee credentials a second time like they do to view their bank password.

There are some cases when storing plaintext passwords is justified, despite all of the risks. There are cases where you can't - or shouldn't - hash passwords.

For Freeversation, we store plaintext passwords for two reasons:

1. Our passwords are group passwords, which (hopefully) aren't re-used anywhere else. If someone hacks our server, the conversations stored on it are incredibly more valuable than the passwords themselves, which aren't associated with a specific email address or account. Our approach to security is that unauthorized access to our server is checkmate. That is the worst case scenario, not stolen passwords.

2. When you create a new conversation, you can invite new users to the discussion. Those users didn't sign up for Freeversation - and in all likelihood never heard of Freeversation before - but they're expected to remember a password that someone else chose. We help them remember that password by including it in every notification email we send. (E.g. emails inviting them to the conversation, emails notifying them of new comments, etc.) We wouldn't be able to do that if we hashed passwords.

In our case, the alternative to plaintext passwords is actually getting rid of passwords altogether and replacing them with secret URLs. We chose plaintext passwords because they provide psychological reassurance that conversations on Freeversation are invite-only, and not public. The irony is that secret URLs are actually more secure than the passwords that most of our users choose. In the future, we may use a combination of the two, so that users both feel protected and are protected in the best way possible.

The catch is in the word hopefully.

Wishful thinking is not a successful way of doing things in engineering.

If someone creates and conversation and re-uses a password, that password is emailed to everyone they invited. There is no way to avoid that and still use a group password.

Edit: Furthermore, the password is not associated with a specific email address or user name. Even if someone has access to a conversation's password, they don't know who the password belongs to.

I don't know your use cases, so pardon me if this is naive, but couldn't you create a token that is unique for each user, and is consumed after use?

I'm not sure what you have in mind.

Our use case is explained on freeversation.com/about. Let me know if you have any questions.

Okay, having read that, I agree -- you absolutely don't have to worry about password theft. At least, not after the fact of a conversation having already happened.

However, what I was suggesting, is that instead of using a group password:

- create a random password for each user that is invited - as part of the 'login' process (or room join process, depending on how your code is structured), check to make sure that token exists in the database - as soon as somebody uses that random password, delete it (or mark it inactive)

This means that for each token, there can be exactly one login. That login should belong to who you sent the email to, and nobody else. It's just as anonymous as your method, and slightly (wee bit) more secure.

This also solves the problem of people sending the password to their friends, though obviously cannot plug the analog hole of allowing their friends to look at their screen.

No, it's only the worst-case scenario for you. The worst-case scenario for the users (your customers) is their password exposed. They don't care about your server.

Again, it's not a private password if they chose to share it with a group.

What if the group is that person and their dad, and they don't care if their dad knows the password to their gmail?

By definition, there is no point in having an anonymous conversation with your dad, because it wouldn't be anonymous. Right now, we're seeing freeversation used with much larger groups of people, where guessing which email matches the password is impractical, even if someone does reuse a password.

I've been wanting to make this for ages. Very pleased to see it made!

Would be awesome to have a notable offenders section. A chrome plugin that hooks into this would also be cool: "This site has rubbish password security. Don't use your usual passwords"

It's already planned :) Stay tuned!

Better add rel="nofollow" too. Or do you want to vouch for all these pages? If your PR rises, expect people to create plain-text systems just to get a dofollow link.

Also, do you check each and every service you put up? Or do you trust the random internet visitor to always do the right thing? Are you ready for and ok with any collateral damage?

Seems that in many cases you get a choice between security over the wire or security in storage, but not both. By this I mean if you use a challenge response authentication algorithm then you often don't have any choice but to store the password in cleartext. Then authentication can be done even over an unencrypted channel without revealing the password.

The compromise seems to be to store the password with a oneway hash then use an encrypted channel such as TLS to send the full password for each authentication. There is still the possibility of intercepting the password at the end of this encrypted channel before the password is compared to the stored hash.

So both models have weaknesses, it just means you have to focus your security efforts into a different area. For the first, it might be somewhere deep in the backend, for the second you'd be paying attention to the front end where you accept the TLS (e.g. https) connection.

This has certainly been the case with for example PPP where you had a choice between PAP (secure storage, but sent in plain text) or CHAP (insecure storage but not sent over the wire in full). Jabber/XMPP servers also traditionally store in plain text but passwords aren't sent for each login. Though it seems that HTTP Digest auth does allow storage of passwords in a hash without transmitting the full password.

Then even with challenge response algorithms if someone is able to monitor a number of authentications then they may be able to gather enough information to pose as that user without actually knowing the password.

If I understood you correctly - there doesn't need to be a tradeoff between wire and storage security.

You could use a oneway hash at the client side as well.

If you don't want to divulge what's the hash in your database, you can add another oneway hash for whatever reaches the server.

The challenge-response can also be based on hashes.

I tried to submit a screenshot, but got the error message Sorry, your page had expired. Please try again. on the submission screen. Either they're having trouble (and displaying an unhelpful error message), or they have an awfully short page expiration time - from page load to the time I hit submit was under 30 seconds.

This comment got downmodded, but I'm not sure why. Does anyone have some insight into what I may have done/said wrong, so I can avoid doing it in the future?

This is a tumblr issue. I think it has something to do with Chrome. Did you use that?

Yes.

Here's my experience trying to bring this to one of the offenders' attention. He actually attempted to justify it.

http://eric.newcomer.org/jamplay-defends-storing-passwords-i...

Rackspace does this with their Cloud Servers :'(

Surely your joking, Mr. Alterego?

Well, they do sent root passwords over email.

if it was the welcome message, that's not a problem. It's up to you to change it. If they're emailing you your password to root after you've changed it, you might have an issue.

Exactly, I'm using SoftLayer cloud servers and they do the same thing... displaying a cleartext version of the initial root password for the machine. I don't see a way around it. I do have to get that information somehow.

EC2 servers dont have any passwords at all by default. Not blank ones, but there are actually none set at all. They come primed with a keypair which you get when you create your account.

Considering we live in space year 3000 now, its a wonder that we still have passwords at all. Why can't we have 2 factor keypair authentication for everything? OpenID is thinking too small.

Inject the users public key in as root and have pubkey only logins for root.

Now you are both secure and convenient.

So does Dreamhost with their shared hosting :(

I forgot the password to my credit union account. I clicked on the 'get password' link and they e-mailed my original password back to me, in plain text. Lame! I still need to move my funds though, doh!

Drupal also sends plaintext passwords out of the box (at least in Drupal 6), although it does hash the password in the database. One of the first things I do is change the wording of the welcome email.

Can someone explain to me why it is so important to hash passwords before storing them?

The passwords can be stolen and then you royally screwed your users who trusted you.

http://blog.moertel.com/articles/2006/12/15/never-store-pass...

http://stackoverflow.com/questions/287517/encrypting-hashing...

http://www.usenix.org/publications/login/2001-11/pdfs/singer...

I'd considered doing something like this the other day, good work for getting the bad news out there! Hopefully this can help lift the expected minimum of security on the web a little.

I'm shocked that Mozilla not only (seemingly) stores their mailing list passwords unhashed, but that they also email them out to each member every month in a reminder email.

Reminds me of this: http://news.ycombinator.com/item?id=2329366.

Unbelievable.

Markus Frind did this way back when and suffered for it when Plenty of Fish got hacked a few months ago, big risk.

Toms.com sends you your password after you signup, which is retarded since YOU JUST entered it into their system.

Props! Took me a moment to figure out why all the initial sites are in Hebrew ;)

A straight list without the irrelevant screenshots would be much more scalable.

Pretty scary feeling: search your gmail inbox for your default password.

Thank you for this. Now I have a list of places where I need to delete my account or change password.

Default password? There's your first problem. Use a utility like LastPass or 1Password. You shouldn't have a default password.

So, the only companies that do this are in Israel?

Add Dreamhost to this list.

Nitpick, they're not necessarily storing it in plaintext, they may just not be salting it. There is a difference.

Whether it is stored plaintext, or in an encrypted format:

1) They are sending it in plaintext

2) Encrypted passwords are a factor less secure than hashed (and salted) passwords

I am not sure how salting the password comes into it in the context you describe - can you explain?

From the site:

A website storing a password in plain text means that your password is there, waiting for someone to come and take it. It doesn’t even matter if you’ve created the strongest possible password. It’s just there.

...We’re tired of websites abusing our trust and storing our passwords in plain text, exposing us to danger. Here we put these websites to shame.

That is possibly a libellous allegation. It is not necessarily true.

The password is not necessarily stored in plaintext, it may still be encrypted.

The website owner does not understand encryption.

Understand my point now?

Not really; this post doesn't mention salting, which is where my confusion about your point came from.

There's also a difference between (non-reversible) hashing, with or without salt, and (reversible) encryption.

Additionally, encrypted passwords are only better than plaintext passwords if an adversary that breaks into your database does/can not also get the encryption key. That's unlikely to be the case.

Very true, my mention of salts seems to have muddied things.

As for getting the key, I'm no Linux expert but in windows afaik SQL injection generally doesn't allow you to get to the machine key which is used for this type of encryption.

So it really depends on the attack vector on the likeliness of them having the key.

I also totally agree in this day and age everyone should be hashing, it's just too easy to leave an accidental hole and you should mitigate the consequences of a breach.

But I still stand by the idea that they're not necessarily storing the password in plaintext, which was all I was trying to say with my nitpick!

Just look at http://news.ycombinator.com/item?id=2343330. Tumblr has piles of money, and a misplaced 'i' still gave away all their passwords (fortunately, just their passwords for external APIs...) Keeping the source code secret is usually not security goal #1, and not needing to is a good idea.

Also, un-salted encrypted passwords are still bad. Just compare the top 10 most popular encryptions with a table of the top 10 most popular passwords.

I'll drop this, but please do hash your passwords with something sensible like bcrypt. ;-)

Still, you can have your passwords very securely stored in bcrypt AND mail the plain text out when the account is created. If your email isn't secure that should really be dealt with, and separately.

No. E-mail is an unencrypted, unauthenticated protocol; how could sending out plain text passwords over a plain text protocol ever be a good idea?

I've refined the allegation to not sound libelous. Thank you for bringing it up.

@omervk

Is there an effective difference between storing it in plaintext and with storing it with a trivially reversible algorithm?

A slight one if any.

If you store passwords plaintext in the database, a simple SQL injection can dump them out.

If you store passwords encrypted in the database, you need to get the code of the server software in order to extract the keys.

So at the end of the day, it depends on the probability of a complete server compromise vs. the probability of a successful SQL injection.

I think you mean hashing rather than salting.

I think you're right (hence my confusion about the salting comment)

Salting is a process used in hashing. Hashing converts an input text (ie. a password) into an unintelligible mash of symbols, that cannot be reversed. If they were sending passwords in plaintext, they are not hashing it, as they are able to reverse it. I believe what you meant to say is "They may just be encrypting it, not hashing it".

The other day I thought there should be a "Wall of Shame" site for photos of the d-bags who abuse handicapped spots.

Just make a tumblr page for it :) Seriously, not including setting up a domain it takes about 15 minutes...

>not including setting up a domain it takes about 15 minutes...

Which, coincidentally, is about the same amount of time as you can expect your tumblr page to be up every month ;)

http://youparklikeanasshole.com/

Reply on news.ycombinator.com