Description
Using more than one way to authenticate a user who is trying to access a web application is becoming important. Companies like Google and Microsoft use a technology for this that is known as TOTP (Time-based One Time Password). You can read how this works using this link.
At this point the library and sample app use the TOTP (Time-based One Time Password) technique. This TOTP technique uses a secret string together with the current time and an encryption method to generate a 6 to 8 digits long number (token) that is used as an extra password for login. By default, this token value get a different value every 30 seconds. The technique itself is based on some RFC standards:
Variables for this techniques are:
- Encryption method
The method of encryption (SHA1, SHA256, SHA512) - Secret
This secret should be known by both the server and the generator of the code. The length of it depends on the encryption method. - Time
Default this is the Unix time, which is the number of seconds since the 1st of January 1970. An epoch can be applied to start at a different time. - Time window
By default is divides the number of seconds by 30. Optionally a different divider can be applied. - Digits
The number of digits for the token. This varies between 6 and 8.
The user will need some way to get the current token value. For the moment we are assuming that someone will use an app on their mobile phone (Authenticator app) to generate a token, but the token can also be generated in different ways, for example a hardware token or sent in a text message to the mobile phone.
Examples of apps that a user can install on their mobile phone to store the secret are for example Google Authenticator or Microsoft Azure Authenticator, but there are others as well.
The most convenient way of getting a secret into the authenticator app on the mobile device, is by letting the app scan a QR code that holds this information. What the app needs is a specifically formatted URI. That URI-text is converted into a QR code and that QR code can be scanned with an authenticator app.
URI: otpauth://totp/login/guest?secret=DATAFLEXAUTHENTICATORAPPLICATION&issuer=DataFlex
The client and server need to agree upon the variable values to be used. The secret is basically binary data. Most implementations, and also the URI, will exchange the secret coded in base32. This way the chance on making typing mistakes is kept to a minimum because base32 only contains the letters of the alphabet and the numbers 2-7. The digits 0 and 1 are not used so these cannot be taken for the letters ‘i’ or ‘o’.
The clock of both the server and client should be in sync because one of the variables of generating a token is the current time and the token only is valid for a time window of 30 seconds. When the clocks don’t run in sync, the chance is that the generated tokes will not match. At the same time, it might also take some time to get a token to the client and/or for the user to enter the token. To avoid this problem, you can let the server accept other tokens that were valid just before the current time or that are valid just after the current time.
Components
The DataFlex Authenticator consist out of a DataFlex package with a DLL and a sample application that shows how this technique can be used in DataFlex applications. The current implementation shows how it can be used with a web app, but the same technique can be used for Windows apps.
The DataFlex package uses some components that have specifically defined for this purpose.
- cOneTimePassword.pkg A DataFlex package that provides functions for generating codes. It also provides an interface to the OATH.dll.
- OATH.dll This DLL provides some low-level functions that are hard to do in DataFlex. It includes coding of data (base32), time operations (unix based time) and cryptographic operations. The DLL has been built by Ulbe Stellema and based on code that can be found here:
Sample app
The sample app shows how the technique can be used during login. Besides that, it also includes a control that can be used to show QR codes in a browser.
To login to the app you will need a user id, a password and a valid token. For demo purposes, the code will be show when you click on the demo link in the login dialog. That information also shows a QR code that can be scanned with an authenticator app so that an authenticator app can be used o generate a code. The generated code by the authenticator app should match the code that is shown in the login screen. Since the current time is factor, you might need to refresh it to compare it with the code that it generated by the authenticator app.
By default, the app will accept 2 codes before and after the current time to be valid to allow for out-of-sync clock problems and time it takes to get and enter a code.
You can try the app here. After logging in, the sample app will show a test view that allows you to play around with TOTP and it has a tab that shows that the component generates the same tokens as on the documentation page behind the RFC.