 TOTP and HOTP are algorithms for generating two-factor authentication codes. Let's take a look at how these work, starting with the simpler HOTP. First, you enable two-factor authentication by scanning a QR code or tapping a link to set it up in your two-factor authentication code generator, such as the Google Authenticator app. Then, when you want to log in, you generate a code and enter it in. Neat! Here's what's going on throughout the process. The QR code you scan with your phone encodes a random secret and some metadata. Your phone and the server both keep track of this secret and a counter value, which starts at zero. Whenever you get a new code, your counter value goes up. When you send the code to the server, the server checks what the next code is. If your code matches, then it logs you in and updates its counter value. If you generate a code but don't send it to the server, then your counter value will be higher than the server's count. In this case, the server will check your code against the next counter value and find it invalid. However, servers then check the next few counter values against the provided code to account for situations like this. If there's a match, then the server jumps its counter value forward to match yours and logs you in. The lookahead window here is typically around four to five codes. If you advance your counter too far, then they'll be outside of the server's lookahead window and you'll either have to manually change your counter value or reset up two-factor authentication. Servers won't accept codes with a sequence value lower than a one that they have already accepted. But how exactly are the codes generated? The HMAC SHA-1 function is key here. HMAC functions are usually used for verifying the authenticity of a signed message. They have two parameters, a secret and a message. HOTP just uses this HMAC function with a secret from the server and a counter value as the message. Since HMAC functions really just end up using their underlying hash function, SHA-1 in this case, the output is 160 bits, or 20 bytes long. Since HOTP codes are usually six or eight digits long, this long output needs to be shortened into a smaller number of digits. The SHA-1 hash is truncated and the numeric value is divided by 10 to the power of the number of digits and the remainder of that is the current code value. Note that the SHA-1 hash is truncated in a needlessly complicated process called dynamic truncation. There is no need for the dynamic part here, but it does add to the complexity of HOTP for no reason. It might have made sense at the time the spec was written, however, to defend against some theoretical SHA-1 attacks. Next, let's take a look at TOTP, which is very similar to HOTP, except time-based. It's quite similar to HOTP and is set up in authentication apps the same. The only difference is that the code is based on the current time instead of a sequence value. The sequence value used for TOTP is derived from the current UNIX time, the number of seconds since January 1st, 1970, and the gap between codes, usually 30 seconds. You divide the UNIX time by that gap, round it down, and you get the current sequence value. Pass that sequence value into the same code generation function used by HOTP and you've got your code for the current time. Of course, authentication apps have to repeat this process to generate a new TOTP code every 30 seconds. TOTP codes are validated a little bit differently than HOTP codes. The authentication server checks if the provided code is within a certain window of the current time, typically a few minutes, and if it's within that window, it's allowed. To prevent code reuse, the server stores the time of the last valid code and requires that any subsequent login attempts use the code from after that time. TOTP is better than HOTP for almost all use cases. Really the only reason to use HOTP nowadays is for older systems that don't support TOTP and for embedded devices that don't have a clock and therefore can't keep track of the current time. Finally, let's take a look at how secrets are sent from the server to the authentication app. The simple, widely supported way is to just tell the user to enter the secrets and parameters directly. However, Google Authenticator supports another method where all the parameters in the secret are combined into a single QR code or link which looks like this. The QR code just encodes the link data and the link contains all of the needed OTP parameters. That's it. Thanks for watching.