Bitcoin Forum

What do you guys think about implementing a Quick Unlock feature in wallets?

The user has to decrypt it with strong password first, and then every time the user want to spend something, has only one chance to enter the last X of characters or any other shorter password, which decrypts the quick unlock key. If it was a failed attempt or it timed out, then the quick unlock decryption key is removed from memory.

A Keepass2Android password manager includes such a feature. By default, the user has to provide 3 last characters of a password in order to quickly unlock a database.

It is important especially on mobile devices, for whom wallets don't provide a decent security (only an easy-to-crack 6 digit PIN).

What do you refer as Quick unlock? Fingerprints?

Imo all those passwords, face recognition, fingerprints, etc add very little to wallet's security. They add something to privacy but that's all.

Just encrypt and lock your device using a strong pin or fingerprint. When you do so nobody will be able to hack it and use your wallet if you have your device lost or stolen. It is possible but highly unlikely.

That sounds unsafe to me. Quick, yes, but risky. Spending your coins by just providing, say, the last 3 characters of your password makes it much easier for anyone to sneak a peek at them while you're on it, steal your phone away, and drain your wallet.

For quicker spending, I agree with bitmover; facial recognition, fingerprint, or retina scanning are much safer.

For both of you guys I think he's referring to the pllogin part of things like banks where they ask you for random characters of your memorable information before unlock.

I'm kinda for and against this idea as for my uses of bitcoin I generally batch transactions into one large one and don't send more than a few a day. Adding a fast unlock ability might stop people from doing this quite so much...

Afaik it's done in hardware when you unlock the device as you open and confirm stuff on the device from then on but then it's quite a bit more secure.

that doesn't sound like a good idea. in normal circumstances your password is protecting an account in a centralized database which you could recover even if it were hacked by simply contacting the provider. but in bitcoin if your wallet is hacked your money is all gone and there is no going back. if such a feature existed in a wallet then it increases the risk of being hacked because it is simplifying the process of gaining access to the wallet which shouldn't be a feature at all. it is not supposed to be easy to "unlock" your wallet and that is a good thing.

Last 3 chars to spend money? Looks like brute force could get easier then. If someone can get a copy of your wallet and there's a tickbox saying 'quick unlock', it won't take that long before your funds are gone.


Then the problem is the wallet itself. They should allow users to add more numbers/ways to protect their wallet. Or is that not possible?

I don’t know why the comments above ignore this part.

It enables you to use strong passwords and yet quick access to your currencies with the ability to reuse those strong passwords when one of the conditions fails.

The problem lies in trusting Keepass2Android password manager and how safe it is, I noticed that they had not updated the code for several months, since being open source in addition to that may make you vulnerable.

The synchronization option will not be good, it may be better to rely on some solutions that do not provide a network connection (offline.)

The idea behind a 4 or 6 digit pin is that after X wrong tries, the app is either locked and requires a different (longer) password or the whole content is erased.
Obviously 10⁴ or 10⁶ possibilities is not much to bruteforce. But the fact that you only have 5/10/15 attempts is the key.

With 15 attempts and 1.000.000 possibilities, you won't be successful unless a stupid pin (e.g. 123456) is chosen.
Sensitive information also is not encrypted using that pin. The pin is used to access the encryption/decryption key. So simply gaining access to the wallet file and bruteforcing it on another device does not work.

And the encryption/decryption key usually is stored in a secure place (ios: secure enclave; android: keychain). Both are hardware backed storages for key material.
So, even with a 4-6 digit pin, it isn't simply possible to bruteforce your way into a wallet, assuming the implementation is done correctly.

You don't get the idea. It should be possible only once. If after the attempt the last 3 characters of your password are wrong, the master key is wiped from the memory and you have to retype the whole password again.

If that still sounds too unsafe, the user should have an ability to hide how many last characters of the password should be used and change the numbers of characters needed.

Look at Keepass2Android. It's beautifully implemented here.


True, although PIN could be replaced with quick unlock which uses X last characters of the password. And it should allow you only for one attempt before you'll have to provide a full password again.

It's harder to figure out last 3 characters of a password or more in comparison to PIN, and especially as you have only one attempt, this shouldn't break the security of your BTC.


It should allow only one attempt before the user would have to provide a full password again. And if you find yourself in danger, you should be able to quickly close your wallet so you need to enter a full password again.

Mobile wallets vulnerabilities lies in the seed generation, not in wallet interface.

It doesn't make any difference if you use a 40 digit password with special characters and facial recognition + PIN if a hacker knows your seed and can empty your wallet at any time just by inserting the seed in his computer.

True, although doing a function through the password in addition to other methods like OS crypto provider, date and time, uptime, battery state, signal strength, messages, phone calls etc. could improve security.

I'm not an expert in cryptography in any way - sorry if I'm wrong.

Biometrics alone are not a recommended authentication and probably won't even be used in the encryption process.

The accelerometer and other information can be used to get a random number (potentially more so than a computer as you have GPS capabilities expected and a more accurate clock on the phone imo).

I haven't seen a wallet for mobile that uses facial recognition and if you're on android especially, a key is encrypted with your main phones pin/password so as long as that turns off fast enough or you remember to turn it off whenever in a critical situation then you have 2 forms of encryption to crack (my pin is 18 digits for example which isn't too long but it'll take some time to crack).

The phone's PIN is for authentication purposes and for encryption in some cases.

If you want to protect data on your Android phone so it will wipe itself down after few times, look here: https://www.youtube.com/watch?v=NmaRe_l-PxU

Not sure whether your data is securely erased, but if you use with encryption, it's a godsend.

Biometrics won't replace passwords, and the problem is using passwords improperly and lack of decent key stretching.

Yes, the user has to decrypt it with strong password first, and then every time the user want to spend something, has only one chance to enter the last X of characters or any other shorter password, which decrypts the quick unlock key. If not, then the quick unlock decryption key is removed from memory.

That's what I meant, perhaps I wasn't able to explain it accurately, because I'm a noob when it comes to cryptography.

The security with this approach heavily relies on the implementation.

What i am most concerned in is, where is the decryption key stored so that you can access it with entering only the last 3 chars.
1) If it is in memory and only used by the application if the 3 chars are correct, that would be prone to a memory dump. If someone would be able to gain access to your unlocked phone, he could, under given circumstances, extract a RAM dump to access the key while there has not been a wrong first attempt entering it.
2) If it is encrypted using a key which is encrypted with the 3 chars this should be fine. But this also means that the encrypted key has to be deleted securely after the first failed attempt.