The LDAP profile we will configure will be extremely basic: no SSL, no Active Directory, etc. The process is broken out into steps as trying to complete all the sections in tandem can be difficult to troubleshoot.Ĭreating An LDAP (Active Directory) Authentication Configuration The installation of Google Authenticator two-factor authentication on your BIG-IP is divided into six sections: creating an LDAP authentication configuration, configuring an LDAP (Active Directory) authentication profile, testing your authentication profile, adding the Google Authenticator iRule and “user_to_google_auth” mapping data group, attaching iRule to the authentication profile, and finally generating soft tokens for your users. Installing Google Authenticator Two-Factor Authentication Google Authenticator Two-Factor Authentication Process The rest is done with simple bitwise and arithmetic functions. These two pieces of code contribute the bulk of the processing of the Google Authenticator code. The iRule was slightly modified to support the SHA-1 algorithm, but is otherwise taken directly from the pseudocode outlined in RFC 2104. The HMAC-SHA256 token calculation iRule was originally submitted by Nat to the Codeshare on DevCentral. The Tech Tip details the process for decoding a user’s base32-encoded key to binary as well as converting a binary key to base32. The resulting 8 hex digits are then AND’d with 0x7FFFFFFF (2,147,483,647), then the modulo of the resultant integer and 1,000,000 is calculated, which produces the correct code for that 30 seconds period.īase32 encoding and decoding were covered in my previous Tech Tip titled Base32 Encoding And Decoding With iRules. The offset is then used to read the next 8 hex digits from the offset. The resulting 80-byte token is converted to a 40-character hexadecimal string, the least significant (last) hex digit is then used to calculate a 0-15 offset. The Google Authenticator TOTP is calculated by generating an HMAC-SHA1 token, which uses a 10-byte base32-encoded shared secret as a key and Unix time (epoch) divided into a 30 second interval as inputs. ![]() The algorithm however is only as secure as the users and administrators are at protecting the shared secret used in token processing.Ĭalculating The Google Authenticator TOTP For all intents and purposes, SHA-1 is reasonably secure, well-tested, and purpose-appropriate for this application. While certain potential weakness in SHA-1 have been identified, none of them can be exploited within the 30-second timeframe of the TOTP’s usability. It is free to use (all applications are free to download), the TOTP algorithm is open source, well-known, and well-tested, and finally it does not require a dedicated server for processing tokens. Google Authenticator’s soft token solution offer a number of advantages over other commercially available solutions. In order for the token to be effective, it must not be able to be duplicated and the shared secret should be closely guarded. A user authenticating with a Google Authenticator-enabled service will require the possession of this software token. Google currently offers applications for the Apple iPhone, Android-based devices, and Blackberry handsets. In the case of Google Authenticator, the TOTP are generated using a software (soft) token on a mobile device. ![]() A TOTP is a single-use code with a finite lifetime that can be calculated by two parties (client and server) using a shared secret and a synchronized clock (see RFC 4226 for additional information). Earlier this year Google released their time-based one-time password (TOTP) solution named Google Authenticator.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |