Magento – Passwords in sign up email. Bad practice? PCI compliant

ee-1.12emailSecurity

We use Magento Enterprise (1.12) and I have had several customers email me already complaining that they received their password via email when they signed up for an account. I know this is considered bad practice, but comes with Magento out of the box.

I am going to change it and remove it from the email template, which is easy enough, but I was just curious why Magento does this if it's long been considered bad practice? I know there is little sensitive information stored in a users account, and we do credit card validation, but "Magento Enterprise does it that way, so it must be ok." seems like a poor answer for me to give..

Also, do many Magento developers make this a frequent 'to-do list' fix when building a new Magento site, like removing phone validation?

Best Answer

Is it good practice (from a security standpoint) to send a customer the password they provided during registration via email?

No, it is most definitely not!

Do we frequently change this for clients?

No. Unfortunately we do not. We probably should, but it's typically one of the lowest items on the worry list. In the past 5 years, I only recall a single client asking about this. It was after receiving a fiery email from a customer who was not too happy over their password having been emailed to them, and who then was questioning the security of having given the site their CC info to place an order.

I would highly recommend making this change for any new store. It's worth the little amount of time, and the supposed "benefits" which I mention below are not worth the risks of insecurely transmitting the password.

Are there benefits to including the password in the new account email?

Yes, there are (although IMO they are not truly beneficial). This probably depends on the demographic of the site some, and I unfortunately do not have any statistics here, but people lose passwords. Folks like me use unique passwords for everything and store them in keychains, but most folks do not, rather they write them down on sticky notes, tape them to computers or email them to themselves. A customer that can't place an order because they can not log in is either a lost order/customer or an unhappy customer which a CSR must help use the site.

I'm absolutely not saying that it makes it worth the security risk though! It's just a "reason" per-se why they are in emails in the first place.

A big thing that comes into play is the simple fact that people still use the same password in many different places. So even if it doesn't matter if a single customer account on your particular website is compromised, the password can be used to compromise accounts which might be of a more sensitive nature. Not that an eCommerce site doesn't contain PII, but it typically does not contain the same level of sensitive information that a bank would, for example.


The risk for the individual eCommerce store becomes much grander (independent of password cross-polination) when credit card information is being stored to enable easier re-ordering and purchasing. It opens you up to the risk of having unathorized users breaking into the account, purchasing on a customers credit card and having the order shipped elsewhere.

Which version of Magento is being used, in this case, does not matter much. All versions I have worked with (including EE 1.13) send the customer's account password in cleartext via email upon initial account creation. Newer versions do not include the password in the password reset emails and opt for an expiring link instead. But if you reset the password from the admin, same situation, it's sent in cleartext.


Preventing the password from being sent out in the account registration emails is pretty simple and can readily be done from the Magento admin by following a few simple steps:

  1. Go to System > Transactional Emails

  2. Click the Add New Template button

  3. From the Template drop down, choose "New account"

  4. Load the template into the form by clicking the Load Template button

  5. Find the following line of code in the template and remove it:

    <strong>Password</strong>: {{htmlescape var=$customer.password}}<p>
    
  6. Edit the copy in the template to better reflect the nature of the email. Parts of the default template (Ex: "following values") won't make sense without the password present...

Related Topic