Live data from Hacker News

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

plaintextoffenders.com

131–140 of 147 posts

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

#131
post #96

Earlier quoted context omitted.

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.

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

#132
post #73

Earlier quoted context omitted.

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.

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

#133
post #39

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.

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 :)

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

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

#134

Earlier quoted context omitted.

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

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.

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

#135
post #18

Earlier quoted context omitted.

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

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.

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

#137
post #18

Earlier quoted context omitted.

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.

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

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

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

Post reply on HN