Live data from Hacker News

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

plaintextoffenders.com

91–100 of 147 posts

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

#92
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'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.

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

#93

Earlier quoted context omitted.

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…

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

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.

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

#95
post #92

Earlier quoted context omitted.

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

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.

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

#96
post #91
post #78

Earlier quoted context omitted.

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.

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

#97

Earlier quoted context omitted.

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?

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

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.

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

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

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.

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

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

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