Expiration for Convenience Unlock about strongbox HOT 23 CLOSED

I googled around a bit and found, that you could maybe set the thisdeviceonly-flag for all data stored by strongbox.

It doesn't really keep the things on the device but see also the comments to that answer.

The pins sure are just convenience things, definitely. I'm just trying to navigate the line between convenience and paranoia in a hopefully optimal way.
I'm trying to think of ways to attack strongbox and feel like if all traces of easy access (like pins) to the safe are lost after some time passes that makes it stronger.
To make it more convenient one could skip the second entering of the convenience pin when setting it, as getting it wrong just means one has to use master credentials one more time.

from strongbox.

I still think expirable pins would be nice, but also not super important.

To topic:
There is a way to keep convenience pins and actually enhance security to a level where having access to the keychain is still not enough to open the safe.
I think this is relevant because you never know whether the keychain is actually safe, see e.g.
here. The vulnerability in the article is on macos only, I just mean it to show that serious bugs in keychain software are not something of the past.
To proof convenience pins against a keychain hack you could store master credentials in the keychain, but symmetrically encrypted with the pin.
Then an attacker still needs to break the encryption of the credentials after accessing the keychain.
Ideally you would use a strong key-derivation function like argon2, as the pin is probably low entropy.
An issue with this is, that strong key-derivation takes time wo opening a safe with the convenience pin would take longer because you spend the time decrypting the credentials and then decrypting the actual safe.

from strongbox.

Adding my support for a timeout. My use case is FaceID + PIN on a password and keyfile protected database.

I would also like a timeout that purges the password (and keyfile) from the app. After the timeout, the database password would need to be re-entered. As far as user interface, I've seen another app where the share sheet (after timeout) states: "Please re-login using the app, and has a link (button) that launches the full app." I don't know if this will work for Strongbox / the iOS password UI.

Perhaps the Strongbox credentials (password, keyfile) can be purged automatically from the iOS Strongbox keychain. Ideally, the timeout is configurable.

If timeout is not configurable, could/does the Strongbox keychain mirror the Face ID specs (Per Apple's Face ID security guide):

You can always use your passcode instead of Face ID, and it’s still required under the following circumstances:

• The device has just been turned on or restarted.
• The device hasn’t been unlocked for more than 48 hours.
• The passcode hasn’t been used to unlock the device in the last 156 hours 
 (six and a half days) and Face ID has not unlocked the device in the last 

  4 hours.
• The device has received a remote lock command.
• After five unsuccessful attempts to match a face.
• After initiating power off/Emergency SOS by pressing and holding either volume button and the side button simultaneously for 2 seconds.

Purging the password (and keyfile) on power off/on and the panic gesture (hold volume and side button) would be sufficient for me. Adding a timeout, is better. Currently a power off does not clear the credentials.

from strongbox.

Thanks for your input @gsharratt

The way I think I want to tackle this is by using the new Secret Store I've built for exactly this sort of expiry situation. It's currently in use on the Mac and seems to work well. The underlying library is the same as on iOS, it's just that on iOS I haven't introduced the ability to set the expiry.

So here's how I think it will look when implemented...

When you are prompted to enable Convenience Unlock (Touch/Face/PIN) (e.g. when you first open your database) you will also be given an option to specify an expiry. The options will probably be something like a slider with options for

• On App Exit (including Device Power Off)
• Timed from 1 hour -> 2 months
• Default of 2 weeks

When convenience unlock expires, full master password re-entry will be required with an explanation that convenience unlock has expired. When you re-enter correctly convenience unlock will be re-enabled with the same expiry as you had chosen initially.

You will be able to change this expiry in the Database Management section of the app.

I think that key file removal on expiry is out of scope for this issue, if that's something that you'd like to see considered, I'd ask that you open a separate issue.

from strongbox.

My usecase is paranoia pure and simple.

I use neither touch id nor face id because security people say, they are easy to attack. In addition its easy to force you to authenticate with them. i guess this is another case of paranoia.

To the case at hand:

I feel uncomfortable storing my master credentials permanently on the disk, only secured with my relatively weak pin. I guess this is mitigated by storing them in the keychain, but this opens up the possibility that they are transferred to servers and stored indefinitely.
But I think i have to think on this a little further.

Oh, by the way: can you disallow uploading keychain entries? I would be in favour of that.

from strongbox.

@eike-f you can disable keychain uploading system wide but not on a per app basis afaik. Again, these convenience unlock methods are just that, convenience methods. If you choose to use them you are likely reducing the security of your database. This is a trade off that the user must decide on. I do use them, and feel the compromise is ok for my situation. If you need that level of paranoia, I think it's best if you don't use the convenience methods at all.

The idea of an expiry on convenience pin seems like an edge case to me tbh, but I'll leave this issue here, perhaps others have strong opinions on this.

from strongbox.

I have no thoughts on whether we should have an expiry time on a pin or not, but you keep mentioning that this systems are for convenience, which is true.
They reduce security when compared to the master credentials sure. However when used in conjunction with one another, Touch ID and pin, that in fact increases the convenience security somewhat.
Two factors are now needed. In my opinion this is a great benefit.
Implimenting feature such as expiring pins, requiring the pin passcode to be entered in order to disable the pin, maybe enabling alpha numeric pins instead of just numeric - these things can increase the security of the convenience methods so they become more viable.

My master credentials are incredibly annoying to type in on a smartphone. They’re so secure to prevent someone downloading my safe and brute forcing it off line.
This isn’t so important a consideration for gaining access through this app on my personal phone. These convenience options are a very good idea, and it wouldnt hurt to mitigate the few holes that remain where possible.
There are many use cases for many people, and Keepass is the home of the most paranoid and secretive people!

from strongbox.

The longer I think about this, the less I'm certain, I'll pose a few questions below, whose answers may convince me to find this request over the top. If so, I would write them up to feature in the faq, if @mmcguill would like that.

My reasons for this feature request are these:
It seems to be incredibly hard to get encryption and security in software right. For this reason I have not so much confidence, that strongbox can't be tricked.
Please don't take this as "You are probably a bad programmer", because this is not about you specifically but about any security-related code by anyone.

At the moment users of strongbox, that use convenience pins must trust the security of

1. the kdbx file format
2. the strongbox code that keeps the master credentials from anyone who doesn't have the convenience pin.

And this means indefinitely. There is no way around number 1.
If on the other hand, the stored master credentials would expire after some hours (Personally I would choose about 12 hours) or after the phone was turned off (whichever comes first), the trust in the strongbox code would only need to reach so far. So if my phone isn't hacked in the period during which my master credentials are still stored, the hacker will have to guess my master credentials.

For convenience the pin could be stored even after the master credentials are deleted. It already works this way, when the master credentials are changed on another device.

My questions are these:

1. What credentials must strongbox provide to access the master password in the keychain and how safe are they from being used by someone else or some other app?
2. What role does the convenience pin play in retrieving the master password?

from strongbox.

Hi @eike-f, There's a lot going on there, let me try to answer your specific questions:

1. What credentials must strongbox provide to access the master password in the keychain and how safe are they from being used by someone else or some other app?

This is managed by Apple's iOS, basically Strongbox has isolated access to it's own dedicated space "keychain" through an API, this cannot be accessed by other Applications. Both the PIN and the Master Credentials are stored in this Keychain under separate "keys". No other Application can use/access/view them.

2. What role does the convenience pin play in retrieving the master password?

The convenience PIN is just checked against the PIN the user enters, if it matches, Strongbox looks up the stored Master Credentials and uses them to open the your database.

I'm not sure I've answered all your questions but I hope that helps and feel free to ask further questions below.

I'm still quite unsure about the Convenience Method Expiry time, I don't hate it, I just don't see a great requirement or desire for it. We can keep the issue open here, and see if there are others interested or keen.

from strongbox.

Hi there,

To be clear, the PIN is not used in any sense to obfuscate/encrypt or determine the Master Passphrase/Credentials stored in the Keychain, and a simple string comparison is done before looking up those Master Credentials.
So in short, a go/no go is done on the pin in the same sense as the go/no go that is received from Apple’s Biometric (Touch/Face ID) system. So Biometric and/or PIN end up accessing the same set of stored Master Credentials.
There would be no security benefit to obfuscating/encrypting the stored Master Credentials with the PIN since anyone with access to the Keychain would already have access to the PIN and so the security of convenience methods (Biometric/PIN) is based entirely on the security of the iOS keychain.
Having said that, the iOS keychain is actually pretty good as mobile device secure storage goes. Only the signed Strongbox application on that device can request anything from the keychain.
Again though, it is up to you as a user to choose your level of security. Touch/Face ID can be faked, a PIN obviously provides a much lower degree of Entropy than a good Master Password/Key file, and though I’m not aware of any general weaknesses in the on device IOS keychain, it’s certainly within the bounds of possibility that there is a weakness/exploit that could be used by intelligence agencies/others that we are not yet aware of. This though is also true of all the crypto used by Password Safe/KeePass, though the general consensus is those algos are not broken/weak right up to this moment.

Hope that clears things up somewhat.

Thanks also for the compliments on the app, glad you like it.
-Mark

from strongbox.

Hi @jmichael2497, Yeah. I'm going on my own knowledge here too, but from my own reasoning this makes sense. If I were a hacker and I had access to the Keychain, all bets are off really. Any cryptography is based on a keyed deterministic procedure (to put it most broadly). If the key is stored in the same place as the ciphertext (master password), and you have access to that location (Keychain) then there's not much point in having the ciphertext.

I believe I'm following standard best practices with regards to the convenience methods (pin/biometric) but of course I could be wrong and I'm open to correction/improvements/suggestions. With regards to your questions however, I believe I'm correct.

Cheers for the questions, worth thinking through this stuff regularly.
Best,
-Mark

from strongbox.

Thanks for the input, all noted, and I'll try schedule this feature for the near future...

from strongbox.

I want to support the request for PIN expiration. Until that's available, I feel the need to log out of the app as soon as I finish using it, as I don't trust PIN locking beyond a short time.
I have no input on the guts of the implementation, only on the functionality. I like the way that LastPass has implemented the feature in their iOS/iPadOS apps. (Their settings page is awful but the functionality is there.)

• "Skip reprompt after login": 1 minute to 20 minutes -- no PIN/biometrics needed for this time
• "Lock options": immediately to 24 hours, or never -- use a PIN/biometrics during this time; after this time, need to log back in using master password -- (I think "never" should not be supported)
• "Auto logout": 1 minutes to 8 hours, or never – purge password and keyfile -- (I think "never" should not be supported)
• Also purge on app force quit

from strongbox.

@mmcguill Looks great except for one needed tweak IMO. I think "slider" means that I would not be able to choose both "On App Exit (including Device Power Off)" and "Timed from 1 hour -> 2 months". But I would indeed like to enable both those settings: when I force-quit any app I expect it to completely deauthenticate.

from strongbox.

I'm curious if your use case includes Face/Touch ID as your first layer of security. If so, adding an expiration setting to the PIN feature seems a bit overkill under my own assumption that most people probably won't use both biometric security combined with the PIN to open the database. If you are not using Face/Touch ID, then I can see the benefit for short periods of repeated access, but then you'd have to reconfigure that PIN and expiration settings every time you log in with the master password UNLESS the defined PIN and expiration settings persists within the database settings and is reactivated by logging in using the master password.

from strongbox.

Thanks for supporting my point but I do understand mmcguill, too.
In the end, whatever feature becomes part of strongbox must be coded by him, so the features should be reasonable.
As I don’t have a mac, I can’t really change the code and make a pull-request, otherwise I would give it a shot. Or is there a way i can program ios apps on linux or windows?

This weekend I am away from home and any computer. But after it I will comment further on this, hopefully convincing you.

from strongbox.

Bump?

from strongbox.

The convenience PIN is just checked against the PIN the user enters, if it matches, Strongbox looks up the stored Master Credentials and uses them to open the your database.

maybe this was oversimplified, but just to double-check... are you saying there is just a check for response of "true" before using a key that is sitting on the keychain waiting for the app to be told to just use it?

not being familiar with how it all works, but just from randomly reading around security techniques (from a very high level for the common, but technically inclined, folk) but...

i would imagine when the convenience pin is used, then the pin should just directly be used to generate a convenience key... the convenience key is used to attempt to directly decrypt the master password key... whatever the result of that is gets used to decrypt the password database before providing a fail, right?

that way it would slow down brute force attempts waiting for several steps to happen vs getting an immediate pin doesn't match, try something else (which is why it would be important to have attempt limits along with pin usage timeout before requiring the master password instead).

anyway, the convenience pin timeout seems like a logical thing to have, if there is going to be a convenience pin at all. the simplest system seems to be just keep the set pin saved for future re-use, but require the full master password after user configured x hours time (probably with color warning if it is set over 16hrs as not recommended, gotta sleep some time).

thanks for creating a handy hybrid to turn the debate of "keepass vs pwsafe on mac/ios" into "why not both?" cheers.

from strongbox.

seems like though i may not know enough yet to understand the answer...

my interpretation is that you're saying you are following standard recommended practices.

as long as that is the case, then that works for me, thank you for your time.

from strongbox.

Right, good idea.

from strongbox.

Any progress on this?

from strongbox.

@metronidazole - this is still planned but no progress has been made yet. Hopefully in the next 2-3 months

from strongbox.

This is now available as of 1.52.20 on iOS and has been on MacOS for quite a while. It can be set by:

Unlock Database > Database Settings > Face ID & PIN Codes > Require Master Password Interval

from strongbox.