Once
upon a time it was enough to have an evil grandmother at the entrance to the machine room to protect the password. Long ago, back in the days of the early mainframes, there was excellent two-factor authentication. Before entering your personal password in the terminal, it was necessary to go through the booth with a guard. All this automatically narrowed the attack surface to a few people who physically had access to the terminal. It was then that modems, hashing and other joys of the modern world appeared, when passwords are regularly leaked by the millions.
If you have users and they log in with a password, I suggest taking another look at the latest recommendations from organizations such as the National Institute of Standards and Technologies and the National Cyber Security Center .
In particular, it is no longer fashionable to require password rotation. And to demand certain symbols in the best traditions of the joke about "FUCKING ROSE" too. Let's go over the main points and try to make users more convenient and safer.
Authentication is not binary
No, I understand that adherents of strict formulations will now begin to resent. In theory, the user is either logged in or not. You won't be able to log in a little. And yet, modern information security guides imply a non-binary approach to user trust.
A perfectly trusted user managed to enter the password correctly and logs in from an authorized device. Slightly less trust in a user who logged in from a trusted device, but made a mistake when entering the password. And it's really bad if the user entered the password correctly, but the device is untrusted, the second factor is not confirmed, and the IP belongs to the output node of Thor. In the third case, it's time to pull the switch with the inscription “Alarm! The wolf stole the rabbits! "
Our task, as people providing the service, is to make people comfortable, safe and not very painful if they make mistakes. Therefore, it is worth placing certain signs of abnormal activity in order in order to include certain additional measures to protect the account. For example, after 3-5 incorrect password entries, prompt the user to go through the CAPTCHA. Yes, everyone hates it, but most users will not encounter it. And those who downgraded their trust rating will just slow down a little before entering the password again. But we will cut off automatic brute-force attacks.
No need to limit the maximum password length
Long passwords are safer. Let users use them.
Well, not that it is not necessary at all. Bold passwords of several megabytes in length can potentially backfire in unexpected places or other strange effects. But the conditional maximum length of 300 characters is guaranteed to suit any typical user. Moreover, NIST adheres to the same recommendations:
The authenticator must allow the user to use memorable passwords of at least 64 characters.
And for especially gifted services, NIST also provides another important recommendation:
Truncating the user's password is not allowed.
Yes, there are extremely strange services that believe that 12 characters will be enough, which means that the remaining 28 can be safely cut off and check the hash of only the first fragment. I don’t know what the affected mind thought of this, but the same banking organizations often suffer from this. Don't do that. If a user wants to use a piece from Iliad in half with fragments of texts from the Bloodstock group, let him use it.
Make sure any ASCII characters are valid
There are certain problems with special characters. For example, the use of "{} / \" or other similar characters may potentially be invalid in some situations. Let's say curly braces can break valid JSON and cause password processing to crash. Or the apostrophe character, which can be used in SQL injection. Yes, the password entry form can also be an entry gate for an attack.
In theory, you could simply prohibit the use of such symbols to make it easier for yourself. But by doing so, you will reduce the entropy of the user's password and make it inconvenient for him if the password is generated automatically. You will have to select certain patterns for exceptions. Again, referring to NIST
All printable ASCII [RFC 20] characters, including space, must be valid passwords. Unicode characters [ISO / ISC 10646] must also be valid.
Yes. Everything is correct. This is your headache and additional testing. But if the user wants to use ਬਹੁਤ ਮੁਸ਼ਕਲ ਪਾਸਵਰਡ or මෙයද ඉතා දුෂ්කර මුරපදයකි, let him do it. Or add a burrito character to your password for cryptographic strength. Has the right to.
Also, lag behind the user with the requirement to use special characters. Yes, just don’t touch him. Let him use what he wants. Studies of mass leaks suggest that people still use stupid substitutions with special characters, which does not improve the situation at all. Specifically, Microsoft writes:
Most people use the same pattern, for example, a capital letter as the first character, special characters and numbers in the last two positions. Cybercriminals are aware of this and customize their dictionary attacks with typical substitutions such as "s" for "$", "a" for "@" and "i" for "l".
Yes, the same Microsoft, because of which millions of people every month come up with a new password that does not coincide with the previous ones, containing special characters and letters in different case. They are the ones who now write "Eliminate character-composition requirements" in their guidelines.
After all, in the end, typical utilities like cain and abel, hashcat, john the ripper can guess the password for several hours or even minutes on a typical video card, if a standard vocabulary word and a typical replacement pattern were used.
Don't use password hints
It is much safer to bury a forgotten password forever than to store a hint for the user in clear text in the database.
In 2013, Adobe leaked its password database. It was encrypted crookedly, but the most unpleasant thing is that it contained hints for recovery, which Randal Monroe did not fail to make fun of in xkcd.
The same opinion is shared by NIST, which does not recommend storing hints in any form. Forgot - restore via mail with all additional checks.
Reduce the load on the user's brain
The National Cyber Security Center has released a cool infographic . Let me quote a small passage:
Note that the main problem with passwords is that a good password is random and almost impossible to remember. If there are many services, then the user will almost inevitably use the same password wherever possible. The more advanced will do something like "myp@ssword_habr.com". Naturally, compromising a password in one place automatically compromises accounts in all other services.
Therefore, let the user use password managers. Yes, it's like a special wallet for bank cards that allows you to lose them at the same time. But here you need to understand that the compromise of an offline password storage is a rather rare situation, in contrast to the compromise of the same passwords on different resources. A password manager doesn't have to be perfect. It needs to be better than the same type of passwords everywhere. Don't be like some nasty service that blocks the ability to paste a password into a field from the clipboard. This clearly forces the user to abandon the password manager and use the weak option.
The second point says that there is no need to force the user to change his password if there are no obvious signs of his compromise. This only motivates him to use the pattern with the same password. It is much better to raise the alarm if the password pops up in one of the many leaked dictionaries. Naturally, you cannot let the user create a password that has already been included in the dictionaries.
conclusions
- Be kind to the user. Do not force him to come up with typical patterns and do stupid things. Standard habitual requirements directly push him to this. Just follow a few points:
- Use key authentication instead of passwords where applicable.
- Do not let the user use a password if it is in the dictionary databases. It doesn't matter if he leaked them there or someone else.
- , . . .
- , .
- , .
