-
Notifications
You must be signed in to change notification settings - Fork 48
PIN Transactions
As an additional security measure, the user can require a 4-digit PIN code to be entered to submit a transaction to the blockchain.
The personal identification number has been the key to flourishing the exchange of private data between different data-processing centers in computer networks for financial institutions, governments, and enterprises. PINs may be used to authenticate banking systems with cardholders, governments with citizens, enterprises with employees, and computers with users, among other uses.
In common usage, PINs are used in ATM or POS transactions, secure access control (e.g. computer access, smartphone access, door access, car access), internet transactions, or to log into a restricted website.
In addition to data protection, our customers also requested PIN codes as a way to restrict access to their Divi information on a shared device, with a common scenario we heard involving a device that is shared amongst family members. Obviously, the parents wouldn’t want their children accidentally modifying their Divi wallet, so having a PIN code seems like a logical way to solve the problem.
- That users have used PIN codes before on their mobile app in order to lock access to either the phone or apps.
- The PIN code would be set to work in a few ways, and this could be adjusted in settings.
- Unlock the app
- Be required in order to send funds
- Open locked wallets (with masked amounts)
- Require PIN after time-bound auto-lock - Require PIN after specifies how much time can pass while the Divi app is idle before the app locks itself and requires the PIN. Allowable values are none (no locking), 1, 5, 10, and 30 minutes. This policy is only enforced if a corresponding PIN Length is configured.
- PIN Length setting - PIN Length sets the length of the identification number. The length can be from 4 to 8 digits.
- When a user of an application or website attempts to sign in after a long period of inactivity, a mobile phone verification process can help ensure once again that your user is genuine and not a hacker or spammer.
- Transactions require SMS OTP - Confirming transactions with real time communications significantly reduces costly fraud. Requiring authentication of users at this critical moment via mobile phone verification is so effective at reducing suspicious activity that many payment and e-commerce applications and websites now require authentication of transactions with a one-time password (OTP) sent via SMS.
- When a user logs in to an app from an unknown or alternative device (i.e. with a different IP address from the one registered in their profile) and requests a password reset, sending a code via SMS to verify the user’s identity can help reduce fraud and identity theft. For example, Gmail uses this process to verify your identity via your mobile phone number whenever a login attempt originates from an unknown device.
- One scenario is someone snatching an unlocked phone out of the users hands while I'm in public. Then having access to their Divi wallet and being able to wipe out their wallet.
- Enable Reset of PIN by Backup Phrase only - This 4-digit PIN will not be recoverable as it will be encrypted on the back end and not stored in a central server. It can, however, be reset if the previous PIN or mnemonic backup phrase is known by the user.
- Encrypted PIN - Simple backend password encryption should be implemented to mask the PIN from any unauthorized users.
The PIN-based flow is implemented in the same exact way as Implementing Sign in with Twitter and 3-legged Authorization, with the only difference being that the value for oauth_callback must be set to oob during the POST oauth / request_token call.
Once your application has obtained either a GET oauth/authenticate or GET oauth/authorize URL, display the URL to the user so that they may use a web browser to access Twitter.
When an oob callback is requested and the user visits Twitter, they will not be automatically redirected to the application upon approving access. Instead, they will see a PIN code, with instructions to return to the application and enter this value.
This feature will fall under the umbrella of security testing, which should be a rigorous process done by a third party. For this feature specifically, testing will include attempts at decryption by an outside party.
No application feature exists in isolation; if you offer customer support to your users, then giving your customers additional powers necessitates supporting them in the event that those powers are not correctly used. If we implemented PIN codes in the Divi app, what happens if the user forgets their PIN? How would they regain access to the application? If no additional functionality were implemented, the user would have to delete, then re-download the Divi application, log back into their account on the app, and finally create a new PIN to resume their work. This is obviously not a user-friendly workflow – would the user know that they had to delete the application to regain access, and that doing so would not delete any of their data? Would confused users reach out to Divi customer support, or simply stop using the app altogether?
Looking at the above scenario, our default solution creates its own problem: being able to regain full access to the app after deleting it renders the entire PIN code feature moot. A thief that knew the customer’s Divi login credentials could simply delete the application, then reinstall it to gain access to the customer’s information. As such, the right thing to do would be a user-invoked PIN-reset mechanism in both the application and a server-side component, analogous to mechanisms for resetting a password for a website. The PIN code would need to be stored on a server and associated with the customer’s account or device, so that when the app is reinstalled the PIN code would still need to be entered. This greatly increases the scope of the feature, however, and also increases the testing effort to detect any vulnerabilities that the mechanism may have. The other issue is that it now makes a centralized solution.