Say you have an e-commerce site that falls under the SAQ A-EP standard, due to extra content on the same page as the iframe that takes the credit card info.

This used to fall under the SAQ A standards, but apparently the standards have recently changed to include any site that hosts any other content on the same page as the iframe that takes the credit card info. So now most sites using Stripe/Paypal/Heartland with a JavaScript implementation all fall into this new category.

Which passwords fall under the requirements of 8.2.1, 8.2.3, and 8.2.4?

Is it

  • the website's user/customers
  • System Admins on the server hosting the site
  • the company that is receiving the payment info, or
  • all passwords connected in any way?
| improve this question | | | | |
  • Did you read the text in 8.2? – schroeder Sep 24 '19 at 18:39
  • 1
    The PCI-DSS document clearly says that it is for non-consumers, so the first on your list is out. You have no control over the payment processing company, so your 3rd item is out. Leaving the server passwords (yes, of course) and your catch-all. I guess it all depends on what you mean by your catch-all. Can you expand on that point? – schroeder Sep 24 '19 at 18:47
  • 1
    The intention behind that is that any account that can change content on the payment processing page should fall under PCI-DSS authentication guidelines. This includes accounts with SSH access, FTP access, or access to web tools that can change files on disk or rows in a database so that it will be rendered as raw HTML or Javascript to be interpreted by the browser. As far as the actual letter of the standard, rather than the intention? Well, PCI-DSS isn't my most favorite standard for various reasons... – Ghedipunk Sep 24 '19 at 19:05
  • Thank you all for the responses. I read this pcisecuritystandards.org/documents/SAQ_A-EP_v3.pdf in the parts that seemed to apply to the web development end and not the servers, but never saw anything about it being for non-customers, which is why I may be confused. I guess I will try to find some fuller documentation. I appreciate the clarification. That being said I am guessing it does apply to the website's admins on Drupal and Wordpress sites as they can change the page of the site with the payment form. @Ghedipunk I agree, I am not a huge fan of some parts of it. – Coyote6 Sep 24 '19 at 20:15

That document version 3 aka 3.0 (and the corresponding DSS) is 5 years old, the current version of both DSS and (all) SAQs is v3.2.1 from 2018 (although a draft of the next major version, 4.0, is scheduled for comment soon); see https://www.pcisecuritystandards.org/document_library and select Filterby=SAQS. The actual standard which the various SAQs (and audits/ROCs) are designed to implement, PCI DSS (Data Security Standard), is under the default Filterby=PCIDSS, and it says at the beginning of section 8:

Note: These requirements are applicable for all accounts, including point-of-sale accounts, with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data. This includes accounts used by vendors and other third parties (for example, for support or maintenance). These requirements do not apply to accounts used by consumers (e.g., cardholders).

However, Requirements 8.1.1, 8.2, 8.5, 8.2.3 through 8.2.5, and 8.1.6 through 8.1.8 are not intended to apply to user accounts within a point-ofsale payment application that only have access to one card number at a time in order to facilitate a single transaction (such as cashier accounts).

See particularly the last sentence of the first paragraph. Since A and A-EP systems don't actually receive or store cardholder data, it's their ability to control access to it that matters.

SAQA-EP 3.2.1 reflects this, briefly, in item 8.1, emphasis added:

Are policies and procedures for user identification management controls defined and in place for nonconsumer users and administrators on all system components, as follows:

but 3.0 did not (according to my saved copy), and even now it's not made obvious this applies throughout all of 8.1.* 8.2.* and 8.3.*. Also note A-EP 3.0 did not include DSS 8.2.2 but 3.2.1 does.

Neardupe To whom do the PCI DSS password requirements apply? which answers essentially the same for 3.2 in 2017, before 3.2.1 was published.

| improve this answer | | | | |
  • Thanks! I appreciate the help. It is all a bit overwhelming to look into all this stuff to make sure I am doing things the right way. Are there any standards that apply to consumer passwords then? Say at least one way password encryptions so they can't be emailed back to you or viewed view code or in the database? – Coyote6 Sep 26 '19 at 13:11
  • ^^^^ Just to note: It's not me that is emailing back passwords. That's just what started all this research. I was not happy to see my password sent to me by another person's system. lol – Coyote6 Sep 26 '19 at 13:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.