Support for passwordless login (FIDO UAF, TREZOR Connect)

[slush0]

Specification proposes opening login dialog or using Kerberos. Are there any plans for supporting passwordless schemas like FIDO UAF or TREZOR Connect (https://github.com/trezor/connect#login) ? Removing the need of manual authentication would improve the user experience significantly.

Motivation: We're working on password manager using TREZOR device as crypto token. For such application, we would like to use cloud storage for storing encrypted blobs. RemoteStorage seems like a nice fit, but it requires login/password, which is deadlock - the password is stored securely in encrypted file :-).

FIDO UAF or TREZOR Connect offers easy and very strong way of authentication (no weak passwords anymore!) based on strong cryptography and challenge/response mechanism so I expect RemoteStorage backends would benefit from it.

[raucao]

Thanks a lot for your interest and question! I for one am actually a happy Trezor user and I'd absolutely love to see support for RS in addition to the current Dropbox sync.

Regarding login in RS:

• The remoteStorage protocol as such doesn't require a specific kind of login to servers. For authorizing access to (parts of) a user's storage, it is using OAuth 2, with the implicit (redirect) flow. This will return a bearer token, with which an app can write and/or read data to/from one or more base directories permitted by the OAuth scope requested. This is basically the same as Dropbox's OAuth, just with finer-grained scopes.
• The login for the user account on the server can be of any possible kind, incl. Trezor/passwordless. This is a responsibility of the server program/developer and is seperate from remoteStorage's OAuth authorization.
• Kerberos is an alternative to OAuth in RS, skipping all of OAuth (incl. the scopes) in favor of the client and server having negotiated their own auth. It is essentially replacing the entire authorization process. As such, the way it is implemented in our reference client is to just deactivate all auth-related features. However, this only works with servers implementing Kerberos as well as a RS API that uses Kerberos instead of OAuth tokens.

Long story short: the only login that is happening is for the user's RS account is that on the server itself, and the server can theoretically implement UAF and Trezor login in addition to the ubiquitous username/password.

In case you decide to support RS, I would even suggest to run a simple storage service yourself (with Trezor login enabled), so users have a good default that they can choose, when they don't have an RS account yet.

That said, I think it's always worth exploring other options in addition to OAuth (or even replacing it long-term). But at the moment it's a rather integral part of the protocol. I'd also be interested in what @michielbdejong and @fkooman think about this!

[ghost]

Current RS works "identity first", at least when using the widget, so you need to know your user identity at the remote storage server before the authentication of the user can be triggered. This is similar to using SAML for authentication, where the IdP (Identity Provider) determines the identity of the user. This does not really "fit" in the design of RS. In the case of Trezor this may not even be an issue... I don't know how Trezor works...

Does Trezor include/output anything that can be used to uniquely identity the user? In that case the Trezor ID could be used as the user identity, if not, it will need to be bound to an actual user account, and then using Trezor as a second factor (like U2F, Yubi, OTP) makes more sense I guess...

I'd be (very) careful by using biometrics for authentication (as the only factor), as a fingerprint should (must?) be considered equal the a "user name" and not to a "password".

That said: for your particular use case, RS may be overkill, if all you need is a blob storage, there are easier ways to accomplish this in 50 lines of code, it may be better and smarter to roll your own to limit the dependencies and lines of code of your solution, less is more, especially in security products...

[slush0]

@skddc Thanks Sebastian on writeup! I'll think more about integrating OAuth2 impllicit flow and how to integrate it with TREZOR. What I like on UAF/Connect is the solutions are completely server-less, there's no need for any kind of identity provider etc. Which is match to RemoteStorage idea, afaik. It could be possible to hack Connect around OAuth2, but it adds some complexity. Okay, I'll dig into specification and maybe I'll find some nice way!

@fkooman Yes, TREZOR can identify itself in anonymous way - it can generate the unique handle (public key) and provide digital signatures for given identity on request. That's exactly how login over TREZOR Connect works. Things like fingerprints etc are out of our scope for their low entropy :).

Francois, you're right that RS seems an overkill for our specific use case; we're writing blob storage for short key/value pairs ourselves; considering all data are encrypted anyway, there's no need for any kind of authentication, which makes it pretty easy task. However, I dislike it is proprietary solution and I'd love to give people freedom of choice, where to put their persistent data. For such thing, project like RS is a good fit.

[raucao]

@slush0 I'll be hanging out at HCPP again this year. Just ping me in case you wanna talk about it in person. Would be interested in your findings.