2-factor ~~auth~~ code seed support

[david-shortman]

2 factor code information should be strongly associated with a password entry like is done in other password managers.

This would support best-practices for users, encouraging them to use one-time codes.

There are some great ways to expose this feature in the client apps, but this would be a core feature change to have entries hold something other user/pass/fields.

[david-shortman]

One feature this can enable in clients is copying the 2 factor code to the clipboard after autofilling the username and password.

[perry-mitchell]

How would you propose creating MFA for this core library? There's no built-in server, so there's no authority... Due to that, I don't think MFA can be implemented entirely in the core.

Each service needs to provide MFA ultimately - Our hosted my.buttercup.pw service will support MFA, for instance.

[david-shortman]

I don't know the terminology completely, but what I'm proposing is the app stores the seed/timestamp thing that is used to generate periodic 6-digit codes every 30 seconds in many popular 2-factor schemes.

For instance, in 1Password, I can scan a QR code or enter a code for an account to start generating 6 digit codes that I can use for that account during 2 factor login. This doesn't appear to require 1Password having any internet connection or relationship to the site that generated the seed.

[david-shortman]

The buttercup mobile app already has some infrastructure for storing the seed/timestamp stuff for the codes, but I'm suggesting those should not be a separate record, but a core part of what an entry represents. Then every buttercup client would need to be able to calculate the code based on the record/display it in some way.

[david-shortman]

I'm definitely not in the loop of what buttercup's plans or philosophies are around entries. I do think that these 2 factor codes are so integral to the notion of accounts these days that simply having username/password/freeform text fields may need to be expanded for use cases such as this.

[perry-mitchell]

the app stores the seed/timestamp thing that is used to generate periodic 6-digit codes every 30 seconds in many popular 2-factor schemes.

The fundamental issue with this idea is that the "app" can store something. It cannot. The app is not secure, by itself - it's running on someone's computer, phone.. in their browser. There's no way to trust it - no authority. You need trust - the authority - to manage MFA processes. I'm not aware of any way to do this securely, offline, in NodeJS etc..

in 1Password, I can scan a QR code or enter a code for an account to start generating 6 digit codes that I can use for that account during 2 factor login

This is because 1Password operates a service where you can most likely authenticate with. I mean the idea is just that there is some secret "key" to unlock your vault - and to get that key, to can obsure it behind MFA/2FA. For this to be possible, a service needs to act as the MFA validator, holding your secret key. Otherwise the key is just stored locally, and is of no more benefit than just your password.

Buttercup's vaults - File / Dropbox / Google Drive / WebDAV - do not have any authentication server (in common) that could provide MFA support. In the near future, like I mentioned, My Buttercup vaults will support MFA, because they're managed by a service which is then capable of what you ask.

The buttercup mobile app already has some infrastructure for storing the seed/timestamp stuff for the codes

The mobile app supports OTP (TOTP) generation by protocol. You can add TOTP codes from anywhere to the app - These also work in the browser extension. These are offline, but provided by a service.

That's all MFA usually is, right? I mean, disregard the SMS based 2FA systems - the QR-code and one-time-password numeric (six or eight digit codes) prompts require the client to have the OTP URI, to get the time-sensitive code, and a server (which has the same OTP URI) to validate the user's provided code. If we tried this in an offline fashion, the OTP URI would be available in memory and allow an attacker to simply bypass it.

I hope this makes sense.. I don't think there's any secure way to increase bcup vault security using MFA besides using our hosted service (where the vaults are stored internally as well).

[perry-mitchell]

I'm definitely not in the loop of what buttercup's plans or philosophies are around entries

Entries are just representations of a secret. It can be a login for a website, an SSH key, a credit card. Some might have URLs, some only a username and password, some might have TOTP URIs and time-sensitive codes. Buttercup aims to not restrict this too much. Entries are not related to how you authenticate with Buttercup vaults - that's a different matter, which I've been discussing here :)

[perry-mitchell]

I'm going to close this for now, as I believe I've elaborated on the reason why this isn't possible with the platform as it is. If a new avenue of thought opens up with how this might be applicable, I'll happily reopen.

To recap:

• my.buttercup.pw will support MFA
• All other Buttercup vault types do not support MFA, by design
• Buttercup entries can store many different data types, including MFA OTP codes

[david-shortman]

Thanks for this explanation, I definitely did not understand the implications of how other apps managed to keep OTP information secure locally. Seems like Buttercup is headed to be able to support the type of integration users from apps like 1Password experience.

(Selfishly I just want to be able to move off of 1Password to something open source. I'll be watching the client libs to see if there's a place I can contribute)

[perry-mitchell]

@david-shortman It's a big deal for us to support it - Can't claim to be a serious password manager without such an option 😅. Please let us know if you spot something you'd like to work on - we'd love to help.