I'm already tired of
writing passwords . But like taxes, e-mail and red eyes, they are not going anywhere. What can I say, based on experience:
- no matter what you say to users, they will choose simple passwords
- and they will use the same password everywhere. If you are lucky - two passwords
What can a developer do with this?
- stop requesting passwords and allow authorization via google, facebook, twitter, yahoo or any other service. The best password is the one you do not need to store .
- Encourage browsers to support automatic embedded password creation and management. Ideally, they are also supported by operating systems, but here a universal binding to cloud technologies is already required. Chrome is moving in this direction.
- kick users when they enter:
- passwords too short: UY7dFd
- entropy minimum passwords: aaaaaaaaa
- passwords from the dictionary: anteaters1
This is usually done using a
password complexity indicator , which works interactively.
This is used when it is impossible to avoid storing passwords.
')
The easiest way to strengthen the password, making it longer. Other things being equal, the exponential law says that the longer the password, the better. I
love secret phrases , although it's very hard to type on touchscreens in our mobile world. But how long should the password be?
When developing
Discourse, it was necessary to choose the minimum acceptable password length. I chose 8, based on quick research. This is not so much, but if you use a sufficient number of different characters, it should be enough to protect against attacks.
And I do not mean those attacks, when the selection of passwords occurs through the reloading of pages or input forms. This may work for the most popular passwords, but usually sites and applications are protected from frequent data re-entry.
I mean high-speed offline selection of hashes, where the hacker has a database of leaked passwords. Such leaks were and will be.
If you are unlucky, the developers of the application, service or site store passwords in clear text. This is not often the case lately - progress. But even if they saved the password in a hash - pray that it was a slow and complex hashing algorithm, such as
bcrypt . And they chose a sufficient number of iterations. Oops, it was relevant for a long time, in the Middle Ages, around 2010. I wanted to say that
scrypt should be chosen as an algorithm.
And everything will be fine. Yes?
- take a random set of 8 characters. Note that the generator is also the default length. I received "U6zruRWL"
- we will enter it in the input field of the GRC password crack checker password complexity check service
- we get that when using the “Big array for hacking” the speed of its detection will be 2.22 seconds
- let's go lie down with a warm towel on his face
You will say that “a large array for hacking” is exotic. Excuse me. An array of 24 ordinary GPUs optimized for fast hash selection is available to any agency and medium-sized business. Moreover, they do not have to buy, and you can rent - for example, in the cloud. And imagine what a national scale agency is capable of. Horror.
Even if we discard this scenario, then in the column “simple offline brute force” is only 37 minutes.
Let's try to extend the password. What happens?
9 characters - 2 minutes
10 characters - 2 hours
11 characters - 6 days
12 characters - 1 year
13 characters - 64 years
Maybe add special characters?
8 characters - 1 minute
9 characters - 2 hours
10 characters - 1 week
11 characters - 2 years
12 characters - 2 centuries
Already not bad, but only the 12-character mark, containing upper and lower case, numbers and special characters, seems to be safe.
And “big arrays for hacking” will not become slower. There will always be a number of characters that, thanks to the exponent, will be unattainable, but over time, the processor power will only grow.
I'll tell you what, unfortunate user: if your password is shorter than 12 different characters, you are in danger. Create random passwords no shorter than 12 characters.
Of course, all these calculations
depend on the hashing
algorithm used . We'll have to accept that all the passwords you use will be stored with encryption with the stupidest and fastest algorithm. There are too many old programs and algorithms that will live for a long, long time.
Developers:
- choose hashing algorithms carefully. Update your systems. Use hashes that are difficult to select on the GPU, for example scrypt.
- Select the correct hash, choose the correct settings for its operation. Matsano recommends these settings:
- scrypt: N = 2 ^ 14, r = 8, p = 1
- bcrypt: cost = 11
- PBKDF2 with SHA256: iterations = 86,000
But these are only tips - you need to adjust the settings to the realities of your server systems. For example, we had a case where a bug in Discourse allowed users to drive passwords up to 20,000 characters long, and the hash count of this password took many seconds.
And now I’ll go I’ll change my PayPal password.