"How to set a strong, unique and memoriaable user password" - this topic has been winning today the first lines in articles about cybersecurity. It often happens that I still see stickers on monitors, notes written on a piece of paper and.... for sure, passwords and PINs written by plain text in the address book, notes app or even home screen widget. However, what if you think a little about the users and don't just give them all the full responsibility? Issued by NIST Special Publication 800-63B. Digital Identity Guidelines. Authentication and Lifecycle Management offers recommendations for service providers, portals and others whether they are cloud based or on-premises. This is not a new document, but it is periodically updated (the latest version is dated 2020) and is still relevant.
Security should be comfortable, I keep saying that. It is gratifying that the guys from NIST worrying about users created best practices for services. Following them, it will be more profitable and easier for users to use well-made passwords, while you do not need to require them to constantly complicate, unnecessary actions and lengthy instructions. For some provisions, I really want to shake hand, because they do debunk a lot of myths.
Actually NIST SP 800-63B contains many aspects of the password management lifecycle and 9 types of authentication. Let me talk today about the only one of them
(Memorized Secret Authenticators).
- Passwords must be at least 8 characters long if they are created by the user, and at least 6 characters long if they are generated automatically. Important: Passwords may be entirely numeric
- The service is recommended to check passwords based on their appearance in the black list of compromised values
- The service should not allow the use of "dictionary" or simple passwords (111, aaaa, qwerty, etc.). Fortunately, there are many such lists on the Internet to check.
- The service sholud prohibit passwords that contain the username or part of it
- Very important (and sometimes a popular myth): No other complexity requirements for memorized secrets should be imposed (like variety of chars, case, digits).
- The service shuold technically support the use of passwords of at least 64 characters in length
- All printing ASCII [RFC 20] characters should be acceptable, including spaces
- Unicode [ISO/ISC 10646] characters (including emojis!) should be acceptable, including normalization and equal number of symbols (1 UNICODE = 1 ASCII)
- The service shall not permit the user to store a “hint” that is accessible to an unauthenticated claimant (Do you remember hints in earlier Windows versions on the login page?)
- Conversely, the service shall not prompt subscribers to use specific types of information and help them not to use typical phrases (e.g., “What was the name of your first pet?”)
- The service should show examples and explain to users why his or her password is not secure and refuse to use it if it matches a blacklist or dictionary
- The service shall implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account (in fact, the number given is quite high - 100, however, it's good practice to use additional mechanisms such as captcha, time limit between attempts, etc.)
- Ones more myths breaking: the service should not require passwords to be changed arbitrarily (e.g., periodically). Instead the service shall force a change if there is evidence of compromise of the authenticator.
- The service should permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.
- The service should offer an option to display the secret — rather than a series of dots or asterisks ("*"). It's also useful to permit the user’s device to display individual entered characters for a short time after each character is typed to verify correct entry (particularly applicable on mobile devices).
- The service also has requirements for reliable password storage and protection when it is requested (transmitted), such as a hash with a "salt", communication encryption, etc.
These recommendations are based on practical experience and many (especially large services) have already implemented them. However, if you are designing your own service or application, it is useful to familiarize yourself with it.
See also: MFA. Part 1, MFA. Part 2
Stay on the light side. R.Z.
No comments:
Post a Comment