See also the distinction between two step and two factor authentication. If you assume an attacker can see or derive the token (say by key logger, or video camera watching the keyboard), they can compromise the password and the TOTP token, defeating the authentication system. The RFC 4226 assumes that token values can be observed. This is a cataclysmic error, as to any black box testing that doesn’t have the first 2 billion hashes prerecorded this looks good. Some of those code snippets have a rand() function which only produces 32 bits of output, so can only generate 2^32 values (easily brute forced, and only needs a couple of captured tokens to figure out which value is right) even if the resulting keys appear to have good randomness, and appear to have the right length. Idiomatically I see a lot of “sha1(rand())” or “md5(rand())” around github and elsewhere (not mentioning sample code from well known security device manufacturer). Do not use a cryptographic hash functions on a pseudo-random number (unless you really know what you are doing in conditioning random numbers when you wouldn’t be reading this advice). When you generate the key use a source of randomness which is cryptographic-ally sound. Pick 160 bits key length now, save yourself revisiting too soon. If you had a sequence of tokens from a device, perhaps from filming the user using their phone (some mobile authenticator apps, Duo’s for example, only have one code shown at a time, this seems a wise precaution against being overlooked), then the attack on the secret is brute force calculating which keys might produce those tokens at those times.Įven with the relatively cheap hash functions used in TOTP, 2^80 is unrealistic for most people to brute force, but it is of a similar magnitude to the RC5 64 bit crack given 20 years of Moore’s law, so it is bordering on possible with current hardware. The key is represented as a base32 string, which stores 5 bits per character, so the string in the QR code should be at least 26 characters long (128/5 rounded up), preferably 32 characters.Ī number of implementations have used 80 bit keys. RFC 4226 section 4 Requirement 6 requires a minimum key length of 128 bits, and a recommend of 160 bits. The encryption key (you are going to store the keys encrypted right?), and the plain text of the secret, need to be handled with the upmost care, as it is logically equivalent to a password (assuming a properly hashed password is the other factor in authentication). From the description above you will see the secret key has to be recoverable to plaintext on both ends. Whilst mobile phones and computers do these days typically have chips that perform this function, most of the apps and server side implementations don’t use them for TOTP. The authors of the RFC 4226 assumed that the shared secret would be embedded in hardware security devices designed to keep their secrets. I have found various common implementation errors with TOTP Thus the scheme is resistant to someone who knows your username, password, and all the historic tokens, as long as they don’t get your current token value, they can’t login to your account. By recommending that the secret be at least a 160 bit number (about 48 decimal digits long) trying every value is impossible in reasonable time. The hashing is such that knowing a sequence of tokens doesn’t allow you to derive the secret any faster than trying every possible value of the secret. The token which is shown and entered during login is derived by hashing the secret with the time rounded to the nearest 30 seconds (well most people use 30 seconds).īoth sides generate the token, and as long as their clocks are synchronized, the tokens will match, and you can proceed. Now the phone and the server share a secret. This is encoded into the QR code you scan, and saved on your phone. The system works by generating a big number, which is a shared secret (aka key). Google Authenticator implements a protocol which is properly called Time-Based One Time Passwords (TOTP) described in RFC 6238 and RFC 4226.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |