Magento2: Magento reveals sensitive information to public

Created on 9 Nov 2018  Â·  20Comments  Â·  Source: magento/magento2

Preconditions (*)

  1. All versions.

Steps to reproduce (*)

  1. Install Magento
  2. Create account using a email
  3. As a non-logged in user, add products to cart and go to checkout
  4. Enter email used in step 2

Expected result (*)

  1. Magento does not signal in any way that an account with the current email exists.

Actual result (*)

  1. Magento reveals that email used in step 2 belongs to a customer of this particular shop.

magento-email-issue

In many countries, it is illegal to reveal such information.

Format is valid

Most helpful comment

@DanielRuf the information that there exists an account for a specific email, is confidential.

All 20 comments

Hi @terolahtinen. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

  • [ ] Summary of the issue
  • [ ] Information on your environment
  • [ ] Steps to reproduce
  • [ ] Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento-engcom-team give me $VERSION instance

where $VERSION is version tags (starting from 2.2.0+) or develop branches (for example: 2.3-develop).
For more details, please, review the Magento Contributor Assistant documentation.

@terolahtinen do you confirm that you was able to reproduce the issue on vanilla Magento instance following steps to reproduce?

  • [ ] yes
  • [ ] no

Should be probably Wrong password or Email Address.

Also password forgot should say: You will get an email if you have an account in our shop.

I guess this is what you mean?

sensitive information to public

Not exactly. It is just some sort of account enumeration.
because the user in front of the screen has to type the email address of the target.

In many countries, it is illegal to reveal such information.

Can you point us to the legal rules / papers who explicitly state this?

In many countries, it is illegal to reveal such information.

Can you point us to the legal rules / papers which explicitly state this?

Both Google and Microsoft must be breaking the law too, as both google login and microsoft login can both be used to determine if a users email address is registered with them.

Both Google and Microsoft must be breaking the law too, as both google login and microsoft login can both be used to determine if a users email address is registered with them.

And also Twitter, Facebook and so on.

About the legal rules:
All European Union nations:
GDPR:
https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1528874672298&uri=CELEX%3A32016R0679

Article 5, section 1 f
states that personal data must be kept confidential.
Article 4, section 1
defines personal information: "‘personal data’ means any information relating to an identified or identifiable natural person"

Hence, "person using email [email protected] is our customer" is 'personal data' and must be kept confidential.

To comment on @gwharton's comment: Login typically does not reveal that an account exists. The error messages are similar in cases where email used in login is known by the system and where it is now.

With Magento the problem is that at checkout page Magento specifically signals if an account exists for the entered email. The password-field and message "You already have an account with us" comes after customer has entered a known email.

states that personal data must be kept confidential.

It is confidential. It does not leak email addresses.

defines personal information: "‘personal data’ means any information relating to an identified or identifiable natural person"

There is no PII leaked as far as I can see.

It is confidential. It does not leak email addresses.

If you already know it, it is not confidential.

Login typically does not reveal that an account exists

Not in general. Best practice in infosec is like I wrote. It is mostly a best practice.

Credential and email stuffing is well known and also enumeration.

I would just propose to change the texts and check if the login checks have no time related attacks which reveal such info (takes longer for existing accounts).

But no one really breaks the law here. Otherwise we would have much more issues in other projects.

@DanielRuf the information that there exists an account for a specific email, is confidential.

It is not just a text issue, the functionality is different.

screenshot from 2018-11-09 12 17 57
screenshot from 2018-11-09 12 17 47

the information that there exists an account for a specific email, is confidential.

Not really. Do you try every single Magento 2 shop?
Not very critical. But also not optimal to show this text and use some other as I already proposed.

Well, then we also have to change a bit more here to show password or email wrong and show both fields b default.

But this does not break the law to be exact (talked with our internal data protector and others, and I have a bit infosec background).

The current case is just not ideal.

Ok, then let's improve this.

My proposal:

  • same text for existing and not existing accounts (login and password forgot)
  • always show both fields

Assume you live in Saudi-Arabia, where homosexuality is punishable by death. You have an account in gay porn shop.
Do you, or do you not, consider this information confidential?

_But this does not break the law to be exact (talked with our internal data protector and others, and I have a bit infosec background)._

This is very much opinion based at this point, as GDPR is new. Ultimately, it is to court to decide and one can not be too confident on either side. However, the only safe assumption is to consider that "an account with the current email exists" is confidential information.

Note that we are not talking about login and messages after successfull/unsuccesfull attempt.

My proposal:

  • same text for existing and not existing accounts (login and password forgot)
  • always show both fields

So this should solve your concerns.

@DanielRuf The proposal is actually very good.

Though, I think we should not jump into conclusions too quickly.

This issue needs to be analysed more thoroughly to fully understand it.

  • is the privacy issue really significant?
  • is there really a legal issue? If yes, where? Do different countries/area have different legistlation?
  • if there is a legal issue, what needs to be done to fix it? Is a software change needed? Or could the legal requirements be fulfilled e.g. by informing customer in T&C. Then, from Magento point of view, this would perhaps become a documentation issue.
  • if software needs to be changed, what and where? Should the changes be configurable, i.e. admin can choose whether to use the old or new way?
  • the checkout has been reported, but are there other places where the issue is present? Perhaps thank you page has to changed as well? Changing UI alone does not do much, if isEmailAvailable ajax call remains.

If it turns out, that checkout page has to be changed what are the possible changes and how usability testing is conducted to make sure UX is not reduced? In an ecommerce application, the checkout page should not be just changed, without deep analysis as it is critical to conversion and business. And the way it currently works is quite nice.

I, personally, think that there might be an issue (for reasons already discussed in detail), thus I raised the issue. However, I think this needs more analysis and in case the issue is confirmed, a deep analysis what and how needs to be fixed.

Hi @engcom-backlog-nazar. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

  • [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
    DetailsIf the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.
  • [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

  • [ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

  • [ ] 4. Verify that the issue is reproducible on 2.3-develop branch

    Details- Add the comment @magento-engcom-team give me 2.3-develop instance to deploy test instance on Magento infrastructure.
    - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
    - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!

  • [ ] 5. Verify that the issue is reproducible on 2.2-develop branch.

    Details- Add the comment @magento-engcom-team give me 2.2-develop instance to deploy test instance on Magento infrastructure.
    - If the issue is reproducible on 2.2-develop branch, please add the label Reproduced on 2.2.x

  • [ ] 6. Add label Issue: Confirmed once verification is complete.

  • [ ] 7. Make sure that automatic system confirms that report has been added to the backlog.

Hi @terolahtinen thank you for you report, i'm closing this issue, if someone in future have the same problem, we can reopen this one. This problem need to be more analyzed.

Was this page helpful?
0 / 5 - 0 ratings