Use Fingerprint Sensor instead of PIN

[cgebe]

From @rico666 on October 12, 2017 16:31

For devices that offer a Fingerprint sensor, allow the user to use that instead of a PIN.

Copied from original issue: PoC-Consortium/burstcoin-mobile-doc#31

[cgebe]

From @ElCarlosCZ on January 12, 2018 23:42

Why not add both? ;-) Im also voting for fingerprint support

[cgebe]

From @ndawad on January 14, 2018 19:31

Why not... Sound like a great idea

[cgebe]

From @harry1453 on March 4, 2018 13:11

I would be happy to work on developing this if the source code was out there.

[cgebe]

@harry1453 This will soon be the case!

[cgebe]

From @harry1453 on March 4, 2018 13:25

@cgebe Thanks!! Any idea of a timescale?

[cgebe]

A matter of days.

[cgebe]

From @harry1453 on March 4, 2018 13:37

Thanks! Would you mind letting me know when it happens? I am very keen to help out on this

[cgebe]

You will be able to find the repo in our github org in addition to an announcement on twitter!

[cgebe]

From @harry1453 on March 4, 2018 15:30

Thanks. On the actual issue, I understand the pin is not stored locally. This makes sense however if we were to enable fingerprint authentication either the pin would have to be stored locally to decrypt the passphrase (which is insecure) or the fingerprint data would have to be used to encrypt the passphrase, which would result in the user having to choose between using fingerprint or using PIN.

So the potential solutions are using an unencrypted copy of the passphrase and having the authentication at a GUI level only, keeping a plaintext copy of the pin in the application storage space, which is user-accessible on rooted devices, or some other solution such as this project, which could potentially allow us to store two copies of the encrypted passphrase: one encrypted with the PIN, one encrypted with the fingerprint. I will look into it!

[cgebe]

Hey, thanks for the suggestion. Im happy to discuss this. Take into account, that at the moment the passphrase is saved encrypted (AES) with the following key: sha256(pin + device.id). The pin is not saved at all and therefore needs to be entered everytime an authorized action needs to be executed.

In order to not change the current process at all, an option would be saving the pin or the key (sha256(pin + device.id) encrypted with a key based on a constant provided by the fingerprint sensor and save it in an additional field of the account object. I need to look into the fingerprint library in order to verify this possible solution.

Edit: fyi, i do not want to replace the pin with the fingerprint process completely, just offer it as an alternative.

[cgebe]

From @harry1453 on March 4, 2018 16:39

Edit: fyi, i do not want to replace the pin with the fingerprint process completely, just offer it as an alternative.

That makes absolute sense as a significant proportion of devices do not have fingerprint sensors.

Saving sha256(pin + device.id) encrypted with the fingerprint data sounds like it would work nicely, however the NativeScript (I gather from other posts around here this is what we are using) library has only this (line 112):

onAuthenticationSuccess(): void {
    resolve();
}

There are multiple branching options in that file but all of them end up with a true or false return value.

I suggest that we store on the device a separate copy of sha256(device.id) which allows for the functionality to be added and then we rely on a programmatic block to prevent bypassing the PIN. We could potentially increase security by using sha256(device.id + (walletNumericID)) to prevent direct theft of the wallet without access to the app first, however both of these are susceptible to attacks if the device is rooted, as this allows direct access to the application's private data directory.

Also, are you on the Telegram group?

[cgebe]

Sounds reasonable, i will look into this as well in the next couple of days. I would like have the fingerprint verification as an extension. So to say, it will somehow result in storing the pin or a derivation of the same encrypted in local storage. Unfortunately, by seeing your reference, the fingerprint library obviously cannot provide a constant footprint dynamically generated when touching the sensor (which would be the best case, to prevent an unhindered decryption in case the internal storage gets accessed or stolen by an attacker). I need to evaluate the options we have.

https://discord.gg/xenZTNw for direct communication. @cgb

[cgebe]

From @harry1453 on March 4, 2018 17:25

Thanks for your help. I would love to be able to address or help to address this issue when the source code becomes open.