Hardware token vs Fingerprint based software token

short: I'd go for the Hardware token.

Long version: First things first: People have proven that it is possible to tamper with fingerprints in multiple ways. Probably the most common way is to recreate it from a fingerprint with a printer, but there are more options. You can see some of them in the article 7 ways to beat fingerprint biometrics. There is a lot more than that though.

But also HW tokens have been proven "crackable". Its a little hard to tell from the little information we have. It really depends on the token. The much more important bit in this consideration (at least for me) is this: If your HW token's seed gets stolen, you can change it. In case your fingerprint (or its digital representation) becomes publicly available your options are pretty limited.

If it really uses the fingerprint to authenticate at the system this should be your consideration. But if this is used on your phone it might just really be a token that is in your phone and secured by the OS using the fingerprint reader to replace the password. In this case your phone is your HW token but it has no proper read protected memory such as the token (should have). In this case: I'd go for the HW token as well.

The fingerprint doesn't directly protect the token (it can't - we to date have no reliable way to consistently scan a fingerprint). The OS encrypts the token with your credentials. An API call into the OS allows applications to request the token which forces the user to re-authenticate.

So the risks on the mobile application come down to -

• How much do you trust the operating system on your device?
• (Related to above) How much do you trust the sand-boxing on the device to stop applications reading each others memory space.
• How much do you trust the application not to place the token anywhere accessible to other applications.
• How much do you trust the fingerprinting mechanisms to stop the phone/app being cloned (Personally I would view this as close to zero).

You also need to counteract this against how high is the risk? I.e. were the app mass exploitable would the bank cover losses? And are you a high risk target (for example a billionaire probably has a higher attack risk than average Joe).

For the vast majority of users I would argue the app when paired with a strong unique password should be viewed as secure enough. Were the app to be compromised the bank would likely take the hit and refund clients.

A hardware token in theory should be more secure - its effectively an airgapped system. For a private/public key system the private key never has to leave the device. However there have been historical issues with manufacturers design decisions and implementations.