[RFC] Proposal: integrate 2fa and webauth into KDE Connect

Matthijs Tijink matthijstijink at gmail.com
Fri Apr 27 12:45:37 UTC 2018


Hi Mayeul,

Sounds useful to have! Do you have time to work on it yourself? I expect that 
none of the developers really have time to work on this (at least for some 
time), but we can definitely give feedback and answer questions.

Otherwise, please file a "wishlist" bug report so we don't lose this (quite 
detailed) explanation.

Kind regards, Matthijs Tijink

Op zondag 22 april 2018 13:42:18 CEST schreef Mayeul Cantan:
> Hello,
> 
> I would be interested in seeing some 2fa elements making their way
> into KDEConnect.
> 
> I am not too interested into protocol implementation details, or very
> specific behaviour for now, just into some basic workflow.
> 
> Firstly, the basic authentication (one time passwords/time-based one
> time passwords) mechanisms such as the ones offered by Google
> authenticator (https://en.wikipedia.org/wiki/Google_Authenticator)
> could be implemented, and integrated into the app.
> 
> Secrets would be stored globally, and a new menu, "authentication"
> would appear for each connected device, with the same elements inside.
> Tapping a code would send it as keyboard events.
> 
> Secondly, this might be more interesting, future-proof and user
> friendly, although not widely deployed yet (supporting this would
> obviously put KDE Connect on the edge here): Webauth.
> 
> Webauth defines a specific set of APIs that can be used to ask browser
> for cryptographic proofs of identity. It seems to be a well-thought
> standard.
> Of course, we're no web browser. I am suggesting KDE Connect could act
> as a store for secret keys on the phone, or as a gateway to them
> (ideally, these would reside in the TPM if the phone has one, or any
> other secure store, such as an NFC security card -- maybe just
> containing a master key that's used to decrypt the other keys).
> 
> This would make KDE Connect behave as an authenticator as defined in
> https://www.w3.org/TR/webauthn/#authenticator and implementing
> https://www.w3.org/TR/webauthn/#sctn-authenticator-model
> 
> Usage would be as follows:
>  * The user uses his normal browser to visit a website that uses the
> webauth API. The browser queries the system to see if any
> authenticator is present
>  * I am not sure what API is used, it could be
> https://github.com/Yubico/libu2f-host or anoter, DBus-based one. Maybe
> GPG-agent?
>  * Regardless, depending on the browser's behaviour, it will prompt
> the user for authenticating using his dedicated hardware
>  * (at this point, the user usually presses a hardware key on his
> authenticator, or enters a password on some system prompt)
>  * If the user is registering for the first time, we can ask which
> device to register on (including maybe some desktop application)
> trough a system tray notification.
>  * If it is connecting to a website, the device that has a matching
> credential ID displays a prompt. If multiple devices have one, display
> a selection in a tray notification
>  * Upon validation by the user, the KDE Connect app signs the
> challenge and sends it back;
> 
> Here is a user story, if that helps:
>  * John wants to log in into www.example.com
>  * He opens Firefox and browses to www.example.com
>  * A KDE Connect notification appears in the system tray, asking him
> to authenticate using the app
>  * John opens the KDE Connect app on his phone, which may require
> unlocking the phone
>  * John is prompted to select between the identities "John123" or
> "Bob456", and taps "John123"
>  * John is now logged into www.example.com
> 
> Multiple security levels (TPM storage, PIN, etc) could be implemented
> on a per-key basis, at a later date. A gpg-agent implementation would
> be nice as well (and imagine using your phone as a 2fa token/secure
> storage for your SSH keys).
> 
> This is mostly a raw dump of what I've been thinking about lately,
> what do you think about implementing such an API, mechanism and
> interface into KDE Connect?
> Also, I apologize if there are some errors, misunderstandings or
> unclear things in the post above. I am not yet familiar with the
> specifics of these standards and their implementations.
> 
> Best,
> 
> Mayeul




More information about the KDEConnect mailing list