Using DID as a Second-factor Authentication
Two-factor authentication has become the de-facto method for authorization. Currently, the best-known and well-used second-factor authentication methods are:
- Email 📧 (proof of email ownership)
- SMS 📞 (proof of phone number / SMS ownership)
- Time-based one-time passwords TOTP 🕐 (mostly through Authenticator mobile applications, as Google Authenticator, Duo Mobile, etc).
How do TOTPs work?
In the third option, a server creates a secret for your account. When your device connection is established, it shares that secret set of numbers/characters (usually in the form of a QR code as otpauth URI) with the Authenticator application. In turn, this application uses that secret and timestamp-based counter to generate the OTP.
When a user enters the OTP generated by the Authenticator application, the app that is authorizing the user sends this OTP to the server to verify it. This is the same as the application (since both have the same shared secret) and it just checks if the result is the same.
SMS, in the current state, is considered to be deprecated due to several weaknesses (NIST post on this).
While the authenticator applications may seem like a better alternative to SMS, they also have many limitations, not to mention the potential for attacks as well: Also, there’s a possibility for the secret generated by the server to get hacked or leaked.
Further, the backup option services often offer backup codes instead of requiring saving that secret and this means that accessing the backup codes can compromise the authorization process.
Given these limitations, DID could be a good option as a second factor of authentication instead of SMS and TOTPs.
DID as a Second Factor Authentication
You can use your DID as second-factor authentication.
First off, you can provide your DID instead of disclosing your phone number or email ID as the second factor of authentication. In the second step of verification, you will have to prove that you are the owner of that DID provided during the initial setup.
To make this happen, the service on the second step of verification can provide a challenge for your user/did using the URI structure.
For example, it can be something like this. didauth://signature?challenge=auth_pmhibhlsjqfjaorz4ja9&ttl=30&callback=https://github.com/multifactor-auth-did
didauthis the name of the protocol/standard (so an app/wallet will know what to do and accordingly, support it).
signatureis the type which the Client/Wallet has to prove.
challenge— is the challenge for the Client to use (in this case — sign).
auth_prefix value is designed to prevent a possible misuse.
ttl— is the “time to live” of this challenge and is expressed in seconds.
callback— is the server endpoint to which the proof must be sent.
This URI could be presented as the URI itself or as a QR code for the user on the web verification step screen. In your identity wallet app, you can scan this QR/post the URI, so the wallet will be able to recognize the protocol, sign the challenge, and send it back to the server callback URL. The server will verify if the signature for the challenge is done by the proper public key of did, and if yes, it lets the web user log into the system.
With this approach,
- You can use your one digital identity/DID as the second factor auth for any service. (no need to setup/add each service separately)
- The services are not storing your secrets (It is only keeping your web3 wallet safe at your end device).
- No secrets are shared to set up the connection.
- No backup OTPs (In this case you need to backup only your DID).
- Low cost to add support at the service side and become crypto/web3 friendly at the same time (potentially to get even more traction from users).
- Thus, a simple, yet effective way to authenticate your users!
What do you think?
Reach out to us in Discord if you have any questions.