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.
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.
- 2 Factor Authentication (2FA) is just a layer of Multi-Factor Authentication (MFA)
- 2FA works even if the device isn’t connected to the internet. Not for SMS 2FA.
- It’s very secure, but as everything, it has some weak components.
- 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.
Some further reading:
- Problems with 2FA: Two-factor authentication is a mess
- Lost your phone?: What Happens If I Use Two-Factor Authentication and Lose My Phone?
- 2 Factor Authentication: How does Authy’s 2FA work, if it doesn’t connect to the server?
- How are the numbers in 2FA generated: How does Authy’s 2FA work, if it doesn’t connect to the server?
- HMAC: Hash-based Message Authentication Code (HMAC)