Plain Text Password in Welcome Email
November 23, 2008 11:50 PM
Online Security Filter: Welcome email contained plain text password. Specific examples of why this is bad needed.
I know this is a bad security practice. But why? My searching is coming up blank, so I'm turning to AskMeFi-ers.
I want to reply with documentation to the below conversation. No opinions, please; given that mine didn't really amount to much for them. :-)
(The site in question didn't ask for my cc # to sign up, but the same credentials would be used to make a purchase. At that time, a cc # is attached to the account.)
==============================
Comment: I just signed up for an account. As this is a shopping site, I used a password that I wish to remain secure. However, I just received an email thanking me for signing up. It contained my password in clear text. This type of security breach gives me concern for shopping with *****.
==============================
Thanks for the feedback Julie. I don't agree with you that this is a major security breach, but I will consider it in the next edition of our cart.
AJ
==============================
I know this is a bad security practice. But why? My searching is coming up blank, so I'm turning to AskMeFi-ers.
I want to reply with documentation to the below conversation. No opinions, please; given that mine didn't really amount to much for them. :-)
(The site in question didn't ask for my cc # to sign up, but the same credentials would be used to make a purchase. At that time, a cc # is attached to the account.)
==============================
Comment: I just signed up for an account. As this is a shopping site, I used a password that I wish to remain secure. However, I just received an email thanking me for signing up. It contained my password in clear text. This type of security breach gives me concern for shopping with *****.
==============================
Thanks for the feedback Julie. I don't agree with you that this is a major security breach, but I will consider it in the next edition of our cart.
AJ
==============================
The reality of the situation is that if someone has the time, experience, and expertise necessary to steal your password from a plain-text email, they can likely break through any additional security you had if they so chose, until you start talking about enterprise-level VPNs and such.
No shopping site is going to invest in (or expect customers to work with) secure tunneling and the like, nor should they. I doubt anyone that can hack into your plain text email wants a password to shopping site *****.
posted by Nixie Pixel at 1:09 AM on November 24, 2008
No shopping site is going to invest in (or expect customers to work with) secure tunneling and the like, nor should they. I doubt anyone that can hack into your plain text email wants a password to shopping site *****.
posted by Nixie Pixel at 1:09 AM on November 24, 2008
It would be bad security practice for a bank, who should deliver passwords/keys in an offline and in a way to establish your identity, but for a shopping site I go with meh...
Most internet security relies on your email account being a secure and private method of communication. While I agree that it is unnecessary for them to send the password in plain text in the welcome message, IMHO the site is no less secure because of it.
If you are worried that your email may be readable by third parties, then any malicious party could access your login by clicking the 'forgot password' link, and for most sites, your existing or a new password would also be sent in plain text (It would be more secure if the site has a password reset system with an additional security question, and the answer to which was not sent in the welcome email, but this is a level of complexity very few sites go to... And the recent Sarah Palin Yahoo mail hack shows how easy to compromise this is!).
As for the 'plain text', most people don't know how to read encrypted mail and even if they did send encrypted mail, you would still have to have a way of resetting your public/private key pair if your half was lost...
Personally I believe that the real security risk for a shopping site is the storing of a CC# - this allows malicious users to make purchases if your account is compromised. I would prefer it if shopping sites do not do this (and I am looking at you amazon, paypal).
posted by nielm at 1:29 AM on November 24, 2008
Most internet security relies on your email account being a secure and private method of communication. While I agree that it is unnecessary for them to send the password in plain text in the welcome message, IMHO the site is no less secure because of it.
If you are worried that your email may be readable by third parties, then any malicious party could access your login by clicking the 'forgot password' link, and for most sites, your existing or a new password would also be sent in plain text (It would be more secure if the site has a password reset system with an additional security question, and the answer to which was not sent in the welcome email, but this is a level of complexity very few sites go to... And the recent Sarah Palin Yahoo mail hack shows how easy to compromise this is!).
As for the 'plain text', most people don't know how to read encrypted mail and even if they did send encrypted mail, you would still have to have a way of resetting your public/private key pair if your half was lost...
Personally I believe that the real security risk for a shopping site is the storing of a CC# - this allows malicious users to make purchases if your account is compromised. I would prefer it if shopping sites do not do this (and I am looking at you amazon, paypal).
posted by nielm at 1:29 AM on November 24, 2008
Most shopping sites use SSL, which is a secure tunnel, if you will. Sending the password in cleartext in email is as insecure as sending it in cleartext HTTP — perhaps moreso, since that message will likely go through a couple intermediate mailservers before it reaches you.
Of course, people do argue that using SSL for the store webpages is pointless also.
posted by hattifattener at 1:31 AM on November 24, 2008
Of course, people do argue that using SSL for the store webpages is pointless also.
posted by hattifattener at 1:31 AM on November 24, 2008
The quick answer you may want is that e-mail is inherently non-secure (neither you nor the other end control the servers and networks it may pass through, and there's no personal validation at the receiving end, unless you're using PGP or something... which nobody is.)
The right way IS to send a password in e-mail, sometimes, but only as a temporary "now go log in and change this" message (forcing auditable tracks), and ideally one that also uses other secret info to reduce the odds that you're a password thief.
The practical reality, though, is that many website/store admins prefer their users to get an e-mail copy of their login and password, because that drastically reduces their customer support inquiries, 90-some percent of which are of the "I registered but forget my (new) password" example. An e-mail that says "print this and store it somewhere safe" shifts the onus back to the user, which is a labor and hassle saver.
Anecdotally, I've worked on maybe fifty or sixty web stores that all used the same software for registration/signup, and I know (for example) that it has a one-line flag setting for what to include in the signup thank-you mail. There's a boolean for "User's full name" and another for "User ID" and another for "Password", and other exotic ones like "Time and Date of signup" that can be echoed. I can remember at least four times, top of my head, that a store was set up with the "send copy of password" turned off (in the "safe" way) only to have the customer service admins ask for it to be added back in a few weeks/months later because they were sick of the inquiries, and/or tired of people making a new account every visit and gumming up their databases with one-time or never-used users.
Much shorter answer: there's no perfect system. :)
posted by rokusan at 1:42 AM on November 24, 2008
The right way IS to send a password in e-mail, sometimes, but only as a temporary "now go log in and change this" message (forcing auditable tracks), and ideally one that also uses other secret info to reduce the odds that you're a password thief.
The practical reality, though, is that many website/store admins prefer their users to get an e-mail copy of their login and password, because that drastically reduces their customer support inquiries, 90-some percent of which are of the "I registered but forget my (new) password" example. An e-mail that says "print this and store it somewhere safe" shifts the onus back to the user, which is a labor and hassle saver.
Anecdotally, I've worked on maybe fifty or sixty web stores that all used the same software for registration/signup, and I know (for example) that it has a one-line flag setting for what to include in the signup thank-you mail. There's a boolean for "User's full name" and another for "User ID" and another for "Password", and other exotic ones like "Time and Date of signup" that can be echoed. I can remember at least four times, top of my head, that a store was set up with the "send copy of password" turned off (in the "safe" way) only to have the customer service admins ask for it to be added back in a few weeks/months later because they were sick of the inquiries, and/or tired of people making a new account every visit and gumming up their databases with one-time or never-used users.
Much shorter answer: there's no perfect system. :)
posted by rokusan at 1:42 AM on November 24, 2008
Um, I'm surprised this hasn't been mentioned, but I consider it a bad practice to ever email my password in plaintext form, not because I'm worried about the security of the transmission or of my email account, but because it means my password is stored as plaintext in their database.
If that's the case, it means that their developers, admins or anyone next to a computer with a saved phpMyAdmin account at their location can hop on and view all user records, including my email address and password. And guess what? I use the same password in a lot of places. I have a throwaway that I use such that if it got hacked, or stored as plaintext, I wouldn't particularly care. Banks and email are under a more secure password that I only use with trusted parties.
But the last thing I need as a developer is having the liability of storing your plaintext password and email address in the same table—if the database were ever hacked, (or, as mentioned above and considerably more likely, someone within the organization wanted to look) it's not just my ghettoshoppingcart site account that's vulnerable. No, it's every single account I (typical user) own, and if I happen to use the same password for my email, it's game over.
Transmitting passwords in plain text is obnoxious but storing them that way is a sin. Use a hash like everyone else does. If a user forgets their password, send a reset request email to the address on file. If you want to require an additional authorization step, ask a security question before you fire that off, but typically, just relying on the idea that they and only they have access to their email is enough. The reset request will be tracked in a separate table, with its own hash and an expiry time, so a user has to click the link and then change their own password. Again, this is promptly hashed and never stored as plaintext again; in fact, I'm not wholly against them transmitting a password in an email to users if the users request it before hashing it. I dislike the practice for the same reason that the password field itself is obscured—I don't want to have a password show up in an email when I have a coworker around. (Say, in a system tray alert that lets me know I have new mail, with a snippet included!)
posted by disillusioned at 2:10 AM on November 24, 2008
If that's the case, it means that their developers, admins or anyone next to a computer with a saved phpMyAdmin account at their location can hop on and view all user records, including my email address and password. And guess what? I use the same password in a lot of places. I have a throwaway that I use such that if it got hacked, or stored as plaintext, I wouldn't particularly care. Banks and email are under a more secure password that I only use with trusted parties.
But the last thing I need as a developer is having the liability of storing your plaintext password and email address in the same table—if the database were ever hacked, (or, as mentioned above and considerably more likely, someone within the organization wanted to look) it's not just my ghettoshoppingcart site account that's vulnerable. No, it's every single account I (typical user) own, and if I happen to use the same password for my email, it's game over.
Transmitting passwords in plain text is obnoxious but storing them that way is a sin. Use a hash like everyone else does. If a user forgets their password, send a reset request email to the address on file. If you want to require an additional authorization step, ask a security question before you fire that off, but typically, just relying on the idea that they and only they have access to their email is enough. The reset request will be tracked in a separate table, with its own hash and an expiry time, so a user has to click the link and then change their own password. Again, this is promptly hashed and never stored as plaintext again; in fact, I'm not wholly against them transmitting a password in an email to users if the users request it before hashing it. I dislike the practice for the same reason that the password field itself is obscured—I don't want to have a password show up in an email when I have a coworker around. (Say, in a system tray alert that lets me know I have new mail, with a snippet included!)
posted by disillusioned at 2:10 AM on November 24, 2008
Any communication that isn't secure - i.e. web to an https: site, email to a non-SSH connection - is open to being tapped. For most people this isn't an issue as there is just so much traffic, your comms are lost in the noise. But your connection will be going over routers and nodes over which you have no control or knowledge of.
Someone could be intercepting, they probably aren't, but they could be.
Also, the issue is that if the password can be sent to you in plaintext then that means it is being stored in plaintext - probably in a database. This means that if that database suffers an attack then your password (and anything else stored unencrypted) is going to be vulnerable. A simple query from an errant admin will be enough to leave you wide open.
Fundamentally your gut feeling is correct - it's not good practice - so if a site is delivering you your password in plaintext what it means is that that site just doesn't "get it". If they'll do that, what other security shortcuts will they be using?
posted by unsliced at 2:13 AM on November 24, 2008
Someone could be intercepting, they probably aren't, but they could be.
Also, the issue is that if the password can be sent to you in plaintext then that means it is being stored in plaintext - probably in a database. This means that if that database suffers an attack then your password (and anything else stored unencrypted) is going to be vulnerable. A simple query from an errant admin will be enough to leave you wide open.
Fundamentally your gut feeling is correct - it's not good practice - so if a site is delivering you your password in plaintext what it means is that that site just doesn't "get it". If they'll do that, what other security shortcuts will they be using?
posted by unsliced at 2:13 AM on November 24, 2008
Basically, sending the email to you in plain text is roughly as unsecure as not having any encryption as you log in. For example, when you check email from a wireless network, the operator (and possibly nearby snoopers) can sniff your traffic and discover your password (again, assuming that you aren't checking email over an encrypted protocol .... which isn't 100% standard).
As disillusioned said, the fact that they have your password in plaintext is a bad sign as well. However, if they email it out at account creation, it's possible that they never store it in the database; just email it out.
In my book, anything which causes your password to appear on your screen is a security hazard due to shoulder surfing. Anything which causes your password to be transmitted in plaintext over the net is a security hazard due to network snooping.
The right way to handle forgotten passwords is to send you a link/code that you have to go to in order to set your password. A one-time-use password that expires is OK (and what everyone uses), though I would feel more comfortable if resetting the password also required some information not contained in the email (like a code shown on the 'reset password' page transmitted over https)
posted by bsdfish at 3:07 AM on November 24, 2008
As disillusioned said, the fact that they have your password in plaintext is a bad sign as well. However, if they email it out at account creation, it's possible that they never store it in the database; just email it out.
In my book, anything which causes your password to appear on your screen is a security hazard due to shoulder surfing. Anything which causes your password to be transmitted in plaintext over the net is a security hazard due to network snooping.
The right way to handle forgotten passwords is to send you a link/code that you have to go to in order to set your password. A one-time-use password that expires is OK (and what everyone uses), though I would feel more comfortable if resetting the password also required some information not contained in the email (like a code shown on the 'reset password' page transmitted over https)
posted by bsdfish at 3:07 AM on November 24, 2008
On preview...um yeah. What bsdfish said: emailing plaintext password in a welcome message doesn't mean they store it that way and also lots of systems do password reset with the one-time-use method mentioned.
posted by juv3nal at 3:39 AM on November 24, 2008
posted by juv3nal at 3:39 AM on November 24, 2008
Disillusioned and unsliced are incorrect, at least in the cases I'm familiar with, while BSDfish nails it: the password as entered may be sent out (optionally) to the user for their records, but then encrypted and stored, either as long-term or single-use (temporary.)
Assuming it's stored in their database as plaintext because it was mailed to you once is not a safe bet. In cases where I've worked on customer service systems (including policy issues), "don't store passwords; change them destructively if you need to." is a basic recommendation.
posted by rokusan at 3:56 AM on November 24, 2008
Assuming it's stored in their database as plaintext because it was mailed to you once is not a safe bet. In cases where I've worked on customer service systems (including policy issues), "don't store passwords; change them destructively if you need to." is a basic recommendation.
posted by rokusan at 3:56 AM on November 24, 2008
All merchants who accept credit cards have agreed to follow the PCI Data Security Standard (PCI DSS), and that specifically requires them to "encrypt" all "transmission of cardholder data."
Report the merchant to VISA (or whoever your credit card company is). That might get results.
posted by profwhat at 5:21 AM on November 24, 2008
Report the merchant to VISA (or whoever your credit card company is). That might get results.
posted by profwhat at 5:21 AM on November 24, 2008
It's bad because if someone can guess/steal one password (your email account) they have access to many of your passwords. In other words, there are now two ways to gain access to your accounts, rather than just one.
posted by paanta at 5:47 AM on November 24, 2008
posted by paanta at 5:47 AM on November 24, 2008
For example, when you check email from a wireless network, the operator (and possibly nearby snoopers) can sniff your traffic and discover your password (again, assuming that you aren't checking email over an encrypted protocol .... which isn't 100% standard).
Second this. For example, let's say you're using Gmail with the default settings, and you're running on a non-secured wireless network (either at home or at a free wifi hotspot). When you log into a shopping site, all of the important stuff is sent over HTTPS, so it's at least encrypted. When you log into Gmail, they have a secure login but all of the actual email content is sent in clear text. So, if a person is wirelessly snooping on your network, they can't figure out your shopping login directly, and they can't figure out your Gmail login directly, but they can see the password text in your email message directly.
posted by burnmp3s at 7:15 AM on November 24, 2008
Second this. For example, let's say you're using Gmail with the default settings, and you're running on a non-secured wireless network (either at home or at a free wifi hotspot). When you log into a shopping site, all of the important stuff is sent over HTTPS, so it's at least encrypted. When you log into Gmail, they have a secure login but all of the actual email content is sent in clear text. So, if a person is wirelessly snooping on your network, they can't figure out your shopping login directly, and they can't figure out your Gmail login directly, but they can see the password text in your email message directly.
posted by burnmp3s at 7:15 AM on November 24, 2008
Ive always dislike this because it screams of developer laziness. Its not that difficult to generate a link that will reset your password for you. Someone above already mentioned that if they can give you your password then your password exists as plain text in their database. That's wrong on many levels. It should be one-way encrypted. Any employee with access to that database can try your password on different sites. If the database gets compromised somehow then someone has all these password with a name, email address, etc.
Its really a sign that the organization doesnt take security seriously.
posted by damn dirty ape at 7:20 AM on November 24, 2008
Its really a sign that the organization doesnt take security seriously.
posted by damn dirty ape at 7:20 AM on November 24, 2008
damn dirty ape: it screams of developer laziness
Amen to that!
What's important is that it's not just a somewhat-academic argument about relative levels of security, it's that it's a problem that's been solved a billion times over, which ought to make it moot.
posted by mkultra at 7:55 AM on November 24, 2008
Amen to that!
What's important is that it's not just a somewhat-academic argument about relative levels of security, it's that it's a problem that's been solved a billion times over, which ought to make it moot.
posted by mkultra at 7:55 AM on November 24, 2008
Again: mailing you your (new or temporary) password does not demonstrate that it's stored in a database anywhere in plaintext. "Retrieving" an old one might, but even then you don't know the process.
Also, mailing it doesn't violate PCI standards.
Note I'm still against it and recommend not doing it. But enough FUD, already.
posted by rokusan at 11:22 AM on November 24, 2008
Also, mailing it doesn't violate PCI standards.
Note I'm still against it and recommend not doing it. But enough FUD, already.
posted by rokusan at 11:22 AM on November 24, 2008
I agree strongly that this is just bad practice. A blog post that comes to mind is about Pet Peeves. However much I agree with the statements here, they are still opinions.
What I'm really looking for is Citation to Internet Security Briefing which talks about why this is a bad practice.
Perhaps it just doesn't exist?
posted by TauLepton at 11:40 AM on November 24, 2008
What I'm really looking for is Citation to Internet Security Briefing which talks about why this is a bad practice.
Perhaps it just doesn't exist?
posted by TauLepton at 11:40 AM on November 24, 2008
When you browse a website in clear text, someone would have to tap into the network path between you and the server in order to listen in on your data. And they'd have to be specifically looking for your traffic (unless they're logging everything).
Email works differently. When you send a message, it gets spooled at your ISP's email server on disk, then gets sent to another server and written to disk, etc. It eventually finds its way to the recipient's inbox, where it gets written to disk once again. So, with one email, sensitive information has been written to disk multiple times, at places that may have different logging and data retention standards. This is not what you want.
posted by lalas at 11:43 AM on November 24, 2008
Email works differently. When you send a message, it gets spooled at your ISP's email server on disk, then gets sent to another server and written to disk, etc. It eventually finds its way to the recipient's inbox, where it gets written to disk once again. So, with one email, sensitive information has been written to disk multiple times, at places that may have different logging and data retention standards. This is not what you want.
posted by lalas at 11:43 AM on November 24, 2008
Naturally, I didn't mean to imply that just because they emailed the password at account creation that it was stored plaintext—as mentioned further in my post, they could easily just send it out and THEN hash. But if a reset request sends you back your plaintext password, then you know they're storing it.
posted by disillusioned at 4:28 PM on November 24, 2008
posted by disillusioned at 4:28 PM on November 24, 2008
This thread is closed to new comments.
It's only a danger if someone somehow gets access to your email account. However if they do that you're humped nine ways from Tuesday anyway since all they have to do to your password to SomeShoppingSite.com is click the "I forgot my password" button and enter your email address have it mailed to you/them.
posted by Ookseer at 1:00 AM on November 24, 2008