Does strongbox support separated database for OTP?

[yur1xpp]

I recently researching on migrating my OTP plugin (keepass database), and came across KeePassOTP. Interestingly, they have two approaches, one is embedded in the entry itself (the classic approach), while the second is creating a separate database for OTP storage. More information on their wiki. My questions is, does strongbox have this support at the moment, if not, will there any consideration on this second approach? Seems like this might be an extra layer of security for OTP.

Thanks!

[svn2208]

I just want to emphasize to have OTP in your password manager is a security risk. A second factor shouldn't be saved together with the first factor.

[strongbox-mark]

Hi @yur1xpp - Yes, Strongbox can have multiple databases (no real limit). You could set one of these up to be a dedicated TOTP database.

You could then switch the Browse View to "TOTP" mode (Customize View) which shows the TOTPs in large text. You can also set it to Copy the TOTP on Tap (Customize View > Tap Actions > Copy TOTP). I believe many people are set up this way.

As @svn2208 said, best practice recommends you keep your TOTP codes separate from your regular passwords.

[yur1xpp]

Hey Mark thanks for the reply, it seems like their approach is an embedded database inside the main database, but AFAIK strongbox does not supports this kind of approach, am I correct?

The advantage of such approach is that it's an embedded database, and everything is automated when creating/manage the OTP key using the plugin (we don't need to fiddle with two separate database). We could use two separated .keyx too.

As you suggested, two completely separated database works as how it is, but it's a two independent database, making creating/management of OTP another effort. Hmmm.

[strongbox-mark]

I'm not sure that they have an embedded database, rather the TOTPs are "embedded" in the individual entries, if I'm not mistaken. That's approach 1, and we support that, you can have a TOTP inside any entry. We do not support embedded databases.

For approach 2, they have some kind of auto open setup/system for a second database, so while we do support a second (or more) database for TOTP, we don't have any automatic or streamlined auto open of that database from the first.

[tchatow]

This is a somewhat different feature, but I'm wondering whether it might be possible to cache TOTP entries under a lower level of security - ie. pin for full database unlock and face ID for TOTP. These would be displayed underneath the database list to save a click with multiple security options:

• No security: TOTP entries immediately visible on opening the app, tap to copy
• Locked: Entry names shown; **'s in the place of the OTP, tapping to copy would prompt for auth
• Hidden: Entry names hidden as well, tapping would prompt for auth and then entries shown and copyable

Entries would be concatenated from all opted in databases (or perhaps opt in on a per-entry basis).

This use case is relevant when logging in on a separate computer and getting 2FA codes from a phone, so the full database wouldn't already be unlocked.

[strongbox-mark]

I think this is a separate feature, and I'll open a separate issue for it now and reference back to this issue... I think though for simplicity's sake I would only consider your first option:

No security: TOTP entries immediately visible on opening the app, tap to copy

If you choose to opt in to this feature then we would show TOTP codes with the entry name on the home screen. You can always enable App Lock if privacy is a concern here. Since the codes change every 30 seconds and we wouldn't display the seed, we would follow other TOTP clients in displaying the codes upfront. If this is an issue, then we would ask users not to opt in.

Within databases themselves, you can choose to mark a TOTP code as "Display on Home Screen" so that you can choose across databases and select individually which TOTP codes to show upfront.

The storage for the seed/settings would need to be external to the database, e.g. (Secure Enclave) (which some users may not want) and therefore this would be an opt-in feature only.

As a sidenote, this may also be useful for those with Apple Watch if Strongbox finally gets around to implementing a Watch app...