10

A large supermarket chain in the UK, are storing their passwords in plaintext. Apparently, Mastercard's security department are already involved. I'd like to report them for violating PCI-DSS, since the lack of session security and unhashed passwords represent serious security problems.

I can't see anything about reporting violations on the PCI website - any idea if there's a contact for or contact email for this kind of thing?

Polynomial
  • 133,763
  • 43
  • 302
  • 380

3 Answers3

3

First of all, thank you for sharing this very interesting and revealing post by Troy Hunt. As for your question, after doing some serious Google searching and after consulting with PCI DDS professionals the best answer I can give you is:

If the entity is compliant and still a violation of one of the requirements is discovered by a client or another outside agent, he/she should be able to report the issue to the company support or contact as there is no direct or formal reference or procedure required to that by PCI.

In other words: "Go fish"

Igal Zeifman
  • 563
  • 3
  • 8
1

a) PCI-DSS is a standard, not a certification. It is required by the banks who provide card payment services, and they are the ones who decide if a merchant meets the standard to their satisfaction.

b) How do you know they are not in compliance with PCI-DSS? You can have very poor security in all sorts of areas of your business and still meet the standard - it's very narrowly focussed on credit cards only.

c) Since PCI-DSS relates to a private contract between a bank and their customer, how is their compliance or non-compliance with PCI-DSS any of your business?

Graham Hill
  • 15,474
  • 37
  • 63
  • 1
    a) True, but PCI-DSS is a requirement for their contract. b) Section 3.4 requires that all personal access tokens are rendered unreadable, including passwords. It's a violation. c) Their provider / bank has no idea they're "doing it wrong". || Anyway, are you saying I should inform their bank? What if they *are* their own bank? - in this case they actually are a bank too! – Polynomial Jul 30 '12 at 14:02
  • a) Yes, and as such is a matter for the parties to the contract, not the PCI Security Standards Council. b) PCI-DSS v2 is infront of me as I write, Section 3.4 is "Render PAN unreadable anywhere it is stored" which is unrelated to custoemr passwords. c) Unlikely, and if so it's the bank's problem. If they are their own bank then I imagine their contract is very forgiving. – Graham Hill Aug 01 '12 at 08:56
  • 1
    To clarify my position, I'm not saying that Tesco are right to have terrible security, I'm saying that PCI-DSS is not a stick you (as a Tesco customer) can beat them with. – Graham Hill Aug 01 '12 at 09:00
  • 2
    @Polynomial I'm not sure which version of the DSS you're looking at, but section 3.4 of DSS v2.0 is talking about rendering the PAN (Primary Account Number) unreadable, not personal access tokens. Section 8 talks about password security and 2 factor authentication, but that's for administrator accounts that have access to cardholder data, not to end users. The DSS doesn't really address authentication for end-users. – Johnny Apr 15 '13 at 21:02
0

The only 2 ways that I know that compliance gets enforced is either by a third party paid audit or after your system gets 0wned then it's too late.

I would report this to your higher up management or compliance officers and they do nothing to resolve this, you will atleast have the paper trail that you reported it in the event that the company gets compromised or audited (3rd party or fed).

The best advice I can give is to BCC an external email account with a different password (on your external account) when you send these emails. Remind them that a mistake like this can cost them the company and is just as important as a good TESTED backup solution.

Brad
  • 849
  • 4
  • 7
  • I don't see any reason to believe that Polynomial is an employee of the organization that is disregarding PCI-DSS's requirements, so these suggestions probably aren't very relevant to Polynomial. – D.W. Jul 31 '12 at 06:58
  • How would someone know if the data is encrypted or not on a specific system? I see 3 possibilities 1. They built the system or work there. 2. They work at a vendor that is tied into their system and saw a design flaw. 3. They already compromised the system. The first one seems most probable, however there is a slight possibility that that they overheard in conversation or know someone who works there. All I can say is that if I knew the store, I would not shop there anymore because of this. – Brad Jul 31 '12 at 18:00
  • Ahh, I see where your assumption came from! Actually, the blog post that Polynomial linked to explains how we know that the passwords are not encrypted. Click on the link and you can see the full explanation of how we know. (Short summary: Tesco will email you your password, if you ask for a password reset. This implies that the passwords are not usefully encrypted. So, it turns out you don't have to be an insider or a hacker to know that they screwed this up.) – D.W. Jul 31 '12 at 18:11
  • The link is blank but is probably being filtered from where I'm at. If the password is being emailed in plain text it MIGHT not be a violation depending on legal requirements. HIPAA for example only requires TLS encryption from point A to point B. Luxsci email encryption tests if it is or not prior to sending and if not available then they encrypt it them selves. Check out https://luxsci.com/extranet/tlschecker.html EX. their mail server to say Gmail would be delivered via TLS and atleast for HIPAA would be compliant as far as the delivery mechanism. – Brad Jul 31 '12 at 21:27
  • The PCI DSS doesn't address end-user account access, the DSS is geared toward protecting cardholder data from the merchant, not whether or not someone can make fradulent purchases on your behalf. The only part of the DSS I can find that addresses end-user passwords is section 8.4b that applies to service providers only. – Johnny Apr 15 '13 at 21:07