- How 2fa works with TOTP
- Code
- Adding bells and whistles
- How secure is OTP really?
How 2fa works with TOTP
TOTP is short for time-based one-time password. This is a commonly used method for a second factor in two-factor authentication. The normal login flow for the user is then: first log in with username and password. Then you are presented with a second login form, where you have to enter a one-time password. Typically you will have an app like Google Authenticator or Microsoft Authenticator that will provide you with a one-time code that you can enter. If you have the right code, you will be authenticated and you gain access.
How does the web service know what the right one-time code is?
Consider a web application using two-factor authentication. The user has Google Authenticator on his or her phone to provide one-time passwords – but how does the app know what to compare with?
That comes from the setup: there is a pre-shared secret that is used to generate the tokens based on the current time. These tokens are valid for a limited time (typically 30, 60 or 120 seconds). The time here is “Unix time” – the number of seconds since midnight 1 January 1970. TOTP is a special case for a counter-based token created with the HOTP algorithm (HOTP = HMAC based one-time password). Both of these are described in lengthy detail in RFC documents, and the one for TOTP is RFC 6238. The main point is: both token generator (phone) and validator (web server) needs to know the current unix time and they need a pre-shared secret. Then the token can be calculated a function of the time and this secret.
A one-time password used for two-factor authentication is a function of the current time and a pre-shared key.
Details in RFC 6238
How do I get this into my app?
Thanks to open source libraries, creating a 2fa flow for your app is not hard. Here’s an example made on Glitch for a NodeJS app: https://aerial-reward.glitch.me/login.
The source code for the example is available here: https://glitch.com/edit/#!/aerial-reward. We will go through the main steps in the code to make it easy to understand what we are doing.
Step 1: Choose a library for 2FA.
Open source libraries are great – but they also come with a risk. They may contain vulnerabilities or backdoors. Doing some due diligence up front is probably a good idea. In this case we chose speakeasy because it is popular and well-documented, and running npm audit does not show any vulnerabilities for the library although it hasn’t been updated in 4 years.
Step 2: Activate MFA using a QR code for the user
We assume you have created a user database, and that you have implemented username- and password based login (in a safe way). Now to the MFA part – how can we share the pre-shared secret with the device used to generate the token? This is what we use a QR code for. The user will then log in, be directed to a profile page where “Activate MFA” is an option. Clicking this link shows a QR code that can be scanned with an authenticator app. This shares the pre-shared key with the app. Hence: the QR code is sensitive data, so it should only be available when setting up the app, and not be stored permanently. The user should also be authenticated in order to see the QR code (using username and password).
In our example app, here’s the route for activating MFA after logging in.
app.get('/mfa/activate', (req, res) => {
if (req.session.isauth) {
var secret = speakeasy.generateSecret({name: 'Aerial Reward Demo'})
req.session.mfasecret_temp = secret.base32;
QRCode.toDataURL(secret.otpauth_url, function(err, data_url) {
if (err) {
res.render('profile', {uname: req.session.username, mfa: req.session.mfa, qrcode: '', msg: 'Could not get MFA QR code.', showqr: true})
} else {
console.log(data_url);
// Display this data URL to the user in an <img> tag
res.render('profile', {uname: req.session.username, mfa: req.session.mfa, qrcode: data_url, msg: 'Please scan with your authenticator app', showqr: true})
}
})
} else {
res.redirect('/login')
}
})
What this does is the following:
- Check that the user is authenticated using a session variable (set on login)
- Create a temporary secret and store as a session variable, using the speakeasy library. This is our pre-shared key. We won’t store it in the user profile before having verified that the setup worked, to avoid locking out the user.
- Generate a QRCode with the secret. To do this, you need to use a qrcode library, and we used the one qrcode, which seems to do the job OK. The speakeasy library generates an otpauth_url that can be used in the QR code. This otpauth_url contains the pre-shared secret.
- Finally we are rending a template (the profile page for the user) and supplying the QR code data url to a template (res.render).
For rendering this to the end user we are using a Pug template.
html
head
title Login
link(rel="stylesheet" href="/style.css")
body
a(href="/logout") Log out
br
h1 Profile for #{uname}
p MFA: #{mfa}
unless mfa
br
a(href="/mfa/activate") Activate multi-factor authentication
if showqr
p= msg
img(src=qrcode)
p When you have added the code to your app, verify that it works here to activate.
a(href="/mfa/verify") VERIFY MFA CODE
if mfa
img(src="https://media.giphy.com/media/81xwEHX23zhvy/giphy.gif")
p Security is important. Thank you for using MFA!
The QR code is shown in the profile when the right route is used and the user is not already using MFA. This presents the user with a QR code to scan, and then he or she will need to enter a correct OTP code to verify that the setup works. Then we will save the TOTP secret in the user profile.
How it looks for the user
Scanning the QR code on an authenticator app (many to choose from, FreeOTP from Red Hat is a good alternative), gives you OTP tokens. Now the user needs to verify by entering the OTP. Clicking the link “VERIFY MFA CODE” to do this brings up the challenge. Entering the code verifies that you have your phone. When setting things up, the verification will store the secret “permanently” in your user profile.
How do I verify the token then?
We created a route to verify OTP’s. The behavior depends on whether MFA has been set up yet or not.
app.post('/mfa/verify', (req, res) => {
// Check that the user is authenticated
var otp = req.body.otp
if (req.session.isauth && req.session.mfasecret_temp) {
// OK, move on to verify 2fa activation
var verified = speakeasy.totp.verifyDelta({
secret: req.session.mfasecret_temp,
encoding: 'base32',
token: otp,
window: 6
})
console.log('verified', verified)
console.log(req.session.mfasecret_temp)
console.log(otp)
if (verified) {
db.get('users').find({uname: req.session.username}).assign({mfasecret: req.session.mfasecret_temp}).write()
req.session.mfa = true
req.session.mfarequired = true
res.redirect('/profile')
} else {
console.log('OTP verification failed during activation')
res.redirect('/profile')
}
} else if (req.session.mfarequired) {
// OK, normal verification
console.log('MFA is required for user ', req.session.username)
var verified = speakeasy.totp.verifyDelta({
secret: req.session.mfasecret,
encoding: 'base32',
token: otp,
window: 6
})
console.log(verified)
if (verified) {
req.session.mfa = true
res.redirect('/profile')
} else {
// we are pretty harsh, thrown out after one try
req.session.destroy(() => {
res.redirect('/login')
})
}
} else {
// Not a valid 2fa challenge situation
console.log('User is not properly authenticated')
res.redirect('/')
}
})
The first path is for the situation where MFA has not yet been set up (this is the activation step). This is checked that the user is authenticated and that there is a temporary secret stored in a session variable. This happens when the user clicks the “VERIFY…” link on the profile page after scanning the QR code, so this session variable will not be available in other cases.
The second path checks if there is a session variable mfarequired set to true. This happens when the user authenticates, if an MFA secret has been stored in the user profile.
The verification itself is done the speakeasy library functions. Note that you can use speakeasy.totp.verify (Boolean) or speakeasy.totp.verifyDelta (gives a time delta). The former did not work for some reason, whereas the Delta version did, which is the only reason for this choice in this app.
How secure is this then?
Nothing is unhackable, and this is no exception to that rule. The security of the OTP flow depends on your settings, as well as other defense mechanisms. How can hackers bypass this?
- Stealing tokens (man-in-the-middle or stealing the phone)
- Phishing with fast use of tokens
- Brute-forcing codes has been reported as a possible attack on OTP’s but this depends on configuration
These are real attacks that can happen, so how to protect against them?
- Always use https. Never transfer tokens over insecure connections. This protects against man-in-the-middle.
- Phishing: this is more difficult, if someone obtains your password and a valid token and can use them on the real page before the token expires, they will get in. Using meta-data to calculate a risk-score can help: sign-in from new device requires confirmation by clicking a link sent in email, force password reset after x failed logins, etc. None of that is implemented here. That being said, OTP-based 2FA protects against most phishing attacks – but if you are a high-value target for organized crime of professional spies you probably should think about more secure patterns. Alternatives include push notifications or hardware tokens that avoid typing something into a form.
- Brute-force: trying many OTP’s until you get it right is possible if the “window” is too long for when a code is considered valid, and you are not logged out after trying 1 or more wrong codes. In the code above the window parameter is set to 6, which is very long and potentially insecure, but the user is logged out if the OTP challenge fails, so brute-force is still not possible.
safecontrols 