Безопасность должны быть удобной - я это повторяю постоянно. Коллеги из NIST выпустили рекомендации главным образом для порталов, приложений и сервисов, которыми мы с вами пользуемся. Следуя им, пользователям будет выгоднее и легче использовать надежные пароля, при этом не нужно требовать от них постоянного усложнения, лишних действий и длиннющих инструкций. За некоторые положения реально хочется пожать руку, ведь они развенчивают кучу мифов.
На самом деле, публикация NIST большая и охватывает все возможные аспекты жизненного цикла "секретов", а также 9 типов аутентификации. Мы же сегодня - исключительно про пароли (Memorized Secret Authenticators).
- Пароли должны быть не менее 8 символов, если придумываются пользователем сервиса и не менее 6, если создаются генератором (например, встроенным в сам сервис), они могут состоять только из цифр.
- Сервису рекомендуется автоматически проверять, не "засветились" ли пароли в слитых базах
- Сервис не должен разрешать использовать "словарные" и очень уж простых простые пароли, благо сравнение с таким справочником сделать несложно, они есть в открытом доступе
- Сервис должен запрещать пароли, содержащие имя пользователя или его часть
- Отдельно оговаривается то, что для нашего уха (профдеформированного разного рода РД и НПА) может показаться странным: никаких дополнительных требований, кроме длины, к паролю предъявлять не стоит (разные наборы символов и т.п.).
- Сервис должен технически предоставить пользователю возможности придумать пароль длиной 64 символа (или больше)
- В паролях должны поддерживаться все символы ASCII [RFC 20], включая пробелы
- Unicode [ISO/ISC 10646] кодировка также должна поддерживаться (эмодзи в том числе), включая такую нормализацию, при которой 1 введенный символ в UNICODE эквивалентен 1 в ASCII
- Запрещаются всякого рода всплывающие подсказки (помните, в прошлых версиях Windows были такие?) на формах ввода логина/пароля
- Напротив, сервис должен объяснить пользователю, чтобы тот не использовал подсказки вида "имя питомца, фамилия матери и т.п." и не мог используя лишь только их сбросить пароль
- Сервису необходимо приводить примеры пользователю и объяснять, почему выбранный им пароль вдруг не безопасен
- Количество неверных попыток ввода пароля должно быть лимитировано. Приводится конкретное довольно большое число - 100, с оговоркой, что лучше использовать дополнительные механизмы (капча, лимит времени между попытками и т.п.)
- Еще одно разрушение мифов: сервисы не должны требовать принудительной смена пароля периодически (раз в месяц, год и т.п.). Вместо этого необходимо мониторить утечки паролей и своевременно предупреждать пользователя о возможной компрометации.
- Вопреки расхожему мнению, сервисы должны разрешать функцию "вставить" при вводе пароля. Иначе пользователи вместо сложного пароля из менеджера паролей будут придумывать и использовать менее сложные.
- Сервис должен позволять посмотреть введенный "звездочками" (*) пароль, чтобы пользователь проверил его корректность. Также актуальным (особенно для мобильных устройств) будет показывать каждый вводимый символ на несколько секунд.
- К сервису также предъявляются требования по надежному хранению пароля и защите при его запросе (передаче), такие как хэш с "солью", шифрование связи и т.п.
Приведенные рекомендации основаны на практическом опыте и многие особенно крупные сервисы уже внедрили их. Однако, если вы проектируете свой собственный сервис или приложение, то нелишним будет ознакомиться с ним.
Читайте также: MFA. Часть 1, MFA. Часть 2
Оставайтесь на светлой стороне. R.Z.
"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