2FA and OTPHMAC HOTP and TOTP implementation in Ruby
@parasquidChief Problem Solver
at Mindvalley
• 2FA - two factor authentication
• OTP - one time password
• HMAC - hash-based message authentication codes (RFC 2104)
• HOTP - HMAC-based one time password
• TOTP - time-based one time password
2FAmultiple evidence presented to the
authentication mechanism
OTPa password that can only be used once
and then discarded
RFC 2119
• MUST (NOT), REQUIRED
• SHALL (NOT), SHOULD (NOT), RECOMMENDED
• MAY, OPTIONAL
HMAChash function (md5, sha*, etc)
shared secret key message
HOTPuses HMAC to sign a counter or
sequence
• The algorithm MUST be sequence or counter-based
• The algorithm SHOULD be economical to implement in hardware
• MUST work with tokens that don't support any numeric input, but MAY also be used in with more sophisticated devices such as PIN-pads
• The value displayed on the token MUST be easily read and entered by the user
• There MUST be user-friendly mechanisms available to resynchronize the counter
• The algorithm MUST use a strong shared secret
• 160bits is RECOMMENDED
strong shared secret160 bits using HMAC-SHA1
token is easily readbit shfting is economical to implement in hardware
HOTPuses HMAC to sign a counter
• The algorithm MUST be sequence or counter-based
• The algorithm SHOULD be economical to implement in hardware
• MUST work with tokens that don't support any numeric input, but MAY also be used in with more sophisticated devices such as PIN-pads
• The value displayed on the token MUST be easily read and entered by the user
• There MUST be user-friendly mechanisms available to resynchronize the counter
• The algorithm MUST use a strong shared secret
• 160bits is RECOMMENDED
TOTPextends HOTP by using a time-based
moving factor
• The prover and verifier MUST know or be able to derive the current Unix time
• The prover and verifier MUST either share the same secret or the knowledge of a secret transformation to generate a shared secret
• The prover and verifier MUST use HOTP as a building block
• The prover and verifier MUST use the same time-step value
• There MUST be a unique secret (key) for each prover
• The keys SHOULD be randomly generated or derived using key derivation algorithms
• The keys MAY be stored in a tamper resistant device and SHOULD be protected against unauthorized access and usage
unix timetime step value
TOTPextends HOTP by using a time-based
moving factor
• The prover and verifier MUST know or be able to derive the current Unix time
• The prover and verifier MUST either share the same secret or the knowledge of a secret transformation to generate a shared secret
• The prover and verifier MUST use HOTP as a building block
• The prover and verifier MUST use the same time-step value
• There MUST be a unique secret (key) for each prover
• The keys SHOULD be randomly generated or derived using key derivation algorithms
• The keys MAY be stored in a tamper resistant device and SHOULD be protected against unauthorized access and usage
TOTPextends HOTP by using a time-based
moving factor
• RECOMMENDED to have at most one time step delay is allowed as the network delay • may be due to network latency OR • may be due to improper server time • handle both future and past
• RECOMMENDED to have a time-step value of 30 seconds • larger time-step exposes a larger window to
attack • when OTP is generated and exposed to a 3rd
party before it is consumed, the 3rd party can consume the OTP before the time-step window
• smaller time-step is not a good experience for the user (especially if the device is cumbersome to use)
DEMO
Why TOTP?(instead of an RNG)
• No need to save tokens in the database
• tokens are calculated on the fly
• you still need to save the shared secret key
• Implementations that adhere to the standard can be used
• e.g. FreeOTP, Google Authenticator, FB Authenticator
• The best possible attack is a brute-force attack (see https://tools.ietf.org/html/rfc4226#appendix-A.4.3)
@parasquidChief Problem Solver
at Mindvalley