Protect App with a Password

[MichiMunich]

A password protection (TouchID/FaceID) for the app would be great to protect the locally stored data or the configurations for the cloud data within Strongbox. With a configurable number of failed attempts to open the app, the local data or configurations will be deleted.

[mmcguill]

Not sure I fully follow you here @MichiMunich. Do you mean, some kind of immediate request for authentication before even showing the list of Safes/Databases?

[MichiMunich]

Exactly. It should be a pre authentication, so that without entering a password or TouchID no access to the password databases is possible.

[milesmcclane]

Yes I agree here

[mmcguill]

Ok, I never really considered this, but it should be straightforward to request Touch/Face ID authentication before even showing the list. Thanks for the details.

[milesmcclane]

Would be better if there was the option of a passcode/phrase to open the app then Touch ID for the safe, two factors are better than one.

[eike-fokken]

I second this idea. My favourite style would be that I can have the password safe open, but access to actually view it is granted only after one enters a custom PIN.
In this way I don't have to retype my really strong (and hence long) decryption password whenever I need a password but am still protected from someone taking my phone and looking at my passwords.
Ideally the password safe is locked again after three (or so) failed attempts to enter the PIN

[georgesnow]

Just to clarify you want there to be a passcode/touch ID for the app? Then subsequent authorization for the safes themselves? If so this kind of goes against the model of granting access using TouchID

if you are allowing touch id or your passcode to unlock the safe (which also includes your phone PIN because it will failover if touch ID fails). That really isn't 2FA. its just making so you authorize multiple times. And since the app allows per safe options for unlocking using Touch ID this seems moot and overly complicated. I can understand wanting to limit access, but if your phone pin is compromised those extra layers don't do anything. IF touch id is enabled for the phone, the app, and a safe. someone would just failover touch id to the pin. Then enter the same pin 3 times.

Maybe I am misunderstanding the objective here?

[eike-fokken]

Oh, I'm sorry,
I read through the thread but actually I meant to second MichiMunich:

Personally I dislike touch and faceid, because people can be forced to touch their finger somewhere and look in a certain direction.

My ideal solution is:
Lets call the password that encrypts the safe "passwordkey".
This is a strong password and hence cumbersome to enter into a smartphone.
Implement a new password for strongbox that can be chosen by the user, let's calll it "appkey".
This will be easier to enter.

Then when I start strongbox I have to open my password safe with the passwordkey.

Now whenever I go back to strongbox, the safe is open (unless the auto-close time is up) but I still have to enter the appkey.
Because I would choose an easy appkey, strongbox would close the safe after 3 attempts to enter the appkey.

I think its appropriate to make an option to replace the appkey with faceid or touchid but it's important for me that I can also choose to use an actual appkey for the reasons in the beginning of this post.

[georgesnow]

Ok, i get it. I thought maybe thats what you meant. And I have seen other apps that allow for authorizing using your password for the account (or safe in this case), but then give you the option to add passcode/password you could use to unlock for a set time frame. ie until a timer runs out or phone is rebooted. This would be taking it one layer deeper to apply the functionality per safe as well.

[eike-fokken]

Oh, again my bad:
I actually only use one safe. And if I used several I would not need the appkey per safe, but only for entering the whole app itself. I have no experience of programming for ios but I guess implementing it for the whole of the app is much easier than for every single safe.

[milesmcclane]

I meant something akin to standard notes, whereby you Touch/face ID to enter the app, then set a code to enter the note, which expires after a user set amount of time.
Then if someone forced you to open your phone with touch/faceID, then subsequently your Strongbox app, they would be presented with a further problem -a random code/phrase.
Of course this could be your actual safe password, but thats very inconvenient for some. This is a kind of halfway place, and of course could be optional.

Seems silly to have a password safe which is as protected as is possible by keepass, to then have it opened by a simple couple of Touch ID inputs with could be forced. This way could be a mixture of security and convenience.

[CzarlsOnGit]

Hi,
Last iOS 1.20.0 added pin codes feature,

• But I noticed that when Touch ID is enabled, pin codes not working
• I need to dis-enable Touch ID and then SB ask for pin codes,

So it work more like alternative to Touch ID?
Is it possible to make it work like addition to Touch ID?

So after correct Touch ID and Convenience PIN- DB opened
After Touch ID and Duress PIN- fake DB opened (or DB deleted- depend on settings)

BR

[eike-fokken]

Its cool that you integrate user requests so fast!
This is nitpicky but would it be possible to choose the length of the delay as a glider for minutes?

[mmcguill]

Hi @CzarlsOnGit , let me see, I'll look into making it work as both OR and AND with pin codes and touch id... Shouldn't be a major problem.

@eike-f I'll add it to the list...

[eike-fokken]

Cool, thanks!
Concerning the PIN locking the app (and even more so the convenience PINs) it would be good if a small number (3? Or if its no big deal, a number chosen by the user) of failed attempts to enter the PIN in question would lock all safes so that the encryption is in place again.
In this case I would choose a really long time for auto lock like 2 hours.

[eike-fokken]

Feature request:
Make the autofill feature also use the PINs.

Sorry, I just realized that the password safe pins do exactly that.

[CzarlsOnGit]

Hi,
Last iOS 1.21.0
Acc. to change log Touch ID AND PIN should work
However I found serious security concern:
Yes, I can protect DB with biometrics and PIN, however
If in app settings, I will turn off biometrics check (app not asking to confirm action eg. with biometrics), then only PIN is enough to unlock DB

[edit]
and when turned off PIN in app settings, then just biometrics is enough to unlock
I understand a Touch ID and PIN as some sort of 2FA, but with above it not work that way

[mmcguill]

Hi @CzarlsOnGit, ok, so you would expect that if Touch ID is turned off in phone settings, that the app should then revert back to requesting master credentials, rather than allowing log through PIN alone?

If so, that sounds like a fair request. I'll get it added into the next release.

[CzarlsOnGit]

requesting master credentials to change Touch ID or PIN options will be the best IMO

[mmcguill]

Oh I think I misunderstood you. I thought you meant if biometrics was disabled at the phone level AND the app uses BOTH Biometrics and PIN, then we should revert to master credentials (actually I still think this is a good idea, and will implement in next version.)

Also, allowing Biometric AND/OR PIN is by design. Some people will want Biometric Only, some will want PIN only, and some will want both. I think this is good, and allows people choose their preferred convenience setup.

But what I think you're saying is that we should ask for master credentials even after the safe has been opened? I'm not sure about that tbh. Once the safe is open, all bets are off, whoever has it has full access already to your safe at that point. There doesn't seem to me much value in re-asking for credentials? Maybe other people have strong opinions here?

[CzarlsOnGit]

Oh I think I misunderstood you. I thought you meant if biometrics was disabled at the phone level AND the app uses BOTH Biometrics and PIN, then we should revert to master credentials (actually I still think this is a good idea, and will implement in next

This idea i OK
2.
now in iOS 1.21.0, I like to have an option to open DB with Touch ID AND Pin (like 2FA), but if I turn off Touch ID OR PIN in app settings, then it is possible to open DB only with PIN OR Touch ID, so eg. PIN added to unlock DB will be enough to open DB
When I'm set up Touch ID and PIN, I need to be sure that both will be necessary to open DB

[mmcguill]

Yes, so if you turn off one of those methods then it won't ask you to use that method. This is by design. If you want to be sure that both are required, then yes, you need to enable both methods. You as the user control the convenience methods required.

Not sure if that answers your question, perhaps I'm misunderstanding something?

[CzarlsOnGit]

from user point of view, control login methods by setting is ok,
I was thinking more about second security layer

[mmcguill]

Ok, think I understand, and will address in next release. If user configures BOTH convenience methods and one (somehow, by config etc) becomes unavailable, require master credentials to open.

[eike-fokken]

For what it's worth, I'm with @mmcguill on both points here:

1. If I change the permissions from within the safe it's my own responsibility
2. If for whatever reasons convenience options can't be the way I configured them, fall back to master credentials.

[dbluxo]

@mmcguill Will the data be deleted after a few (configurable) failed attempts?

[mmcguill]

Hi @dbluxo, this is something I could look at with the addition (or return) of the App Lock screen. It could be that if someone enters the wrong pin 3 times, we could remove (or delete) all databases.

[mmcguill]

Just FYI, The App Lock is available now with 1.28.0. I'll close this off in a couple of days all going well. I'll create a new Github issue for deleting all databases on 3 incorrect attempts.

[Mukrosz]

Many thanks for implementing this. It was very much needed and now this is my goto app.

[eike-fokken]

Cool, thanks a lot!

[mmcguill]

Thanks for all the input everyone... created #121 to track database deletion on incorrect unlock attempts. Closing this one off. Please open new issues if you have any further requests.