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: "Control of hacker attacks" Part 1 / Part 2 / Part 3
Lecture 3: "Buffer overflow: exploits and protection" Part 1 / Part 2 / Part 3
Lecture 4: "Separation of privileges" Part 1 / Part 2 / Part 3
Lecture 5: "Where Security Errors Come From" Part 1 / Part 2
Lecture 6: "Opportunities" Part 1 / Part 2 / Part 3
Lecture 7: "Sandbox Native Client" Part 1 / Part 2 / Part 3
Lecture 8: "Model of network security" 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 select 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: this is so, the attacker must be somewhere on the network between the client and the server 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 headline - 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 a lot of 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 either yes or 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. , , . , . , «» , .

, , .

. , , , , , , , . , , , .

- , , . . .

, , . — . , , , DNS - , , . , : «, , , ». , , .



. : . , , . , , , , . , , .

, , , , , , , . . , , , , , , , .

, , , .

– , . , , . , . , – , .
, , , HTTPS . , CA, . - , , .



, , «». , . , - Gmail, Facebook.

, , . , .

, . , , . , , , , .

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 we have 2 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?