photon-sdk / photon-keyserver Goto Github PK

The user should be able to provide google authenticator as a fallback to their mobile phone number in case they lose their prepaid sim card and are unable to get a replacement from their mobile service provider.

This would be the most secure authentication option (compared to email and sms), but would likely be the most complex to implement in an easy-to-use fashion as backup codes are usually a best practice in case users lose their GA devices (which will likely be the same as their mobile phone, containing the SIM card).

From threat model doc: "In the case of a prepaid SIM card this might not be possible. For this case the user should be able to provide a fallback 2FA method such as Email and/or Google Authenticator."

Wallet devs should be made aware of this so they can design their wallet and use the API accordingly.

The user should be able to write down a randomly generated Recovery Code that can be used in case the user has lost access to their 2FA methods (phone number, email, Google Authenticator) or forget their PIN.

This should be optional and available post onboarding e.g. in the wallet's settings.

This concept would be comparable to Apple's Recovery Key used to reset the Apple ID password or 2FA methods: https://support.apple.com/en-au/HT201487

The user should be able to provide an email address as a fallback to their mobile phone number in case they lose their prepaid sim card and are unable to get a replacement from their mobile service provider.

1. Add PIN support which requires client to supply a PIN as part of authentication to access data stored on keyserver

2. Should be optional and determined by client

3. PIN digit size could be configurable by client (perhaps 4 digit minimum? 6 digit default? Should there be a max (beyond max integer size)?

Users might want to use physical security keys like the YubiKey. Related to #7 as backup codes would be required. We might get around backup codes though if users setup multiple hardware keys or have many fallback methods (SMS, Email, and Google Authenticator).

Ideally clients would be notified in the case of a data integrity or data breach issues, so that the client could re-backup the private key from the phone or rotate keys.

Unclear to me if this is some kind of push notification model or a polling mechanism in which case the design guidelines for the client would be to check every time the client app is opened or runs on the CPU.

Add a time delay that helps mitigate SIM jack and cloud account attacks by giving users time to respond.

Similar to Coinbase Vault 48 hour delay:
https://help.coinbase.com/en/coinbase/getting-started/other/vaults-faq.html

or Casa 7 day delay:
https://support.keys.casa/en/docs/201-the-recovery-key-in-keymaster

Allow client to optionally configure a time delay of N (hours, days, etc.) before the server provides the client with data upon successful authentication.

Successful authentication could mean different things:

1. It could be verified SMS and PIN
2. Or just verified SMS (a wallet design might want to require the user to either enter a PIN or wait, say, 7 days)

Send user multiple notifications during the N time window.

As the user could very well not be receiving SMS messages if they've been SIM jacked, consider also adding the ability to store an email which can receive notifications too.

To mitigate brute forcing of the verification code (sent via SMS) a time delay should be added between authentication responses from the key server. This should also apply to the optional PIN.