miohtama
commented
9 years ago Looks very promising!
Here is some of feedback based on the experience of implementing two-factor on Bitcoin exchange sites.
Please note that one should ask minimum of two separate TOTP codes (or HOTP, paper based two-factor codes) for all outgoing transfers. I suggest the the following procedure
- One TOTP / HOTP code is asked on login for two-factor authentication
- A timer of 40 seconds is set (because TOTP codes change every 30 second). Before the timer is finished, no further two-factor actions are wllowed.
- The next TOTP / HOTP code can be consumed on wallet action if the timer is finished
This effectively prevents phishing attemps or man-in-the-middle attacks which phish out the first two-factor code on login. Phishing two two-factor codes is more rare, as this makes the attack much more complex as modying a single web page is no longer enough.
HOTP, paper based two-factor codes, are useful for people without smartphones. Supporting HOTP is as easy as supporting TOTP - you only need to store additional counter which is the latest used code. HOTP is foreign for most U.S. citizens, but extensively used by European banks. The benefit is that, as being paper based, it is immune to all digital attacks.
HOTP RFC: http://tools.ietf.org/html/rfc4226
TOTP RFC: http://tools.ietf.org/html/rfc6238
Sample TOTP+HOTP implementation: https://github.com/miohtama/django-twofactor
Some background on two-factor on websites: http://opensourcehacker.com/2014/05/28/securing-your-site/
nullstyle
bartekn
bekkibolthouse
We will enable TOTP for a second factor of authentication in the v2 wallet server.
Login
To enable 2FA (and in the future anti-phishing tech), we split the login process into two steps:
LOGINandGETWALLET. AtLOGINthe client provides the username to login with, and the server responds with the KDF params to use when derivingK_mand whether TOTP is required.When TOTP is required, the GETWALLET message must also provide a valid TOTP-code to be successful
Lockout
When 2FA is enabled, we do not lock out attempts that provide a valid TOTP code.
TOTP Removal
It is possible that a user will lose their phone or otherwise lose access to their TOTP generator. In many organizations, you would use call in phone verification to allow a user to disable TOTP. Instead, we will allow for a time-released, automated process to disable TOTP:
Requesting Removal
To request removal, the user clicks on a link in the client to initiate the process. As a second step, the user re-enters their password, which is used to derive
W, which is transmitted to the server as part of the /v2/totp/disable message. The removal is now initiated.NOTE: If the password is entered incorrectly, we provide no indication to the user, so that we do not leak the passwords correctness to an attacker. We simply state "We've received your removal request. You should receive an email soon confirmation soon".
Grace Period
We initiate a 30 day grace period before allowing TOTP-less logins. We use this grace period in an attempt to prevent an attacker from inadvertantly disabling TOTP for a user. During this grace period, we notify the user periodically that their account's TOTP is being disabled in X days, and provide them a link to abort the process. This is not fool-proof as an attacker may have also compromised the user's email and can delete the messages before the user gets to see them. As such, we also abort a TOTP removal request if a login is successful during the grace period.
The bet we are making is that either some notification will reach the user, or they will check their account at some point during the grace period.
Removal implementation
Rather than having to trigger a piece of code after 30 days to decide whether to remove the TOTP-code, we instead represent the data for TOTP as two columns: totpKey, totpDisabledAt. If totpDisabledAt is in the past, we consider TOTP as disabled for the account.
NOTE: we might want to consider an alternate design for totp that requires some validated proof from the client that TOTP is not enabled, such that an attacker who compromises our db cannot simply disable TOTP for any user.