2fa and otp
TRANSCRIPT
![Page 1: 2FA and OTP](https://reader036.vdocuments.net/reader036/viewer/2022081507/58e7afc91a28abbb4e8b4915/html5/thumbnails/1.jpg)
2FA and OTPHMAC HOTP and TOTP implementation in Ruby
![Page 2: 2FA and OTP](https://reader036.vdocuments.net/reader036/viewer/2022081507/58e7afc91a28abbb4e8b4915/html5/thumbnails/2.jpg)
@parasquidChief Problem Solver
at Mindvalley
![Page 3: 2FA and OTP](https://reader036.vdocuments.net/reader036/viewer/2022081507/58e7afc91a28abbb4e8b4915/html5/thumbnails/3.jpg)
• 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
![Page 4: 2FA and OTP](https://reader036.vdocuments.net/reader036/viewer/2022081507/58e7afc91a28abbb4e8b4915/html5/thumbnails/4.jpg)
2FAmultiple evidence presented to the
authentication mechanism
![Page 5: 2FA and OTP](https://reader036.vdocuments.net/reader036/viewer/2022081507/58e7afc91a28abbb4e8b4915/html5/thumbnails/5.jpg)
OTPa password that can only be used once
and then discarded
![Page 6: 2FA and OTP](https://reader036.vdocuments.net/reader036/viewer/2022081507/58e7afc91a28abbb4e8b4915/html5/thumbnails/6.jpg)
RFC 2119
• MUST (NOT), REQUIRED
• SHALL (NOT), SHOULD (NOT), RECOMMENDED
• MAY, OPTIONAL
![Page 7: 2FA and OTP](https://reader036.vdocuments.net/reader036/viewer/2022081507/58e7afc91a28abbb4e8b4915/html5/thumbnails/7.jpg)
HMAChash function (md5, sha*, etc)
shared secret key message
![Page 8: 2FA and OTP](https://reader036.vdocuments.net/reader036/viewer/2022081507/58e7afc91a28abbb4e8b4915/html5/thumbnails/8.jpg)
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
![Page 9: 2FA and OTP](https://reader036.vdocuments.net/reader036/viewer/2022081507/58e7afc91a28abbb4e8b4915/html5/thumbnails/9.jpg)
strong shared secret160 bits using HMAC-SHA1
![Page 10: 2FA and OTP](https://reader036.vdocuments.net/reader036/viewer/2022081507/58e7afc91a28abbb4e8b4915/html5/thumbnails/10.jpg)
token is easily readbit shfting is economical to implement in hardware
![Page 11: 2FA and OTP](https://reader036.vdocuments.net/reader036/viewer/2022081507/58e7afc91a28abbb4e8b4915/html5/thumbnails/11.jpg)
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
![Page 12: 2FA and OTP](https://reader036.vdocuments.net/reader036/viewer/2022081507/58e7afc91a28abbb4e8b4915/html5/thumbnails/12.jpg)
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
![Page 13: 2FA and OTP](https://reader036.vdocuments.net/reader036/viewer/2022081507/58e7afc91a28abbb4e8b4915/html5/thumbnails/13.jpg)
unix timetime step value
![Page 14: 2FA and OTP](https://reader036.vdocuments.net/reader036/viewer/2022081507/58e7afc91a28abbb4e8b4915/html5/thumbnails/14.jpg)
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
![Page 15: 2FA and OTP](https://reader036.vdocuments.net/reader036/viewer/2022081507/58e7afc91a28abbb4e8b4915/html5/thumbnails/15.jpg)
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)
![Page 16: 2FA and OTP](https://reader036.vdocuments.net/reader036/viewer/2022081507/58e7afc91a28abbb4e8b4915/html5/thumbnails/16.jpg)
DEMO
![Page 17: 2FA and OTP](https://reader036.vdocuments.net/reader036/viewer/2022081507/58e7afc91a28abbb4e8b4915/html5/thumbnails/17.jpg)
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)
![Page 18: 2FA and OTP](https://reader036.vdocuments.net/reader036/viewer/2022081507/58e7afc91a28abbb4e8b4915/html5/thumbnails/18.jpg)
@parasquidChief Problem Solver
at Mindvalley