In June 2017, the US National Institute of Standards and Technology (NIST) issued new guidance on authentication in the form of four Special Publications (SP).
- SP 800-63 is an overview of digital identity and the other three publications in the series.
- SP 800-63A discusses digital enrollment and identity proofing.
- SP 800-63B discusses authentication and lifecycle management.
- SP 800-63C discusses federation and assertions.
This post is about SP 800-63B which covers the new password guidance from NIST. In the vernacular of NIST, a password/passphrase is referred to as ‘Memorized Secret Authenticator’. Here are the key attributes offered by this new NIST guidance:
- A Memorized Secret Authenticator must be at least a minimum of eight characters in length and should allow for at least 64 characters.
- All printable ASCII characters should be allowed for comprising a Memorized Secret Authenticator.
- A replacement Memorized Secret Authenticator used to reset a forgotten/corrupted/compromised Memorized Secret Authenticator must be at least six characters long.
- A Memorized Secret Authenticator can be forced to comply with blacklisted words/phrases to avoid guessing or brute force attacks.
- No hints are allowed to be provided to unauthenticated users.
- When changing a Memorized Secret Authenticator, the provider should ensure that the new Memorized Secret Authenticator is not known to be compromised, a known word or expected value such as ‘12345678password’ or similar.
- The Memorized Secret Authenticator can be displayed if it cannot be readily observed by others.
- Verifiers should not impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets.
- Verifiers should not require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers shall force a change if there is evidence of compromise of the authenticator.
A lot of clients are pushing hard to use these new NIST rules in place of the PCI DSS requirements. As a reminder, the PCI DSS requires the following when it comes to passwords.
- 8.2.3 Passwords/passphrases must meet the following: require a minimum length of at least seven characters, contain both numeric and alphabetic characters. Alternatively, the passwords/ passphrases must have complexity and strength at least equivalent to the parameters specified above.
- 8.2.4 Change user passwords/passphrases at least once every 90 days.
- 8.2.5 Do not allow an individual to submit a new password/passphrase that is the same as any of the last four passwords/passphrases he or she has used.
- 8.2.6 Set passwords/passphrases for first-time use and upon reset to a unique value for each user, and change immediately after the first use.
So where are we in regard to NIST versus PCI DSS?
On length, we are good. Both documents have a minimum of 8 characters.
Complexity is a sticking point as the PCI DSS imposes complexity rules on the composition of passwords, NIST states that the authentication system should not impose such composition rules.
NIST is more restrictive on the checking of password/passphrase changes to include ensuring that they have not been used somewhere else that was compromised. In addition, it also requires that if believed to be compromised, the authentication system should force a change.
However, it is when we get to changing passwords/passphrases on a specific interval that we run into trouble. NIST advises that arbitrary changing of passwords/passphrases are not required whereas the PCI DSS states that passwords/passphrases should be changed every 90 days. NIST counts on the fact that they require to monitor that credentials have not been compromised to support their not requiring an arbitrary change of passwords.
The first thing that comes to peoples’ mind is the guidance to requirement 8.2.3 which states:
“Strong passwords/passphrases are the first line of defense into a network since a malicious individual will often first try to find accounts with weak or non-existent passwords. If passwords are short or simple to guess, it is relatively easy for a malicious individual to find these weak accounts and compromise a network under the guise of a valid user ID.
This requirement specifies that a minimum of seven characters and both numeric and alphabetic characters should be used for passwords/ passphrases. For cases where this minimum cannot be met due to technical limitations, entities can use “equivalent strength” to evaluate their alternative. For information on variability and equivalency of password strength (also referred to as entropy) for passwords/passphrases of different formats, refer to industry standards (e.g., the current version of NIST SP 800-63.)
Note: Testing Procedure 8.2.3.b is an additional procedure that only applies if the entity being assessed is a service provider.”
What people focus on is the last sentence before that note that states:
“For information on variability and equivalency of password strength (also referred to as entropy) for passwords/passphrases of different formats, refer to industry standards (e.g., the current version of NIST SP 800-63.)”
They then refer the QSA to that statement and say that gives them license to apply that guidance to requirement 8.2.4 and the other password related requirements. Unfortunately, that guidance only applies to 8.2.3 as it clearly references “password strength” and nothing about change interval or anything else related to password attributes.
Another key point is that the guidance for 8.2.4 makes no reference to SP 800-63. The Council will tell you that if SP 800-63 applied to 8.2.4, they would have included the same sort of reference in the guidance for 8.2.4 as they did in 8.2.3. Without that reference, a QSA should not be using the new NIST guidance to replace the requirements specified in 8.2.4.
So, with that path ruled out, the second thing that comes to peoples’ mind is, we will write a compensating control for following the NIST guidance.
There is only one thing wrong with the compensating control approach and that is that a compensating control must go “above and beyond” the PCI DSS requirement. Above and beyond 90 days would be a value less than 90, not more than 90. The test is very specific that the change interval must be no more than 90 days. As a result, there is no compensating control that will get you above and beyond the intent of a 90-day change interval.
That is not to say that you and your QSA cannot write such a compensating control. The question then becomes if you can get your acquiring bank to sign off on such a compensating control? There are a number of banks that are not so diligent with their reviews of PCI ROC filings and such a compensating control would sail under the radar. But that is no guarantee.
However, such a compensating control puts your QSAC at risk of remediation if the PCI ROC is selected as part of the Council’s Assessor Quality Management (AQM) review. Such a compensating control would not be viewed favorably by the Council because it flagrantly violates the rules of a compensating control. Remediation, while not a death nell to a QSAC, does adversely impact sales of PCI assessments and services and makes current clients uncomfortable, so going into remediation is avoided by QSACs like the plague.
The bottom line is that until the Council makes a change to the PCI DSS (i.e., v4), you are stuck with its password/passphrase requirements regardless of what other standards setting bodies state.
UPDATE – June 28, 2019
This is from the PCI SSC June 2019 Assessor Newsletter.
“PCI DSS v3.2.1 to NIST Cybersecurity Framework Mapping
In July, the PCI Security Standards Council (PCI SSC) will be releasing new resources that show how the PCI Data Security Standard (PCI DSS) maps to the NIST Cybersecurity Framework. PCI DSS and the NIST Cybersecurity Framework share the common goal of securing data. The Mapping of PCI DSS to the NIST Cybersecurity Framework will provide a resource for stakeholders to use in understanding how to align security efforts to meet objectives in both PCI DSS and the NIST Cybersecurity Framework.Details about the Mapping of PCI DSS to the NIST Cybersecurity Framework will be coming soon to the PCI SSC website.”
PCI Guru 
I was reading your blog and ended up seeing the mapping from PCI DSS site which isn’t helpful when thinking compensation for every 90 days password change. They do not tell anything on the mapping about control 8.2.4. obviously because there isn’t one in NIST. There went my hope of getting something specific. https://www.pcisecuritystandards.org/pdfs/Mapping-PCI-DSS-to-NIST-Framework.pdf
“NIST advises that arbitrary changing of passwords/passphrases are not required”
The standard does not say that password/passphrase changes are not required- it specifically says that you should not require password/passphrase changes.
The former implies you don’t have to do them but can if you want to. The latter says you should not do them at all and that is an important distinction. PCI and NIST contradict each other here and all the evidence suggests that PCI is on the wrong side of this argument.
Let us not play a semantics game because that tosses us down the legal interpretation rabbit hole that gets no one anywhere.
At the end of the day, NIST is saying that requiring arbitrary password changes is not a requirement of their standard. Therefore, requiring a password change on some set schedule is NOT required. Period. That is all they have said.
However, they then suggest that controls need to be implemented at the time a password is changed to ensure the credentials being supplied have not already been compromised using reliable sources that track such information as well as to monitor devices/networks for credential abuse. If abuse is detected, then NIST says that you need to advise the user of the credential abuse so they can change their password.
PCI and NIST do not contradict each other, so much as they are taking a different approach to solving a known problem which is the cracking of easy passwords. If you also noticed, NIST allows for an minimum password length of eight (8) characters. That is to support all of the US Government owned systems that do not support more than eight character passwords. Are you really thinking of allowing some eight character password (no complexity or special characters) to protect a system for 12 months or more when it can be cracked in under two minutes? That is the problem PCI addresses and requires the 90 day change time frame. NIST tackles it from a monitoring approach which may or, more likely in the eight character scenario, may not work.
Requiring arbitrary password changes with no suspicion of credential compromise is a pet peeves of mine. That said, isn’t “…cracked in under two minutes” a red herring? You are correct, full unimpeded access to logon attempts or the hashes, cracking of simple passwords is fairly easily achievable, but most systems should have protections in place for invalid login attempts, either significantly delaying repeated attempts or locking out the credentials entirely, and usually combined with some sort of alerting mechanism. IMHO, requiring arbitrary password changes simply lead to post-it notes, forgotten passwords, and user frustration (I know, I know, user frustration is not a security consideration – but it is).
Yes, there are other controls here that also need to be in place. But I am talking about the controls that NIST SP800-63B specifies and the controls you speak of are NOT documented there. Not sure why, but they are not.
“most systems should have protections in place” – well, yeah, this is a PCI forum so they are required to have these protections in place.
SHOULD and SHOULD NOT have very specific meanings in these documents and use the same definition as Internet RFCs: https://tools.ietf.org/html/rfc2119
NIST is not saying they are not required- they are actively advocating against them.
SP-800 63b also does not specify a minimum password length of 8 characters so I’m not sure where that came from- the password length is based on level of assurance and the length is different at each level. 8 was permitted for LOA2 and based on a specific threat model.
Regardless- none of this changes the fact that arbitrarily requiring people to change memorized secrets has been shown to be less secure. If you are concerned with cracking- then require longer passwords which does work- not arbitrarily changing them which does not.
Not true. 5.1.1.1. Memorized Secret Authenticators on page 17 states, “Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber;”
I am not saying that the NIST standard is bad or even opining on their standard. All I am trying to point out is how anyone attempting to meet compliance with the PCI DSS is going to have to do to be judged compliant if they follow NIST SP800-63B.
Seems that for the next major release of PCI DSS the Council maybe will align PCI password guidance with NIST password guidance
https://blog.pcisecuritystandards.org/pci-dss-looking-ahead-to-version-4.0
“PCI DSS v4.0 will incorporate input received from global PCI SSC stakeholders during the 2017 request for comments (RFC) period. Some of the specific areas that stakeholders asked PCI SSC to review include:
Authentication, specifically consideration for the NIST MFA/password guidance”
Maybe. Maybe not. I have friends that are involved in the process and the subject of NIST passwords has yet to be broached. Not to say it will not be discussed, just that it has not been discussed thus far.
I see a principal problem here in your argument, that a compensating control must be “above and beyond” and thus must less than 90 days.
To my understanding a compensating control has to address the risk associated with the requirement through other controls that are “above and beyond” what is required by PCI DSS in *other* requirements, not in the same requirement that you want to compensate. This is clearly expained in Appendix B of the standard.
Demanding that the CC must be “above and beyond” of the requirement that is to be compensated, would forbid any CC at all.
So how would a password change of say 180 days go above and beyond the requirement of 90 days?
It doesn’t go above 90 days requirement but I don’t take the password expiry time as an independent control. The CCW information I use is all of the password requirements that have been put in place to negate the need for password expiry.
But, the Council DOES treat every requirement as independent of every other requirement. It has been explained that way in their training of QSAs/ISAs since the very beginning.
Again: the “above and beyond” is required with respect to *other* controls, not with respect to the control itself that is not in place and needs to be compensated.
Let me give you an example:
With a password retention period of 180 days, requirement 8.2.4. is clearly not in place.
The intent of the requirement is not to allow the password to be broken within the time of it’s validity.
The compensating control could be to require a password with a minimum lenght of 20 characters, which contains numbers, alphabetic characters and special characters. Additionally the password needs to be validated against a list of commonly-used, expected or compromised passwords.
This goes “above and beyond” requirement 8.2.3 and could also meet the intent to prevent the password to be broken.
I do not claim that this example is a suitable compensating control for every implementation. I only claim that such a scenario is in consent with the “above and beyond” for compensating controls.
I have gone down this road and banks are not willing to accept your logic as part of the CCW. So until we get better guidance from the Council, I think we are stuck with what we have until the requirements are changed.
My point is not whether banks would accept such a CCW or not.
I am questioning your argument that a CCW that allows password retention longer than 90 days is always against the standard (regardless what other controls it might define), and that a QSA puts his good standing with the council at risk, just because of this.
I am in the process of working through a CCW to see if this is even possible and if it is possible, what would the controls be to make it work. Wait for a future post as this CCW idea will need a few more eyes on it before I publish the post.
Surely the logic of not requiring periodic password change only works if all the other replacement controls on passwords get implemented instead – checks against cracked password lists, etc, etc
If the choice is just “expire” or “don’t expire” then to me the answer is still expire.
I deal with the audit teams of lots of finance industry giants and very few of them are telling us to turn off password expiry.
The updated NIST position doesn’t seem to address the situation where a password has been compromised, but nobody knows that. https://www.darkreading.com/application-security/database-security/bad-password-management-exposes-critical-databases/d/d-id/1137125 talks about the password disclosure (and subsequent IP theft) at Nortel which went on for 4 to 8 years, because the execs never changed their passwords.
The main theory against password expiry is that a compromised password is usually used immediately by the attacker, therefore if it expires next week, that’s already too late and therefore serves no purpose and forcing people to change them just encourages recyling passwords by changing from Password1 to Password2 and increases the risk of them being written down.
I understand very well the theory that NIST is proposing. Unfortunately, the Council has not changed the PCI DSS to reflect this thinking and that is what I have to work with as a QSA.
The key to the NIST guidance is ensuring that users choose good passwords in the first place. This should involve doing things like checking known bad passwords, lists of compromised passwords from known data breaches, etc. PCI DSS has no requirements on that, so anything done there is “above and beyond”.
In addition, since the NIST research shows that frequent password changes increases the risk, not having them is clearly lower risk than implementing the original requirement. Easy to go “above and beyond” there…
If an entity wants to follow the NIST guidance, I would write a compensating control covering all the password requirements. You need to look at it as a whole, not each password requirement separately.
From the Assessor Newsletter May 2018:
How Does the NIST Password Guidance Impact PCI DSS?
The password requirements in PCI DSS include a minimum level of complexity and strength that can be met by all types of organizations via many technologies. PCI SSC encourages entities to implement stronger controls or additional security measures as appropriate to meet the security needs of their organization.
PCI DSS does not prevent an organization from implementing alternative controls than those defined in the standard, as long as the intent of the requirements is met. Entities wishing to follow a different combination of password complexity and change frequency (for example, based on the NIST Digital Identity Guidelines) can document their approach as a compensating control. The entity can then demonstrate how the risk is mitigated and how the intent of the requirement is met through implementation of other controls (for example, how controls address the risk of passwords being guessed during their lifecycle).
In the case of the recent NIST guidance, it is important not to look at any single recommendation in isolation but to take all the recommendations as a complete set of controls. For example, the suppression of the periodic password change is compensated by implementing more stringent rules to ensure that the password cannot be guessed. In other words, suppressing the requirement for periodically changing passwords without the implementation of additional compensating controls does not meet the intent of either the NIST guidance nor the PCI DSS password requirements.
PCI SSC continually monitors changes in technologies and payment environments and may incorporate updates in future PCI DSS revisions as needed to support evolving industry best practices.
The requirement to force a password change every 90 days has always been a pet peeves of mine. I believe it causes more security issues than it solves. Regular forced password changes promotes te post-it note vulnerability. Also with many application, the password reset process users must perform when they forget their password is less secure than the normal authentication process. I’m not sure PCI ever considered this when the mandate was created. NIST seems much more reasonable, only requiring change upon compromise or suspected compromise. I hope PCI adopts the same.
I heard a gentleman from Bell Labs years ago that stated that you should have three passwords, one that you don’t care if it’s breached, one that would be inconvenient if it were breached, and one that cannot ever be breached. He suggested using upper/lower case alphabetics, numerics and specials (if possible) to make up your password. That said, he also suggested creating a standard six character complex starter such as ‘Sp3ci@l’ plus a four digit PIN. You would only have to change the four digit PIN every 90 days. Seems pretty simple and straight forward approach.
Sounds simple enough. Simply teach that to millions of Internet users. 😉
I’ve always said don’t use the obvious letter replacements such as “@” for “a” and “3” for “e” as everyone knows that so a smaller brute force table can be used by including just these substitiutes rather than all symbol combinations.
90 days for password resets has always been somewhat nebulous in terms of the “spirit” of the requirement. I think there are two major factors in why this time period was originally set this way: 1) the belief that it would take longer than 90 days to “crack” or recover the password through brute force methods, and/or 2) the desire to minimize the relative amount of time that an attacker would have access to a stolen or hijacked account. Given those goals it would seem that a longer password reset period could be allowed by compensating control if the length/complexity of the password was increased beyond what PCI requires to at least a comparable “brute force” number of possible password combinations, then would that not be a valid consideration for a compensating control? Of course, if you use that logic, I’m not sure a 7- or 8-character password with the minimal “must use alphabetic and numeric characters” requirement itself is sufficient to protect against brute-forcing the password within 90 days.
My hope is this section is given a major scrubbing during the development of PCI DSS v4.0 because I think maybe PCI DSS has fallen way behind in this particular area.
So, if I have password character length of 12, which is above and beyond the password length requirements for PCI, for storage (use PBKDF2, 32-bit random salt / secret, and increase iterations – all NIST 800-63B guidances for storage and above the vague “strong cryptography” password storage requirements for PCI) and do password checks against known compromised password DBs, couldn’t a CCW be used to extend the 90 days to 180 days or more? To me these far exceed the requirements for CCW and would not get a QSAC into remediation.
The problem is that the change interval option is independent of the length. While I agree with your rationale, I am afraid that the Council and the Brands would not and I seriously doubt that any QSA is going to go into remediation over such an analysis.
I think the presentation we gave at the PCI CM in London and Vegas would not have been allowed as we talked very specifically about the differences of NIST/PCI in this area and using the NIST guidance as a way to move past the 90 days for a CCW. That said, it was not tested via the AQM process but a technical committee review from the PCI SSC.
There have been too many instances where statements are made at the CM and then get taken back or severely revised after the Council and the Brands have time to think about their statements.
To my understanding this argument shows a wrong understanding of the general idea of compensating controls (above and beyond *other* PCI DSS requirements).
I had posted a comment on this in this thread a few days ago, which was apparenty dropped by the moderator. Can you please let me know, why this happened?
I didn’t drop it so much as I have been traveling the past few weeks and have not had time to respond to anything posted here. This blog is a sideline, not my primary job so I too have work to do and cannot always be as timely as my readers would like. I did approve your post this morning.
I totally agree that, from the audit/compliance perspective, we are stuck with what we have in the DSS for now. My biggest concern would be taking 800-63B piecemeal… if it were to be used for a CCW, I would think all “SHALL” statements need to be implemented (as defined in 800-63).
If we accept that all SHALL statements are required to “align with NIST SP 800-63B for the purposes of a CCW” we need to consider the systems being included in this CCW. Active Directory is very often in-scope for the CDE, yet it is not possible to configure AD to align with NIST SP 800-63B. There are third party addons that can get you close (e.g. credential blacklist checks), but cannot align with the following:
“Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Memorized secrets SHALL be salted and hashed using a suitable one-way key derivation function. Key derivation functions take a password, a salt, and a cost factor as inputs, then generate a password hash. Their purpose is to make each password a guessing trial by an attacker who has obtained a password hash file expensive and therefore the cost of a guessing attack high or prohibitive. Examples of suitable key derivation functions include password-based Key Derivation Function 2 (PBKDF2) [SP 800-132] and Balloon [BALLOON]. A memory-hard function SHOULD be used because it increases the cost of an attack. The key derivation function SHALL use an approved one-way function such as Keyed Hash Message Authentication Code (HMAC) [FIPS 198-1], any approved hash function in SP 800-107, Secure Hash Algorithm 3 (SHA-3) [FIPS 202], CMAC [SP 800-38B] or Keccak Message Authentication Code (KMAC), Customizable SHAKE (cSHAKE), or ParallelHash [SP 800-185]. The chosen output length of the key derivation function SHOULD be the same as the length of the underlying one-way function output.”
The UK has had the National Cyber Security Centre password guidance for a few years now that states: “Don’t enforce regular password expiry. Regular password changing harms rather than improves security. Many systems will force users to change their password at regular intervals, typically every 30, 60 or 90 days. This imposes burdens on the user and there are costs associated with recovering accounts.”
Most of the places I audit have changed to this method now for standard users and this is put in the compensating control as it is considered a stronger control than changing passwords every 90 days. So far, they’ve not had any comeback from the banks.
UK banks are going to have a better position to argue from than US banks because that standard has been in place for a long time versus slightly more than a year in the US.