Introduction to 2FA

Historically, the ​Akamai​ Identity Cloud has relied on single-factor authentication: as long as you knew your email address and password (two items which, in the authentication world, are considered a single “authentication factor”) then you were able log on to an Identity Cloud website or app, and to do so simply by supplying that email address and password. 

📘

Yes, this could be an email address and password specific to the site in question, or it could be an email address and password for a social login provider. The point is, you just needed to have a valid email address and password, regardless of whether that user name and password were unique to the Identity Cloud site or were “borrowed” from a social login identity provider.

Single-factor authentication is quick and easy, but it’s not the most secure authentication method ever devised. For example, email addresses are often publicly available; that means a hacker needs to guess only one piece of information (your password) in order to access your account. How hard is it to guess someone’s password? Well, according to the National Cyber Security Centre, these are the most-commonly used passwords in the United Kingdom:

1. 123456
2. 123456789
3. qwerty
4. password
5. 111111
6. 12345678
7. abc123
8. 1234567
9. password1
10. 12345

Which means that guessing someone’s password might not be all that hard. Single-factor authentication is probably the most-widely used authentication method, but it’s not without its issues.

Two-factor authentication (2FA) helps address these issues by adding a second authentication factor: in addition to an email address and password you need a second piece of information before you can log in and access an account. In the case of Hosted Login v2, that additional piece of information is a one-time access code (i.e., a one-time password) sent to the user via email or text messaging (using SMS: the short message service). Before a user is fully logged on, and before a user is issued an access token, that user must present the access code sent to them. No access code? Then you can’t be logged on and you can’t be issued an access token.

Period.

📘

If you’re familiar with 2FA, the two factors used with Hosted Login v2 are something you know (your email address and password) and something you have (an access code).

In other words, even if a hacker has your email address, and even if a hacker has managed to guess your password, that hacker still can’t access your account: they also need the access code, which means they need real-time access to your email account and/or your mobile device. That’s not impossible, mind you, but the degree of difficulty that must be surmounted in order to hack into a user account has been upped dramatically.

In Hosted Login v2, 2FA (if enabled) is employed for both user logins and user registrations. If 2FA is enabled then, when you create an account, you’re emailed an access code (text messaging is not used during the registration process), and you must supply that access code before you can log on. 

📘

Technically, your account will be created even before you get the access code. However, without a verified email address you can’t log on, meaning that the account is of little use to you.

During subsequent logins, you’ll sign in by using either traditional login or social login, and sign in the same way you always have.  After you’ve been authenticated, you’ll then be given a choice between having a verification code sent via email or via text message. Once again, you’re required to supply that code before you can finish logging in and before you can be issued an access token.

📘

One clarification: you’ll be given the opportunity to receive an access code via text messaging only if you’ve added your mobile device number to your user profile. If you haven’t done this then access codes are automatically sent via email.

A similar approach has also been applied to the email addresses and mobile device numbers in your user profile. Hosted Login v2 allows you to change your email address and/or your mobile device number any time you want, but only if you complete a 2FA-like process: you can change your email address or mobile device number, but those changes won’t take effect until you’ve supplied the required verification code.

📘

If you change your email address the code is emailed to that email address; if you change your mobile device number, the code is sent via text message to the new number.

Keep in mind that this verification process is applied to your email address and mobile device number even if 2FA is disabled: in Hosted Login v2 you always need to verify changes made to your email address or mobile number. (Although you can delete your mobile number without having to go through the verification process.)

A quick note about access codes

Access codes are randomly-generated six-digit values tied to a specific user account; for example, if the code 036858 is sent to user karim.nafir@mail.com, then only karim.nafir@mail.com can use that code. If any other user presents the verification code it will be rejected as invalid:

Access codes expire after 10 minutes; if a user waits 11 minutes to supply the code that code will be rejected and the user will need to request a new one.

Codes can only be used once, although it is possible for a user to have more than one valid access code. For example, suppose a user logs in and, as part of the 2FA process, is sent an access code. Instead of using that code, however, the user requests another code. That second code is also sent; however, the first code won’t be revoked or otherwise invalidated. That means that the user now has two valid verification codes, and either code can be used to complete the 2FA process. That’s one reason why verification codes have such a limited lifespan: to help minimize the security implications of a user having multiple valid 2FA codes. (Although, because the codes are tied to a specific account, those security risks are relatively minor.)