Password Evolution: A Guide to Authentication in the Modern Age
It all started simply: you have two sets of characters (username and password) and those who know both can log in. Nothing complicated.
However, the ecosystems in which they functioned were also simple — say, a time-sharing system from MTI , which is considered the first computer system where passwords were used.
')
But this situation has developed in the sixties of the last century, and since then much water has flowed under the bridge. Up until the last couple of decades, we had a very small number of accounts with a limited number of connections, which made the spectrum of threats rather narrow. Only those who were in the immediate vicinity could harm you - that is, people who were able to directly, physically gain access to the system. Over time, they were joined by remote users who could connect via the phone, and the range of threats expanded. What happened after that, you yourself know: more interconnections, more accounts, more intruders and more data leaks, especially in recent years. The original scheme with a simple reconciliation of characters no longer seems such a brilliant idea.
A couple of months ago, I wrote about the reusable use of passwords, the stuffing of registration data and that another billion entries were added to the Have I been pwned service database . Things are like this: billions of access details are lying and waiting for some villain to start using them to hack into any site he likes. This poses a very interesting question for us: how to protect yourself in such circumstances? I mean, are you trying to keep the online system afloat, and some type of party has working data from the accounts of some users - how can you prevent him from logging in? A simple juxtaposition of characters from the sixties is not enough.
But the evolution of authentication does not boil down to an infinite expansion of the database for the injection of registration data - the process of entering the system has changed in many other respects. In some cases, this led to the fact that everything turned upside down, and those truths about creating and managing accounts, which were once considered to be capital, are no longer relevant. Nevertheless, we can see how some organizations today apply outdated schemes to modern threats. This post aims to analyze this discrepancy and explain how you really need to design this critical part of the system in our time. I hope someday it will become the resource where well-wishers will send companies that say: "We do this nonsense for the sake of security."
I will begin with references to other sources, because lately there have appeared many good materials on this topic on the Web, and I will turn to them. I want to put it all at once, to clarify one thing: most of the recommendations that will be cited below are not just my personal view of the problem, but direct quoting of organizations such as the National Institute of Standards and Technology (National Institute of Standards and Technologies, or NIST). In fact, their work Digital Identity Guidelines , which came out literally last month, perhaps, can be considered the push that prompted me to take up this post - there were so many interesting things there.
The National Cyber ​​Security Center (National Cyber ​​Security Center) of the UK government is another great resource I will use. They regularly publish very informative articles on security, and represent one of the rare examples of a government agency that really “understands” in the IT field.
I will also refer to the Microsoft's Password Guidance study from the Identity Protection team. Its first page says that Microsoft is in a “unique position to understand the role of passwords in the seizure of accounts,” thanks to the fact that it experiences 10 million attacks each day, so these guys have enough experience! This is a very practical guide, compiled by people who have clearly thought through how to secure their online accounts.
I am sure that there are other interesting materials, and I will be glad if you share your findings in the comments. Here I have listed only a few sources, further down the text you will find references to many others. Well, let's get started!
To begin with, we will look at the authentication process from a more philosophical point of view: until you are logged in, you do not have access to any of its components, then you go in and get access to everything that is registered in your rights. No gray area - either way or commercials.
One of the remarkable trends that we have seen in the information security sector lately is the differentiation of threat and trust levels, that is, the realization that in some scenarios involving potential risk (such as logging in), we feel more trust in the user, and in some - less. For example: instead of allowing a certain number of login attempts, say, five (did you notice that the number is for some reason always odd?), And then just block your account, you may need to add a step with entering a captcha after three. Thus, we show that the level of trust in the user has decreased and we have to take additional measures to make sure that the system is not subjected to an automated attack. For bots, this is a serious obstacle, and for users - a slight inconvenience, moreover, if necessary, you can still block your account after several unsuccessful attempts.
Continuing the thought, is it worth giving users access to all the features immediately upon a successful login? Suppose they did not correctly enter the password from the first time and came from a browser that they had not used before, and from another country - should they then provide unlimited access to everything? Or is it better to restrict yourself to the most basic functions and require proof that the specified address really belongs to the user before giving him the opportunity to perform some serious operations?
Using these simple examples, I try to lead readers to the idea that it is possible to act smarter than traditional binary systems, which still prevail in most services, allow. This topic will be developed in the text and beyond.
Now let's dive into the technical component and start with a simple one: what you see below is not the best policy for creating passwords.
The first sentence in the pop-up window (“Password length should be 8-10 characters”) is probably the most common of the erroneous anti-password patterns: a small specified password length. This kills the password managers (we’ll talk about them later), it kills passphrases and, as a result, it kills usability. Speaking of usability: I took the screenshot from my last year’s article on how we make mistakes in the most basic things , and, in addition to the ineffective Etihad policy (adopted, by the way, for the sake of security ), I describe the case when Paypal actually blocked my account access due to a policy of the same kind.
In addition to the problems voiced above, the low limit in length often inspires people to suspect that the storage of passwords is poorly organized. After cryptographic hashing, all stored passwords have the same fixed length, so such arbitrary restrictions can mean that passwords are stored in plain text and the column contains only ten characters. Of course, the reason may be different, but, you know, such assumptions are not unreasonable.
What then the length limit you need to put? “No” is the wrong answer, because beyond a certain boundary you will have other problems. For example, if the size exceeds four megabytes, you will not meet the default request size in ASP.NET . This is what NIST says about this:
Not a single normal person, registering on a website with a password limit of 64 characters, will say: “What a crap they have security for, I wasn’t even allowed to make a password longer than 64 characters”. But just in case you can set a limit of 100 characters. Or pick up the idea of ​​NIST, and set a maximum of 256 characters - what's the difference, anyway, after hashing everything is aligned.
NIST points to another important, though not so much moment on the surface:
These are, in fact, the most basic things: do not specify a small length and do not trim the final characters of the user-supplied password. At the worst, companies that protect the legitimacy of such practices should add: “We know that this is wrong, we have problems with heredity, we will add this to the list for urgent improvement.”
I want to consider two aspects of using special characters. I'll start with this:
Usually, some characters in passwords are prohibited. This rule is introduced to protect against possible attacks. Say, angle brackets can be used in XSS attacks, and apostrophes - when introducing SQL-code. But such arguments show that there are serious flaws in the site’s security profile. First of all, passwords can never be displayed on the interface due to cross-site scripting threat; secondly, passwords should not be sent to the database without hashing, after which only alphanumeric characters remain. And of course, even if you break these rules by displaying passwords in the interface and storing them in the database in plain text, you still have the encoding for the output and parameterization.
NIST is quite unequivocal about this - do not do this:
It is worth noting especially their reservation about Unicode characters - there were precedents when developers imposed a ban on quite acceptable from the point of view of language characters simply because they allegedly went beyond the "normal". On the other hand, of course, there are passwords like this:
Well, if someone wants to put the first verse “Let go and forget” from “Cold Heart” recorded with emoticons so please with a password - please!
Another aspect I wanted to touch on is also mentioned by NIST:
Wait, how so ?! That is, people do not need to include in the password uppercase, lowercase letters, numbers and symbols? This is so contrary to the generally accepted approach that you have to sit down and think over everything logically to understand that they are right. As an illustration: I recently wrote about how a system evaluating a password as “good” or “bad” encourages people to make wrong decisions . The basic premise was this: a purely mathematical approach does not help us invent good passwords. Such requirements allow passwords like “Password!” And cut passwords-phrases just because they do not contain capital letters.
In the document I mentioned above, Microsoft echoed recommendations from NIST:
If there are requirements for the complexity of the password, the situation usually unfolds as follows: people first try to enter something primitive, and then correct the characters until they turn on the minimum of the required components. Microsoft reveals this problem like this:
As a result, the password will still be bad, and most likely the user has already used it somewhere before. All that can be achieved with these measures is to pull the nerves of the user without any result!
According to my personal observations, now tips are far from being as popular as they once were. This idea took the beginning in “listen, people constantly forget passwords, let's help them remember!” And resulted in the fact that when creating an account, the user was able to enter not only the password, but also a hint to it. The problem is that this prompt will be shown to unauthorized users - because only at this stage it is needed. Another problem is that this information is entered by the user and, accordingly, the horror will most likely be complete.
Adobe has stored password hints in its database, which was made publicly available in 2013. To demonstrate how bad everything is, I looked through this database and decided to share individual examples:
They were all stored as plain text, so you can imagine what happened when the system was hacked. It's clear why NIST thinks it's a bad idea:
As I said before, now you’ll see prompts and so rarely in online systems, but just in case you thought about something like that - don’t think it over!
I have long been arguing about the value of password managers in me - from the beginning of 2011, when I wrote in one of the articles that the only reliable password is one that you don’t know by heart . The idea is simple and you can literally put it in several points:
Now, someone will argue that using a password manager means collecting everything in one place, and it will be right: if someone penetrates this place, you will be in big trouble. But this is a very rare phenomenon in comparison with the cases of hacking of individual services and the subsequent leakage of these accounts. Moreover, as I recently said, password managers do not have to be perfect, it’s enough that they are better off with them than without them .
But this post was not written as a guide for users to create good passwords, it is intended for those who create services. Accordingly, no matter how you personally treat password managers, you should not do this:
Good day! We do not recommend using a password manager, your device may be hacked.
Such myopia is common, I can immediately find a dozen such tweets. They generally do not take into account the three points that I touched above, and actually say something like the following: “Hey, create easy-to-remember passwords, they, of course, will be weak and, most likely, you will repeat them from account to account, but it is necessary for the sake of safety. ”
NCSC direct text speaks about this problem: in the infographics for the Password Guidance: Simplifying Your Approach guide, they have this snippet:
Create secure passwords for users
In other words, do not break the password managers and do not make such statements as in the above tweet. But NCSC goes even further and offers the following recommendation, obviously with the intention that organizations give their employees the ability to create and manage passwords without risking security:
Think about the situation in which you are working at the moment. Are there any criteria for password security? Are annual trainings conducted, or maybe posters hanging on the walls calling for the creation of unique, complex passwords? Of course, some kind of control and instruction related to passwords is definitely present, but do you provide an “authorized mechanism” that would help you achieve your goals? Most likely not, and I speak about it with such confidence because I often ask this question when I conduct trainings in various organizations. It's amazing how often you see such inconsistencies.
The use of a password manager is closely related to the ability to insert passwords in the input field. There are many password managers who fill in the fields automatically, but there are also cases when you still have to use an insert or the service blocks attempts to enter a password not manually (this is easy to verify using JavaScript). The result is the following:
In 2014, I wrote about the “cobra effect” , which occurs when insertion is prohibited in the password field. I explain in detail the meaning of this term in the article by reference, but if to summarize briefly: the effect of the cobra manifests itself when an attempt to solve the problem only aggravates it. When the site blocks the ability to insert a password to ensure security, it forces some users to simplify passwords until they become so primitive that it is not difficult to print them.
NCSC support me here too:
They even introduced a special term for this anti-pattern - SPP (Stop Pasting Passwords, Stop Passing Passwords) and debunk the popular myths about the risks associated with pasting passwords. They also mention my article, where they spoke about the effect of the cobra - it is nice to receive such a patronage from the British government!
NIST joins the NCSC position, as evidenced by their statement:
So do not even hesitate: people on both sides of the Atlantic Ocean unanimously support the use of password managers and oppose active actions to block them.
In my previous work in a private company, I came up with an easy way to calculate how much I already use my current password: I just took the number it contained and which I increased once a quarter when the company required to change the password, and divided it into four. Thus, I stretched a single password for almost six years, changing no more than a couple of characters in it each time. If you also have to change passwords regularly at work, you are probably doing the same - this is an easy and natural way out when faced with a technical requirement that causes inconvenience.
Let's analyze the rationale for this approach: the argument for periodically updating passwords is that if the password falls into the wrong hands, it will become irrelevant after a forced replacement, which means fraudsters will not be able to use it. The problem here is that in my example, hackers had up to three months time, and in other cases, perhaps more:
If you think so, hackers usually do not wait idly, they immediately take up work with accounts, trying to derive benefit from them. The Lifeboat team did not take this consideration into account in their attempts to mitigate the effects of last year’s data leakage, and the chain of reasoning turned out to be incorrect:
As mentioned in the above tweet, the NCSC shares the view that today forced passwords are anti-patterns in information security. Here is what they say about this practice in their password management guide :
They bring this idea to infographic:
Ask users to change the password only if there are signs or suspicions that the old password has been compromised.
Microsoft speaks the same way:
Their words, of course, should not be understood as “do not force users to change passwords, and nothing more is required of you”. It is rather an indication that a broader, more advanced approach to password management is needed. For example, NCSC also provides such recommendations:
And here we smoothly proceed to the next section.
This is an important aspect of the “advanced” approach to the authentication process and it is quite possible that you have already observed it in action. Recently, I logged into my Yammer account with my new Lenovo Yoga 910 - until that moment I did not use their service on this machine. A little later, I received this notification:
Later, I went to Dropbox via a browser on the same machine and immediately received the message:
Of course, these letters did not prevent me from logging into the system and, of course, in my place there could be an attacker who obtained the details of the victim's access. But they immediately notified me of what happened, and this is of tremendous value - based on this information, I could, if necessary, go and drive out the one who invaded my account. Dropbox even showed me all the devices that I have authorized over the past five years, and provided the opportunity to cancel the authorization.
The ability to track account behavior in this way is very useful; for example, you can look at what devices are currently logged in to my Facebook account.
As in the case of Dropbox and Yammer, there is also an option to log out on any device from the list. , - , - . ; — Github, , IP , , , .
:
, , , . , .
, , , , .
. - , «» — , . . , , , , . : e-mail -, , :
NIST :
: - , , , . , , , , — , , . , «, ». , CloudPets , , - bcrypt , «cloudpets». , — !
, . , , , — , , NIST . , , , (, ) — , .
1% Dropbox ( )
, — . : , , , ? , , ? , , , , ? , Cloudpet, ?
, , . , Password Storage Cheat Sheet OWASP . , Dropbox — , .
, . , , , , , .
, IT-: , . , , , . , , , , , ( ), , , , .
: – , . , . - , . , , . , , . !
However, the ecosystems in which they functioned were also simple — say, a time-sharing system from MTI , which is considered the first computer system where passwords were used.
')
But this situation has developed in the sixties of the last century, and since then much water has flowed under the bridge. Up until the last couple of decades, we had a very small number of accounts with a limited number of connections, which made the spectrum of threats rather narrow. Only those who were in the immediate vicinity could harm you - that is, people who were able to directly, physically gain access to the system. Over time, they were joined by remote users who could connect via the phone, and the range of threats expanded. What happened after that, you yourself know: more interconnections, more accounts, more intruders and more data leaks, especially in recent years. The original scheme with a simple reconciliation of characters no longer seems such a brilliant idea.
A couple of months ago, I wrote about the reusable use of passwords, the stuffing of registration data and that another billion entries were added to the Have I been pwned service database . Things are like this: billions of access details are lying and waiting for some villain to start using them to hack into any site he likes. This poses a very interesting question for us: how to protect yourself in such circumstances? I mean, are you trying to keep the online system afloat, and some type of party has working data from the accounts of some users - how can you prevent him from logging in? A simple juxtaposition of characters from the sixties is not enough.
But the evolution of authentication does not boil down to an infinite expansion of the database for the injection of registration data - the process of entering the system has changed in many other respects. In some cases, this led to the fact that everything turned upside down, and those truths about creating and managing accounts, which were once considered to be capital, are no longer relevant. Nevertheless, we can see how some organizations today apply outdated schemes to modern threats. This post aims to analyze this discrepancy and explain how you really need to design this critical part of the system in our time. I hope someday it will become the resource where well-wishers will send companies that say: "We do this nonsense for the sake of security."
Listen to what the government says (and smart IT companies)
I will begin with references to other sources, because lately there have appeared many good materials on this topic on the Web, and I will turn to them. I want to put it all at once, to clarify one thing: most of the recommendations that will be cited below are not just my personal view of the problem, but direct quoting of organizations such as the National Institute of Standards and Technology (National Institute of Standards and Technologies, or NIST). In fact, their work Digital Identity Guidelines , which came out literally last month, perhaps, can be considered the push that prompted me to take up this post - there were so many interesting things there.
The National Cyber ​​Security Center (National Cyber ​​Security Center) of the UK government is another great resource I will use. They regularly publish very informative articles on security, and represent one of the rare examples of a government agency that really “understands” in the IT field.
I will also refer to the Microsoft's Password Guidance study from the Identity Protection team. Its first page says that Microsoft is in a “unique position to understand the role of passwords in the seizure of accounts,” thanks to the fact that it experiences 10 million attacks each day, so these guys have enough experience! This is a very practical guide, compiled by people who have clearly thought through how to secure their online accounts.
I am sure that there are other interesting materials, and I will be glad if you share your findings in the comments. Here I have listed only a few sources, further down the text you will find references to many others. Well, let's get started!
The authentication process should not be reduced to switching between two states.
To begin with, we will look at the authentication process from a more philosophical point of view: until you are logged in, you do not have access to any of its components, then you go in and get access to everything that is registered in your rights. No gray area - either way or commercials.
One of the remarkable trends that we have seen in the information security sector lately is the differentiation of threat and trust levels, that is, the realization that in some scenarios involving potential risk (such as logging in), we feel more trust in the user, and in some - less. For example: instead of allowing a certain number of login attempts, say, five (did you notice that the number is for some reason always odd?), And then just block your account, you may need to add a step with entering a captcha after three. Thus, we show that the level of trust in the user has decreased and we have to take additional measures to make sure that the system is not subjected to an automated attack. For bots, this is a serious obstacle, and for users - a slight inconvenience, moreover, if necessary, you can still block your account after several unsuccessful attempts.
Continuing the thought, is it worth giving users access to all the features immediately upon a successful login? Suppose they did not correctly enter the password from the first time and came from a browser that they had not used before, and from another country - should they then provide unlimited access to everything? Or is it better to restrict yourself to the most basic functions and require proof that the specified address really belongs to the user before giving him the opportunity to perform some serious operations?
Using these simple examples, I try to lead readers to the idea that it is possible to act smarter than traditional binary systems, which still prevail in most services, allow. This topic will be developed in the text and beyond.
The longer the better (usually)
Now let's dive into the technical component and start with a simple one: what you see below is not the best policy for creating passwords.
The first sentence in the pop-up window (“Password length should be 8-10 characters”) is probably the most common of the erroneous anti-password patterns: a small specified password length. This kills the password managers (we’ll talk about them later), it kills passphrases and, as a result, it kills usability. Speaking of usability: I took the screenshot from my last year’s article on how we make mistakes in the most basic things , and, in addition to the ineffective Etihad policy (adopted, by the way, for the sake of security ), I describe the case when Paypal actually blocked my account access due to a policy of the same kind.
In addition to the problems voiced above, the low limit in length often inspires people to suspect that the storage of passwords is poorly organized. After cryptographic hashing, all stored passwords have the same fixed length, so such arbitrary restrictions can mean that passwords are stored in plain text and the column contains only ten characters. Of course, the reason may be different, but, you know, such assumptions are not unreasonable.
What then the length limit you need to put? “No” is the wrong answer, because beyond a certain boundary you will have other problems. For example, if the size exceeds four megabytes, you will not meet the default request size in ASP.NET . This is what NIST says about this:
Verifiers should allow entry of any secret code of up to 64 characters to the choice of the subscriber.
Not a single normal person, registering on a website with a password limit of 64 characters, will say: “What a crap they have security for, I wasn’t even allowed to make a password longer than 64 characters”. But just in case you can set a limit of 100 characters. Or pick up the idea of ​​NIST, and set a maximum of 256 characters - what's the difference, anyway, after hashing everything is aligned.
NIST points to another important, though not so much moment on the surface:
Truncation of the secret code is not allowed.
These are, in fact, the most basic things: do not specify a small length and do not trim the final characters of the user-supplied password. At the worst, companies that protect the legitimacy of such practices should add: “We know that this is wrong, we have problems with heredity, we will add this to the list for urgent improvement.”
All characters are special (but not necessarily include them)
I want to consider two aspects of using special characters. I'll start with this:
Usually, some characters in passwords are prohibited. This rule is introduced to protect against possible attacks. Say, angle brackets can be used in XSS attacks, and apostrophes - when introducing SQL-code. But such arguments show that there are serious flaws in the site’s security profile. First of all, passwords can never be displayed on the interface due to cross-site scripting threat; secondly, passwords should not be sent to the database without hashing, after which only alphanumeric characters remain. And of course, even if you break these rules by displaying passwords in the interface and storing them in the database in plain text, you still have the encoding for the output and parameterization.
NIST is quite unequivocal about this - do not do this:
Secret codes should allow the use of any printable ASCII characters [RFC 20], including the space. Unicode characters [ISO / ISC 10646] should also be accepted .
It is worth noting especially their reservation about Unicode characters - there were precedents when developers imposed a ban on quite acceptable from the point of view of language characters simply because they allegedly went beyond the "normal". On the other hand, of course, there are passwords like this:
Well, if someone wants to put the first verse “Let go and forget” from “Cold Heart” recorded with emoticons so please with a password - please!
Another aspect I wanted to touch on is also mentioned by NIST:
Verifiers should not introduce additional rules for composing a secret code (for example, require the use of different types of characters or prohibit entering the same characters in a row) .
Wait, how so ?! That is, people do not need to include in the password uppercase, lowercase letters, numbers and symbols? This is so contrary to the generally accepted approach that you have to sit down and think over everything logically to understand that they are right. As an illustration: I recently wrote about how a system evaluating a password as “good” or “bad” encourages people to make wrong decisions . The basic premise was this: a purely mathematical approach does not help us invent good passwords. Such requirements allow passwords like “Password!” And cut passwords-phrases just because they do not contain capital letters.
In the document I mentioned above, Microsoft echoed recommendations from NIST:
Discard the requirements for the composition of the password.
If there are requirements for the complexity of the password, the situation usually unfolds as follows: people first try to enter something primitive, and then correct the characters until they turn on the minimum of the required components. Microsoft reveals this problem like this:
For the most part, people resort to the same patterns (the first letter is a capital letter, a special character, or two numbers at the end). Cyber ​​fraudsters know this, therefore, performing a dictionary search, they include all substitutions made according to standard schemes (“$” instead of “s”, “@” instead of “a”, “1” instead of “l” and so on) .
As a result, the password will still be bad, and most likely the user has already used it somewhere before. All that can be achieved with these measures is to pull the nerves of the user without any result!
Tips? In no case!
According to my personal observations, now tips are far from being as popular as they once were. This idea took the beginning in “listen, people constantly forget passwords, let's help them remember!” And resulted in the fact that when creating an account, the user was able to enter not only the password, but also a hint to it. The problem is that this prompt will be shown to unauthorized users - because only at this stage it is needed. Another problem is that this information is entered by the user and, accordingly, the horror will most likely be complete.
Adobe has stored password hints in its database, which was made publicly available in 2013. To demonstrate how bad everything is, I looked through this database and decided to share individual examples:
- my name
- adobe
- as usual
- password
They were all stored as plain text, so you can imagine what happened when the system was hacked. It's clear why NIST thinks it's a bad idea:
Secret code verifiers should not allow subscribers to leave a “hint” that will be available to an unauthorized person when they try to log in.
As I said before, now you’ll see prompts and so rarely in online systems, but just in case you thought about something like that - don’t think it over!
Love password managers
I have long been arguing about the value of password managers in me - from the beginning of 2011, when I wrote in one of the articles that the only reliable password is one that you don’t know by heart . The idea is simple and you can literally put it in several points:
- We know that passwords must be “strong”, that is, they must be difficult to guess or calculate by brute force. In other words, the more characters and the more random they are selected, the better.
- We know that it’s impossible to use one password several times: if one service is hacked, then user accounts on other resources will be at risk. The problem with stuffing credentials, which I mentioned above, is just that.
- People cannot invent and learn reliable, unique passwords for each service, relying only on their memory.
Now, someone will argue that using a password manager means collecting everything in one place, and it will be right: if someone penetrates this place, you will be in big trouble. But this is a very rare phenomenon in comparison with the cases of hacking of individual services and the subsequent leakage of these accounts. Moreover, as I recently said, password managers do not have to be perfect, it’s enough that they are better off with them than without them .
But this post was not written as a guide for users to create good passwords, it is intended for those who create services. Accordingly, no matter how you personally treat password managers, you should not do this:
Good day! We do not recommend using a password manager, your device may be hacked.
Such myopia is common, I can immediately find a dozen such tweets. They generally do not take into account the three points that I touched above, and actually say something like the following: “Hey, create easy-to-remember passwords, they, of course, will be weak and, most likely, you will repeat them from account to account, but it is necessary for the sake of safety. ”
NCSC direct text speaks about this problem: in the infographics for the Password Guidance: Simplifying Your Approach guide, they have this snippet:
Create secure passwords for users
In other words, do not break the password managers and do not make such statements as in the above tweet. But NCSC goes even further and offers the following recommendation, obviously with the intention that organizations give their employees the ability to create and manage passwords without risking security:
You must also provide appropriate password storage equipment with a level of protection appropriate to the confidentiality of the information you seek to protect. These storages can be either material (for example, safes) or technical (for example, special programs for managing passwords) or combine aspects of both. It is imperative that your organization provides an authorized mechanism to help users exercise control over passwords: this will save them from having to resort to unreliable "hidden" methods to cope with the abundance of passwords.
Think about the situation in which you are working at the moment. Are there any criteria for password security? Are annual trainings conducted, or maybe posters hanging on the walls calling for the creation of unique, complex passwords? Of course, some kind of control and instruction related to passwords is definitely present, but do you provide an “authorized mechanism” that would help you achieve your goals? Most likely not, and I speak about it with such confidence because I often ask this question when I conduct trainings in various organizations. It's amazing how often you see such inconsistencies.
Let them in passwords
The use of a password manager is closely related to the ability to insert passwords in the input field. There are many password managers who fill in the fields automatically, but there are also cases when you still have to use an insert or the service blocks attempts to enter a password not manually (this is easy to verify using JavaScript). The result is the following:
In 2014, I wrote about the “cobra effect” , which occurs when insertion is prohibited in the password field. I explain in detail the meaning of this term in the article by reference, but if to summarize briefly: the effect of the cobra manifests itself when an attempt to solve the problem only aggravates it. When the site blocks the ability to insert a password to ensure security, it forces some users to simplify passwords until they become so primitive that it is not difficult to print them.
NCSC support me here too:
They even introduced a special term for this anti-pattern - SPP (Stop Pasting Passwords, Stop Passing Passwords) and debunk the popular myths about the risks associated with pasting passwords. They also mention my article, where they spoke about the effect of the cobra - it is nice to receive such a patronage from the British government!
NIST joins the NCSC position, as evidenced by their statement:
Verifiers should allow a person undergoing authorization to use the insert function when entering a secret code. This facilitates the use of password managers, which are widespread and in many cases encourage users to create more complex secret codes.
So do not even hesitate: people on both sides of the Atlantic Ocean unanimously support the use of password managers and oppose active actions to block them.
Do not ask for a regular password change.
In my previous work in a private company, I came up with an easy way to calculate how much I already use my current password: I just took the number it contained and which I increased once a quarter when the company required to change the password, and divided it into four. Thus, I stretched a single password for almost six years, changing no more than a couple of characters in it each time. If you also have to change passwords regularly at work, you are probably doing the same - this is an easy and natural way out when faced with a technical requirement that causes inconvenience.
Let's analyze the rationale for this approach: the argument for periodically updating passwords is that if the password falls into the wrong hands, it will become irrelevant after a forced replacement, which means fraudsters will not be able to use it. The problem here is that in my example, hackers had up to three months time, and in other cases, perhaps more:
If you think so, hackers usually do not wait idly, they immediately take up work with accounts, trying to derive benefit from them. The Lifeboat team did not take this consideration into account in their attempts to mitigate the effects of last year’s data leakage, and the chain of reasoning turned out to be incorrect:
After what happened in January, we decided that the best course of action was to quietly replace all the passwords so that hackers did not know that they have little time left to implement their plans.
As mentioned in the above tweet, the NCSC shares the view that today forced passwords are anti-patterns in information security. Here is what they say about this practice in their password management guide :
[it] does not bring any real benefit, since hacked passwords are usually used immediately.
They bring this idea to infographic:
Ask users to change the password only if there are signs or suspicions that the old password has been compromised.
Microsoft speaks the same way:
The password expiration policy does more harm than good because it pushes users to create highly predictable passwords from consecutive numbers and words that are closely related to each other (as a result, each subsequent password is easy to guess based on the previous one). As for risk reduction, changing the password does not play a big role here either, since cyber-crooks in most cases use the details immediately as they get access to them.
Their words, of course, should not be understood as “do not force users to change passwords, and nothing more is required of you”. It is rather an indication that a broader, more advanced approach to password management is needed. For example, NCSC also provides such recommendations:
- Track all authorization cases to detect unusual behavior.
- Give users details of login attempts, no matter if they were successful or unsuccessful. In turn, users should notify you if any of these attempts did not come from them.
And here we smoothly proceed to the next section.
Inform users about atypical behavior
This is an important aspect of the “advanced” approach to the authentication process and it is quite possible that you have already observed it in action. Recently, I logged into my Yammer account with my new Lenovo Yoga 910 - until that moment I did not use their service on this machine. A little later, I received this notification:
Later, I went to Dropbox via a browser on the same machine and immediately received the message:
Of course, these letters did not prevent me from logging into the system and, of course, in my place there could be an attacker who obtained the details of the victim's access. But they immediately notified me of what happened, and this is of tremendous value - based on this information, I could, if necessary, go and drive out the one who invaded my account. Dropbox even showed me all the devices that I have authorized over the past five years, and provided the opportunity to cancel the authorization.
The ability to track account behavior in this way is very useful; for example, you can look at what devices are currently logged in to my Facebook account.
As in the case of Dropbox and Yammer, there is also an option to log out on any device from the list. , - , - . ; — Github, , IP , , , .
:
, , , . , .
, , , , .
. - , «» — , . . , , , , . : e-mail -, , :
NIST :
, , . , , , .
: - , , , . , , , , — , , . , «, ». , CloudPets , , - bcrypt , «cloudpets». , — !
, . , , , — , , NIST . , , , (, ) — , .
1% Dropbox ( )
, — . : , , , ? , , ? , , , , ? , Cloudpet, ?
, , . , Password Storage Cheat Sheet OWASP . , Dropbox — , .
, . , , , , , .
, IT-: , . , , , . , , , , , ( ), , , , .
: – , . , . - , . , , . , , . !
Source: https://habr.com/ru/post/334600/
All Articles