Live data from Hacker News

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

plaintextoffenders.com

81–90 of 147 posts

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

#81
post #71

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…

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.

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

#82
post #77

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.

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.

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

#83
post #81
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…

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.

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

#85
post #81
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…

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.

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.

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

#86
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?

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

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

#87
post #86

Earlier quoted context omitted.

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

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

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

#88
post #82
post #77

Earlier quoted context omitted.

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.

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

#89
post #71

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'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)?

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

#90
post #77

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.

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.

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