views:

85

answers:

3

Most of the online sites on registration do send a link to activate the site and on any further correspondence with the end user they provide information about the site and also provide the login credentials with password in clear text (as given below)

Username - [email protected] Password - mysecretpassword

What would you do in such a case? From a usability perspective does it make sense to send the password information in clear text or should you just avoid sending this information. I was under the impression that most of the passwords are MD5 hashed before storing in the database and hence the service provider will not have any access to clear text passwords, is this a security violation?

+4  A: 

Yes, this is definitely a security violation. Only a salted and hashed version of passwords should be stored.

It is common to have reset password functionality that sends either a temporary auto-generated password (which should be good for only one login) or a one-time reset link. This does mean your other accounts are only as secure as your email.

However, you should steer clear of any site that will email your actual password in clear text.

Matthew Flaschen
will definitely avoid clear text communication of passwords.
Samuel
+2  A: 

It's a commonly-held fallacy that if you receive a password in plain-text it means they aren't stored securely - passwords like any other data can be stored using reversible encryption.

Having said that, it's pretty likely anyone that sends you a plaintext password does not have a clue about security and is probably storing them carelessly (unless the passwords are used as weak real-world identifiers, say as part of an in-store membership scheme, in which case they shouldn't be called passwords lest your customers get confused).

If you send a password plain-text you may as well assume that if it is linked to something important then it has been compromised. There are just too many weak points. You can also do a lot more unintentional damage.

  1. The email could be intercepted giving someone else the password.
  2. Someone could see them open the email on their screen (been at mates houses and had this happen to both of us so many times, and every time is a massive headache to go change all your passwords).
  3. The email might be forwarded to other addresses which are not secure.
  4. The email might bounce/encounter a server error and then you (perhaps your untrusted staff or outsourced helpdesk too?), and the email server's system admin will probably get copies of the original email.
  5. Someone who obtains access to the user's emails through a cookie hijack or even just a briefly unattended open email account will now be able to see their password. Worse, their password is probably used elsewhere (or at least has a common stem, e.g. "password1", "password1$$" "passwordSuperSecure123") so you've now compromised more than just your own service. Worse still, it might be the password to the email account that's been hijacked and now they can steal this person's email account and thus identity for a much longer time than the expiry date on the cookie/session. (This has all happened to people I know).
Graphain
It's not a fallacy at all. Passwords should *not* be stored using reversible encryption. It is all too common for entire systems (including both database and key) to be compromised. If you use reversible encryption, that means the attacker gets access to the password (which users usually use repeatedly, and in more than one place). If you use salting and hashing, they don't.
Matthew Flaschen
The fallacy is that passwords sent as plaintext indicates passwords stored as plaintext. If they have access to your key and database then you probably have bigger issues at hand. If they have access to your salt and your database then they can still generate a rainbow table that shouldn't take that long to break most of the hashed passwords.
Graphain
@Matthew Flaschen: If you use the same password repeatedly, you are asking for it.
Longpoke
I just want to point out I wasn't encouraging reversible passwords over hashed passwords either, it's just a compromise that sometimes has to be made under business pressure. I was simply addressing the OP's question "does this mean they're stored as plaintext" before addressing "should I send passwords as plaintext".
Graphain
@Graphain, nobody said "passwords sent as plaintext indicates passwords stored as plaintext." The OP said, and I agree, it indicates a security violation. Obviously you don't want people cracking your systems. But in that scenario, there's no reason to also let them get decrypted passwords. @Longpoke, even if users didn't use passwords in multiple places (and it's a fact of life they do), the attacker could still use the decrypted passwords at the same site he cracked, once it was up and running again.
Matthew Flaschen
@Matthew Flaschen - Encrypted data does not indicate a security violation. By your logic all encryption is pointless.
Graphain
No, encryption in general is not pointless. It is essential to provide confidentiality. But here we don't want confidentiality. We want *no one* to be able to recover the passwords, even if the system is compromised.
Matthew Flaschen
+1  A: 

There are always trade-offs, and developers have to consider useability, the savvy-ness of the intended users, the secrecy and importance of the data, the frequency that the website will be used, and so on. Of course users don't want their privacy violated, but on the other hand "ordinary" web users may be turned off by having to remember a password, or even having to invent one in the first place (some websites simplify user registration by generating a random password and emailing it). Website developers have a responsibility to keep the users' best interests in mind when designing security.

My advice is that passwords should only be emailed in the clear when they are randomly generated. This avoids the following awkward scenario: a user registers with a password which they are already using for various other web services, and then receives a registration confirmation email containing the password they just entered. A lot of users may not be security-conscious enough to use unique passwords for every website, but they are security-conscious enough to recognize that "sensitive" passwords should not be sent around by email.

Todd Owen