Sync Device Two Factor Authentication

[afshawnlotfi]

Problem Description

If sync code ever got compromised all account data could be at risk. Traditionally other services have two factor authentication to prevent access.

Feature Overview

After user enters sync code they will be prompted with additional two factor option to enter sync chain

Implementation Details / Design

Once user enters sync code this code is looked up with an account which has a TOTP token associated with it. The user is sent back a session token from the server. The user will be prompted with a two factor menu. Either the user enters TOTP directly from a phone app or notifications are pushed to a sync devices to Accept/Deny and if accepted TOTP token will be generated on their end and sent back to client. Once TOTP code is received it will be sent to sync server alongside the session token to be authenticated. Once authenticated normal sync functions will be granted.

User Experience

Idea 1

1. User tries to create a new sync chain
2. User enters sync code
3. Sync Devices receive notification of device to be added (/w its Public IP Address)
4. Sync Device can approve device to be added into sync chain

Idea 2

1. User tries to create a new sync chain
2. User enters sync code
3. User is prompted with two factor 6 digit code to enter from authenticator app

[iccub]

Very nicely written feature request, thanks. Passed it to our Sync team to evaluate

[jsecretan]

Thanks @afshawnlotfi for the well written request. We'll see when we can work it into the backlog.

[fmarier]

I'm trying to understand better the proposal here. TOTP requires a secret key to be shared between the server and the client (typically that secret key is encoded in a QR code). I assume that the server would generate a random key when the first device creates the account and then return it to that first device?

How would the second device get a copy of the key so that it can generate the same TOTP codes?

[afshawnlotfi]

I'm trying to understand better the proposal here. TOTP requires a secret key to be shared between the server and the client (typically that secret key is encoded in a QR code). I assume that the server would generate a random key when the first device creates the account and then return it to that first device?

How would the second device get a copy of the key so that it can generate the same TOTP codes?

You could store the TOTP key in Brave Sync similar to the way Passwords are stored and all the confirmed devices can get it from that. You would need to add a storage element for that to the Chromium Sync Server that Brave uses for Sync to differentiate the TOTP token from Passwords.

[fmarier]

But the second device needs the TOTP key before it can access the Sync account, no?

[afshawnlotfi]

But the second device needs the TOTP key before it can access the Sync account, no?

Ah I see the question now. So I'm not familiar with the current Brave infrastructure for authentication, but traditionally the TOTP key is looked up by account username or in this case the sync key and the code is generated and compared to the code received by the second device trying to login. In the case of the current Chromium Sync Server it would need to be extended to be able to do this lookup and compare.

Idea 1 does a two factor code handoff if the new device is approved on a trusted device which is why the devices themselves would need the key, however, if Idea 2 is used then only the central server would need the TOTP key.

[fmarier]

Ok, I see what you mean now. It turns out that the existing Brave Sync design doesn't have a separate authentication step (where we could add 2FA for example). The key that is inside the Sync QR code is used for both encrypting the data and authenticating with the server.

That was a deliberate design choice in order to avoid our knowing anything about our users (e.g. their email address or a username). It seems however that many users would prefer to see a more forgiving/traditional account-based system where extra security controls are possible. Of course, we'd want to keep such a design end-to-end encrypted still.