Let’s talk about 2 factor aunthentication – Security Blog #5

After the last security class, when we all did the Last Pass Challenge (Where I did so… so bad), I started to change an generate a lot of passwords (Like 40 as of now) and activated 2-factor authentication on most of the sites where I could. I don’t know why I did this until now, and not when we talked about this topic in class.

16021496959_1d2ffb589a_h
“Fingerprint authentication 06” by Hideya Hamano (CC BY-NC-ND). From https://www.flickr.com/photos/mawari/16021496959

I knew what the 2-factor authentication did, but I didn’t know how. So after some reading (Links below) I finally got around all the concepts.

  1. 2 Factor Authentication (2FA) is just a layer of Multi-Factor Authentication (MFA)
  2. 2FA works even if the device isn’t connected to the internet. Not for SMS 2FA.
  3. It’s very secure, but as everything, it has some weak components.
  4. This makes 2FA a failed attempt to create a silver bullet for security.

Let’s start with the concept of 2FA just being a layer. What layer? Of how many? Why do we have that layer only? I want more of those!

Okay, so the point of the verification is to tell the service that you are who you say you are. That is why we have passwords. And passwords are things we know, and the knowledge factors are the first and basic layer of credentials in an MFA.

The second layer of credentials are the possession factors, which are the things that the user has, like a phone, an ID or tokens. This is the layer where 2FA is based upon.

The last big layer is the third one. It’s called inherence factors. These factors are the things that the user is. Usually, we are talking about biometrics here, but there are ways to measure behaviors and patterns of a user (Behavioral biometrics) such the way they walk, the way the type or talk. This layer is less used because it depends on hardware and it might increment complexity and costs.

There are two more, far simpler layers, that are only used in heavy security demanding systems. Location and time are these layers. This means the location of which the user is trying to access the service and the time might be taken into account to verify you.


And now: Whow do they manage to make 2FA app’s, such as Google Authenticator, work even if the app is completely disconnected from the WEB?

First. I’m going to explain to you two types of One Time Passcode (OTP): HMAC-based OTP (HOTP) and Time-based OTP (TOTP). Both of these are used to generate the numbers that you see in Google Authenticator App, and both use HMACs in the process.

The first method, HOTP, (The inefficient one), takes the secret key the sever gave to you when the account was created or the 2FA service was activated, and a counter as the message for the HMAC function. The counter represents the number of times an OTP was generated. So when I try to login to a site for the nth time (The server must know how many times have I used an OTP. It also knows the secret and has the same HMAC), I also generate the nth code in my app. And this works as long the server and the app have fully synched counters. The server even usually checks from n to n+x values of the counter to see if, by any case, the mobile app has gotten out of sync. In case the app’s counter is ahead, the server can know at which value the app is currently in, but only if it’s in the x-range, and the problem is that the user can get so ahead from the server that it can’t get in sync.

The second method, TOPT (The popular one), also uses an HMAC function and the secret key. But instead of a counter, it uses 30 seconds intervals of UNIX time; It uses floor(Unix-time() / 30) to get to the nearest second. The server and the user are usually just some seconds out of sync, so the server can just check for the previous and following values of the HMAC function to see if that is the code that the user is typing.

Both methods generated a hashed message. Then, both the server and the client slice and apply some modulos to finally generate the code. The user sends the generated message, and the server compares it to the set of messages it generated (In case the user is out of sync), and if the service is using HOTP, it also increments the counter on success.

And because both devices have everything they need to generate the adequate code for that specific moment, they don’t need to be connected.


But is this secure enough?

Well… It depends… This method is as secure as it’s weakest component.

In case that the 2FA isn’t done using an app, but instead uses 2FA-SMS (The server generates a code, it sends it to the user, the user types it in), the integrity of 2FA can be easily compromised by intercepting or redirecting messages.

There are some sites where the account-recovery is badly implemented and can let the hijacker get around the necessity of introducing the 2FA code.

The database where the user keys are stored can also get hacked. With this knowledge, along with the hash and a clock you could, in theory, generate the security code.


Maybe I will post something more regarding this and my current Last Pass experience (I think that there are only some few sites missing!).

But as for now, I think I have said enough.

Cheers.

Miguel Montoya
Esperanto enthusiast
ʕ•ᴥ•ʔ


Some further reading:

Some references:

Anuncios

I just had an idea – End of week 9

Okay, so supposedly this week we would try to come up with some new ideas for our project. Because,you know…. We kinda did all of them already.

140802535_8a43eaec59_o
“Gun-Idea” by Linus Bohman (CC BY). From https://www.flickr.com/photos/bohman/140802535/

My team came up with several ideas and changes. But what I think it’s the most important is that we are going to -finally- introduce proper sprites and sounds to the game. The idea of different surfaces (Like some slippery and bouncy ones) that would affect (And force us to develop) a more complex set of phisycs.

Well, at least I suggested a new issue for the project (new issue) that I will be implementing. That is a new enemy that can’t be killed when shooting at it. This will enable us to develop more levels where we don’t need to care about the gameplay getting to easy if the gun is spammed.

And that is all for this week.
Have a good one.

Miguel Montoya
Esperanto enthusiast
ʕ•ᴥ•ʔ

Week 9 TO-DO

We need new objectives!

And I need to update the code documentation and the README!

And that’s basically it. We don’t have anything more to do but to prepare for Friday’s presentation. I will publish at the end of the week what we plan to do the next week.

Cherio.

Miguel Montoya
Esperanto enthusiast
ʕ•ᴥ•ʔ

2446866948_987f5c418e_b
“Old Objective” by wolfgangfoto (CC BY-ND). From https://www.flickr.com/photos/wolfgangfoto/2446866948/

 

End of week 8 (Vacations)

As I was talking about the week before last, we decided to take that week lightly and so the week after that (Because it was our Taller Vertical).

 

5994875062_3d09a434f1_b
“Change” by Mark Deckers (CC BY-NC-ND). From https://www.flickr.com/photos/27454036@N03/5994875062

The summary of the last to weeks is the following:

  1. I made some bugfixes regarding the code I was working the past weeks. Some of the scripts were heavily bugged, especially the ones regarding level setting and getting to and from the database.
  2. Realize that I have to update part of the documentation. That I didn’t do.
  3. Realize as a team that we need more objectives to our project. Because, as it is, we kinda have done everything. So that is what we are going to do this week.

That is all for now. Thanks for tunning in.

Miguel Montoya
Esperanto enthusiast
ʕ•ᴥ•ʔ