Passcode anyone?

Some wallets like Mycelium has an application passcode which is different than the PIN+Biometrics protection provided by the operating systems. It looks like one of these:

Why passcode?

The rationale is that the users need a different level of protection when it comes to their private key. Naturally, that implies passcode is longer than the operating-system-provided PIN. In short:

  • PIN+Biometrics is for unlocking the phone to do the transaction;
  • passcode is for signing off the transaction.

Is passcode really needed?

I question that rationale. True, when it comes to financing, users need a higher level of protection, since it is no longer about privacy but about safety. It's one thing to close the door to prevent someone peeking what you are doing, another to lock it to deter burglars. But financing needs are better solved with a mobile-compatible hardware wallet. Is there the need for a middle level "passcode protection" between these two (PIN+biometrics offered by the OS and hardware wallet)?

Let's suppose there is such a need. Either because users are already trained to have different passcode for a different purpose (like China, where most bank cards have two PINs, one for checking balance and the other for withdrawing), or that current generation hardware wallet performed too poorly to fit for use on the go. Next question would be: how does it work?

How does passcode work?

First, from my intuition, when it comes to signing transactions, a user will either use operating system PIN+biometrics authentication or use an app-specific passcode, but not π‘π‘œπ‘‘β„Ž. That would be too confusing. Therefore, enabling passcode necessarily disables the use of operating-system-provided PIN+biometrics in the transaction confirmation. (The user might still need to lock the phone with PIN+biometrics at the outset, but not for confirming transactions.)

Second, although both passcode and PIN+biometrics are used at the moment of signing or backing up of the key, they are set-up in different occasions.

  • PIN+biometrics is set-up when the user first creates an address or recovers from a key-backup.
  • The passcode is set-up when the user first π‘π‘Žπ‘π‘˜π‘  𝑒𝑝 a key.

Why? Well, the wallet can't set up a passcode if it isn't sure that the user has written down the seed mnemonics by verifying that they can reproduce the sequence. The process of backing up is the moment that the wallet is sure of this, so it's a good opportunity to introduce passcode. If the wallet allows the user to set up passcode without the certainty of the backup, we may end up with the situation that the user can unlock his/her phone, yet forgotten the passcode and does not have a backup. In another post, I reasoned why there isn't such a requirement for PIN-biometrics.

Third, because the backup of seed mnemonics is specific for each wallet, the passcode, too, is for each wallet. It's possible to set up different passcode for different wallets. AlphaWallet currently only allows a single wallet to be active. There needs to be a table of statues for each wallet in the settings:

  • Wallet 1: not backed up.
  • Wallet 2: backed up, passcode set.
  • Wallet 3: backed up, no passcode.

And that is how I think passcode should be implemented if implemented at all. I do believe we will come back to this topic if we have not successfully implemented mobile hardware wallet by the end of 2019.

I am not sure it is a good idea nor that it provides higher security. Assuming the user has not been careless with a backup of his/her private key, then simply requiring the phone holding the private key along with biometrics already provides 2 factors, which is enough for high value financial transactions in the EU according to the new PSD2 specification*. Furthermore, even encrypting with an 8-digit numeric value will only add a slight hindrance in a brute-force attack. It could be argued that using a high entropy alpha numeric value could add more security, but I feel that unless significant iOS/Android bugs attacking the Secure Enclave comes out, the current approach without an extra passcode is sufficient.

*The β€œCliff notes” can be found here

Agree. Let's scrape off the passcode idea entirely.