MIT course "Computer Systems Security". Lecture 17: User Authentication, Part 2

Massachusetts Institute of Technology. Lecture course # 6.858. "Security of computer systems". Nikolai Zeldovich, James Mykens. year 2014

Computer Systems Security is a course on the development and implementation of secure computer systems. Lectures cover threat models, attacks that compromise security, and security methods based on the latest scientific work. Topics include operating system (OS) security, capabilities, information flow control, language security, network protocols, hardware protection and security in web applications.

Lecture 1: “Introduction: threat models” Part 1 / Part 2 / Part 3
Lecture 2: “Controlling hacker attacks” Part 1 / Part 2 / Part 3
Lecture 3: “Buffer overflow: exploits and protection” Part 1 /Part 2 / Part 3
Lecture 4: “Privilege Separation” Part 1 / Part 2 / Part 3
Lecture 5: “Where Security System Errors Come From” Part 1 / Part 2
Lecture 6: “Capabilities” Part 1 / Part 2 / Part 3
Lecture 7: “Native Client Sandbox” Part 1 / Part 2 / Part 3
Lecture 8: “Network Security Model” Part 1 / Part 2 / Part 3
Lecture 9: “Web Application Security” Part 1 / Part 2/ Part 3
Lecture 10: “Symbolic execution” Part 1 / Part 2 / Part 3
Lecture 11: “Ur / Web programming language” Part 1 / Part 2 / Part 3
Lecture 12: “Network security” Part 1 / Part 2 / Part 3
Lecture 13: “Network Protocols” Part 1 / Part 2 / Part 3
Lecture 14: “SSL and HTTPS” Part 1 / Part 2 / Part 3
Lecture 15: “Medical Software” Part 1 / Part 2/ Part 3
Lecture 16: "Attacks through the side channel" Part 1 / Part 2 / Part 3
Lecture 17: "User authentication" Part 1 / Part 2 / Part 3

One of the interesting things mentioned in this article is that if you go through all these authentication schemes, the authors say: “OK, here are the passwords, they seem to suck, and there are other things that provide much better security , but they often fail to deploy, are inconvenient to use, and the like. ”



This is an interesting and at the same time distressing result of this work, which consists in the fact that even if we have all these tools that provide higher security for the protocols, we cannot use them because of the extreme inconvenience.

So Telepathwords is just a fun site, they claim that they do not store your passwords, so you can take their word for it if you want. But it’s very interesting to just sit down and think about how good the password I came up with? And then enter it here and see how easy it is to guess. It even allows you to do such things as heuristic analysis of popular phrases from several words, of which only the first letter of each word is selected for a password. So this thing is very useful.

Another interesting thing is that your passwords can be guessed offline. This vulnerability, called preauth, or "pre-authentication", was inherent in Kerberos v4 and v5. Anyone could ask the KDC for a ticket that was encrypted with the user's password.

Thus, the KDC did not verify the authenticity of requests from the client. The KDC returned, in response to a request, a set of several bits that was encrypted with the client key. This is what was returned to the client. The problem was that the server did not check who sent this encrypted set of things, so in principle, the attacker could get this thing, and then try to just guess what K_C is.



Just try to guess the value of K_C, try to encrypt it, see if it looks like, if not, try guessing another K_C, decrypt, see if it looks like the truth, and so on. The reason for allowing an attacker to organize this type of attack is that this thing here, inside the brackets, this TGT actually has a known format. There is something like timestamps and internal consistent reference fields, and all this helps the attacker to solve the password. Because if an attacker guesses K_C and receives the decoded contents of the brackets, but the internal fields are not checked, the attacker understands that he chose the wrong K_C and is taken for the next one.

In Kerberos version 5, the client must pass a time stamp to the KDC, after which this tag will be encrypted using K_C. All this is sent to the server, the server looks at this request and checks it before sending something to the client. So any random client can come and just ask for this item from the server.

Student: does the timestamp appear in the message? Couldn't an attacker just pick up and hack this message using the brute-force method?

Professor: let's see. Can an attacker get this message {time stapm} K_C?

Student: Yes, this is an encrypted message.



Professor: so you think that an attacker could, for example, just fake this message?

Student:no, he would use brute-force to match K_C.

Professor: I see, in other words, you are worried that someone can peep the contents of these brackets. I believe that the content is inside the encrypted thing that belongs to the server, or to the key that belongs to the server, precisely in order to prevent such an attack, but this is just my opinion. But in general, you are right, if the attacker manages to find out the timestamp in the client's request, it will be of great benefit to him. In this case, he can guess in which range neighboring time marks can be, and use this for a similar attack.

Student: in this case, the attacker must be a "man in the middle."
Professor:so, the attacker must be somewhere on the network between the client and the server in order to “sniff out” such things.

Another important thing concerns password recovery. The point is that if you lose your password, you must go to the office and ask for another password. But before you get this password, you must somehow prove that you are you.

So how does it work? How can I recover my password? Interestingly, people often focus on the entropy of the password itself. But the problem is that if the questions used to recover the password, or the password recovery scheme has little entropy, it affects the entropy of the overall authentication scheme. In other words, the strength of the general authentication scheme is equal to the minimum password entropy and the minimum question entropy for password recovery. There are many scenarios and rules, there are enough well-known cases, such as the case of Sarah Palin. Someone was able to recover her password fraudulently, because her password recovery questions were such that any stranger could find an answer to them, for example, by reading a Wikipedia article about her that said which school she went to and etc.



So often these password recovery questions are not good enough for several reasons. Sometimes these things just have very low entropy. For example, if your password recovery question is “what's your favorite color”, then the most popular answers are “blue” and “red”. No one will answer "white", "fuchsia" or "purple". Thus, some of these issues for restoration are inherently unable to provide quite a lot of entropy.

Another problem is that sometimes answers to password recovery questions may leak through social networks. For example, if one of the password recovery questions is “what's your favorite movie”, then there is a lot more guessing space, for example, I can view your profile on IMDB or Facebook and find the name of your favorite movie that you suggested to me .

And one more problem, the most ridiculous, is that the users themselves come up with very weak recovery questions, for example, what will be 2 plus 3? That is, the user thinks that it will be a big problem for someone to give the correct answer to such questions, but most people who pass the Turing test can successfully answer them and use your password.



Student:Is it possible to use some additional information instead of questions for password recovery, just as we insert our name into the email or briefly describe the content of the letter in the header - can this approach ensure the security of such things?

Professor:I do not know of any such research, but in fact these things are much better. I know this because I was trying to help my girlfriend go through this process. She lost control of her Gmail account and tried to prove that this was her account. And the site owners asked her about things like, for example, when exactly she created her account, if she talked to someone about her account, for example, with Hezbollah, before losing control of it, and the like. In fact, this is quite a laborious process, but in the end, additional information is more powerful than questions for password recovery. I do not know any official research on this topic, but it seems that this is obvious.

If you have no questions, we can proceed to the topic of today's lecture described in the article. So, the authors propose to consider a bunch of factors that can be used to assess the effectiveness of authentication schemes. What is really cool about this article is that it says that most of us in the security community fight only for aesthetic principles. For example, "we have to choose this, because I just like the way the curly brackets look in evidence", or "we have to choose it, because many mathematical methods are used here."

They say, why don't we try to establish some kind of performance evaluation criteria? Maybe some of these criteria will be a bit subjective, but let's just try to systematize ways to evaluate authentication schemes. Let's just see how these different schemes are arranged in separate piles.

The authors of the article proposed three high-level parameters for evaluating these schemes. The first parameter is usability. The first requirement in this parameter is the ease of learning the authentication method. Its main idea is how easy it is for users to interact with the authentication scheme. Here they mark a couple of characteristic features, for example, is it easy to learn this method, and is this method of identifying a user’s identity easy to learn.

Some of these categories are fairly simple, some include some tricks, but there is a lot of sense to it. If you look at the passwords, they meet this requirement, because everyone is used to using passwords, so we will say that it is easy to learn how to use them, and the answer is yes.

The second requirement is the rarity of authentication errors. This means that if you are an actual user of the system, then there should be no error when attempting to authenticate you. And here, with respect to passwords, the authors say that they conditionally correspond to this parameter. “Conventionally” in this case means that the authors recognize the presence of subjectivity in their assessment. Thus, to the question of whether password authentication errors rarely occur, we cannot definitely answer neither yes nor no.

As a rule, you can authenticate yourself, but for example, when you try to access the mail server at 3 o'clock in the morning, weakly thinking about it, and enter the wrong password several times, in this case you can recognize the authentication system error. Therefore, they believe that passwords conditionally meet this requirement.

The next requirement is user scalability. The basic idea here is that if a user has a bunch of different services in which he or she wants to authenticate himself, does this scheme scale well? Should the user memorize something new for each of the schemes? Here, with respect to passwords, the authors unequivocally say “no”, since password authentication does not satisfy this requirement. Because in practice it is very difficult for users to remember a separate password for each site they visit. In fact, this is one of the reasons why people often use the same password for authentication in different services.

Another requirement for ease of use is ease of recovery. That is, what happens if you lose the authentication token, in this case your password, will it be easy to reset it? In this case, the answer for passwords is yes. In fact, it is even too easy to reset them, as we discussed a few minutes ago.

The next requirement is to not require anything extra, not to carry with you any additional means for authentication. For example, elaborate authentication protocols require that you run some kind of smartphone application, or have some sort of security token, smart cards, and the like with you. So this is a heavy burden. Maybe there are not so many problems with a smartphone, it is enough to install an application for authentication, but it is rather inconvenient to carry around one of the other gadgets. Therefore, a good quality of passwords is that you have to carry it with you only in your brain, which you should always have with you.



These are the criteria for usability of the authentication scheme. In a general sense, it is of interest how the security community people differ in their assessments of the importance of these criteria. For example, they say: "this thing uses a million pieces of entropy, and only a universal catastrophe can crack it," while forgetting that the above requirements are also essential for authentication schemes.

So, the next high-level parameter that the authors of the article use to evaluate the authentication scheme is deployability. It describes how easy it is to implement this authentication system in existing network services. For example, they look at server compatibility, that is, is it easy to integrate this scheme into modern servers, in which authentication is based on the use of text passwords? In this sense, passwords fully comply with this requirement, so we can answer “yes”.

The second requirement is browser compatibility, it looks like the previous one and says, can I use this authentication scheme for existing popular browsers without having to install a plugin or something like that? Again, here passwords win by default.

Another interesting requirement is accessibility, excessibility. That is, can people with some physical disabilities, for example, blind or hard of hearing, with insufficient motor skills, etc., be able to use this authentication scheme? In fact, this is quite an important requirement.

Here, the authors once again say "yes", which is a bit strange, because it is not clear how people with disabilities will be able to use passwords, but the authors say they can.



These are the requirements that should be considered in relation to the ability to deploy this authentication scheme. The reason for the particular importance of the deployment capability is that it is extremely difficult to upgrade all of these things in order to implement a new scheme, because it can be difficult for people to force something to update. I mean that often people don’t even want to reboot their machines and install a new OS update. Therefore, there are great difficulties if the authentication scheme requires changes on the server that force people serving the server to perform any additional operations. This is related to your question, why don't we use any additional information or improve password strength. The characteristic of deployability is in many cases very, very important for people.

So, the last parameter that we will consider is security, security. What types of attacks can this scheme prevent? I will refer to this characteristic in abbreviated form Res - adaptability to foo, where foo is any impact that could cause harm.

For example, the first characteristic indicates the stability of the system to physical observation, “peeping” or “eavesdropping”. The point is that the attacker could not impersonate this user after several times observe his authentication in the system. Imagine that you are in a computer class, and someone is behind you and watching what you are typing. Maybe someone is shooting you on video, maybe someone has a microphone that “takes off” the acoustic signature of your keyboard and tries to extract something from it, and so on and so forth.

The authors of the article say that passwords do not meet this requirement, because an attacker can view the video and quite easily find out which letters you typed. There are attacks that use acoustic fingerprints on the keyboard to determine printable characters. So passwords are not resistant to physical observations.

The next requirement is resistance to the target of impersonation for a stranger, or resistance to target impersonation. The basic idea here is that someone - your friend, acquaintance, spouse, lover can impersonate you, using your knowledge of who you are and what you do. The authors of the article write that passwords conditionally correspond to this requirement, because they are not aware of any studies showing that if you know a person, then you will most likely be able to guess his password. Therefore, they say "conditionally - yes."
Please note that there is a deliberate impersonation, in which protection with password recovery questions fails miserably, because if someone knows something about you, in many cases he will quite easily guess your security questions.

This is followed by two requirements for guessing. The first is resistance to intense guessing. This means that the attacker will not be able to guess at the speed of data transmission over the network, for example, using Antihammering protection. In this sense, passwords are insecure, as they are easily exposed to brute-force guessing, and the authors of the article say no. The reason why they say “no” is that in practice, passwords not only have a low entropy of inheritance, because they are not so long, but also distorted in distribution. Therefore, with a rather intensive search of values, an attacker easily guesses the passwords of many users.

Another requirement is resistance to non-intensive guessing. Suppose an attacker can issue an authentication verification request as quickly as he wants. In other words, an attacker is limited only by the speed of his equipment. And here the authentication scheme using passwords also does not meet the requirement, and the authors say "no" for the same reason as in the previous case.

Thus, passwords mostly have a very small entropy space and an asymmetric distribution, so everything is simple.

The next requirement is resistance to internal observation. This means that the attacker will not be able to impersonate the user by installing a keyboard interceptor on the client machine, fixing a set of each character, and also means that there is no possibility for the attacker to spy on the data that the client sends over the network in order to then impersonate user In this case, passwords also do not meet the requirements, because they are static tokens, they do not change, and static tokens are usually vulnerable to replay.

So if an attacker somehow installs a keyboard interceptor and obtains a password, he can use this password until it expires or it is revoked. He can use it again and again to access the server. So passwords do not pass this test.

The next requirement, which we talked a little about in the classroom, is phishing resistance. Phishing resistance is another indicator of security. Here, the basic idea is that an attacker can imitate a valid service, for example, attacking the DNS infrastructure or something like that, if he cannot get the authentication data directly from the user in order to pretend to be this user. Here, mostly fake websites are used that directly tell the user: “Hey, I’m exactly the service you need, so you can feel confident and give me your credentials.” Passwords also do not pass this check, because phishing sites are very popular and they are not able to protect the user from them.



The following two requirements are of interest from the point of view of system scaling. The first is: no trust in a third party. Essentially, this means that no one should participate in the authentication protocol except the client and the server. It also means that there can be no third party that, if compromised, could compromise the security of the entire authentication system. In fact, this is an interesting property, because it would be possible to avoid many problems of authentication, if we could store all our information for authentication in one place.

We just store it in one place, it’s very simple, because we don’t need to remember a lot of customer information, and we always say that any service you want to use is always located at a third party and you have to contact it . This third party will always be able to authenticate you and only then allow you to follow in the direction you need. Of course, the presence of a third party is problematic from the point of view of reliability, because if you access one of these global third parties that everyone trusts and it is compromised, then all sites that use it for authentication will potentially be in danger.

Therefore, the authors of the article believe that passwords meet this requirement, since they do not use third-party trust, because each site has its own separate password.

A third property has a related feature - resistance to leakage through third-party services, in which authentication takes place. It means that some services are prone to information leakage, which will help an attacker to use your data for authentication in other services. Basically, these are fraudulent schemes, when one website can illegally transfer your personal data to another website or service. Here, the same situation occurs with passwords as in the previous requirement - if we do not trust any third parties, then we do not trust third-party authentication systems.
The problem here is that the resistance of the entire system is equal to the resistance of the weakest link, for example, HTTPS or CA. For example, if a single CA authorization center is compromised, then its certificates can be distributed to multiple sites. If someone erroneously issues a CA certificate to a untrustworthy party, it will damage all system participants.



The authors of the article believe that passwords do not meet this requirement, so they say no. This is due to the fact that users often use the same password on many different sites. For example, if someone steals my Gmail account password, he will automatically take over my Facebook account password.

So, this was an overview of the most important categories of authentication scheme evaluation reviewed by the authors of the article. But all these indicators make sense only if you can compare them with indicators of other authentication systems and give a corresponding assessment.

One of the interesting authentication systems is biometrics, or biometric data. We used to think of biometrics as a super cool thing that scans the retina, fingerprint, and so on, and therefore looks very futuristic. In fact, biometrics is simply based on taking into account the unique features inherent only in this individual, for example, bodily properties, peculiarities of gestures, and the like.

One of the interesting characteristics of biometrics is the dimension of the keys, which determines the degree of entropy. The dimension of the keys is not as large as it should be. For example, for fingerprints, the key dimension is approximately 13.3 bits, for retinal scanning, 19.9 bits, voice recognition has a key dimension, or the entropy index is about 11.7 bits.

54:15 sec.

The course MIT "Security of computer systems." Lecture 17: User Authentication, Part 3


Full version of the course is available here .

Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to friends, 30% discount for Habr users on a unique analogue of the entry-level servers that we invented for you: The whole truth about VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps from $ 20 or how to share the server? (Options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps until December for free if you pay for a period of six months, you can order here .

Dell R730xd 2 times cheaper? Only here2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV from $ 249 in the Netherlands and the USA! Read about How to build an infrastructure building. class c using servers Dell R730xd E5-2650 v4 worth 9000 euros for a penny?