Product: Credit card or prepaid card

XXXX XXXX Dear CPFB, I have a new XXXX XXXX XXXX XXXX from U.S. Bank and I was able to set up an online account with U.S. Bank for this Credit Card. 

However, I use XXXX XXXX  XXXX and I tried to attached the Credit Card to XXXX XXXX XXXX   update and I found the Password Policies to attached the Card to XXXX XXXX  XXXX in violation of the United Stated Password Standard ( https : XXXX I looked it up so you believe me ) and I would know because I am a computer expert of about 37 years and I have a College Degree in XXXX XXXX. U.S. Bank is responsible for the password policies in XXXX the attach picture of the password rules say so, " This institution require a password to change and only be 8 characters '' Which an illegal Policy exactly ; and a direct security risk to U.S. Bank and the users as well. 

There are many password rule violations the worst of which are " No more than XXXX Characters '' very wrong and " required to change password from existing password '' Wrong and " can not be same as the old one '' I called U.S. Bank Technical Support XXXX but they assure me the following the law, which they are not, and U.S. Bank Technical support refuse to address this issue at all. I called the Bank at least 3 times before I filed this complaint, they will not listen at all even though I am trying to help them. 

XXXX NIST guidelines In XX/XX/XXXX, the United States National Institute of Standards and Technology ( NIST ) issued a new revision of their digital authentication guidelines, NIST SP 800-63B-3, stating that : [ 13 ] :5.1.1.2 Passwords must be at least 8 characters in length if chosen by the subscriber. 
Password verifier systems should permit subscriber-chosen passwords at least 64 characters in length. 
All printing ASCII characters as well as the space character should be acceptable in passwords. Acceptance of Unicode characters is also permitted.

Verifiers may replace multiple consecutive space characters with a single space character prior to verification, provided that the result is at least 8 characters in length, but truncation of the password shall not be performed. 
Verifiers should not impose other composition rules ( e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters ) for passwords. 
Verifiers should not require passwords to be changed arbitrarily ( e.g., periodically ). However, verifiers shall force a change if there is evidence of compromise of the password.

Verifiers shall not permit the subscriber to store a hint that is accessible to an unauthenticated claimant, and verifiers shall not prompt subscribers to use specific types of information ( e.g., What was the name of your first pet? ) when choosing passwords.

When processing requests to establish or change passwords, verifiers shall compare the prospective passwords against a list that contains values known to be commonly-used, expected, or compromised. The list may include, but is not limited to : o Passwords obtained from previous breach corpuses, e.g. Online Breach Databases [ 14 ], Breached Collections [ 15 ] o Dictionary words o Passwords consisting of repetitive or sequential characters ( e.g. aaaaaa, 1234abcd ) o Context-specific words, such as the name of the service, the username, and derivatives thereof If the chosen password is found in the list, the verifier shall advise the subscriber that they need to select a different password and provide the reason for rejection. 
Verifiers should offer guidance to the subscriber, such as a password-strength meter, to assist the user in choosing a strong password. This is particularly important following the rejection of a password on the above list as it discourages trivial modification of blacklisted ( and likely very weak ) passwords. 
Verifiers shall implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscribers account. 
Verifiers shall store passwords in a form that is resistant to offline attacks. Passwords 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 guessing trial by an attacker who has obtained a password hash file expensive and therefore the cost of a guessing attack high or prohibitive. 
NIST included a rationale for the new guidelines in its Appendix A. 

XXXX XXXX XXXX   =============================================== https : //pages.nist.gov/800-63-3/sp800-63b.html XXXX XXXX XXXXXXXX