The totp vocab implements time-based one-time password generation as described in RFC 6238 (https://tools.ietf.org/html/rfc6238).
The idea is that a client is able to prove its identity to a server by submitting a password that is only valid for a short period of time. The password needs to be sent via a secure channel inside that time period, and client and server must have a shared secret established in advance. The TOTP protocol uses the number of whole 30-second intervals passed in Unix time as a counter value, which it authenticates with an HMAC and converts into a string of digits. Client and server must use the same secret key, the same hash for the HMAC, the same time reference point (not necessarily Unix time) and the same time interval length for the counter. The string of digits used as the password should be long enough to balance convenience and brute-force attack resistance. For 30-second intervals 6 or more digits are typically used.
Both client and server are able to generate exactly the same digits from the shared secret using their current time as the counter. Server can be programmed to accept values from the adjacent time slots, so that time drift and network delays are compensated for, though that somewhat weakens the system.
Simple high-level interface:
Customizable implementation:
The idea is that a client is able to prove its identity to a server by submitting a password that is only valid for a short period of time. The password needs to be sent via a secure channel inside that time period, and client and server must have a shared secret established in advance. The TOTP protocol uses the number of whole 30-second intervals passed in Unix time as a counter value, which it authenticates with an HMAC and converts into a string of digits. Client and server must use the same secret key, the same hash for the HMAC, the same time reference point (not necessarily Unix time) and the same time interval length for the counter. The string of digits used as the password should be long enough to balance convenience and brute-force attack resistance. For 30-second intervals 6 or more digits are typically used.
Both client and server are able to generate exactly the same digits from the shared secret using their current time as the counter. Server can be programmed to accept values from the adjacent time slots, so that time drift and network delays are compensated for, though that somewhat weakens the system.
Simple high-level interface:
totp-hash
totp-digits
totp ( key -- string )
Customizable implementation:
timestamp>count* ( timestamp secs/count -- count )
totp* ( count key hash -- n )
digits ( n digits -- string )