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