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

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

plaintextoffenders.com

Post reply on HN
Print view View original

101–110 of 147 posts

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

#101

Post by potatolicious »

tedunangst wrote: post #66
lkozma wrote: post #46

Earlier quoted context omitted.

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

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.

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.

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

#102

Post by MartinCron »

psaintla wrote: post #58
Kudos wrote: post #3

Earlier quoted context omitted.

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?

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.

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

#103

Post by MartinCron »

goosemo wrote: post #96
emp_ wrote: post #91

Earlier quoted context omitted.

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.

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

#104

Post by qntm »

scott_s wrote: post #71
tedunangst wrote: post #66

Earlier quoted context omitted.

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…

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.

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

#105

Post by tnorthcutt »

tnorthcutt wrote: post #53

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?

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

#106

Post by tedunangst »

btilly wrote: post #98
tedunangst wrote: post #90

Earlier quoted context omitted.

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 questi…

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.

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

#107

Post by gabbo »

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.

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

#108

Post by scott_s »

qntm wrote: post #104
scott_s wrote: post #71

Earlier quoted context omitted.

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…

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…

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.

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

#109

Post by btilly »

tedunangst wrote: post #106
btilly wrote: post #98

Earlier quoted context omitted.

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 questi…

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.

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

#110

Post by JangoSteve »

nyellin wrote: post #50
mercuti0 wrote: post #49

Earlier quoted context omitted.

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?
Post reply on HN