Let's discuss the client certificates

[MKleusberg]

The way we're doing client certificates has quite some flaws at the moment. The major ones are:

• The certificates are neither encrypted nor somehow else protected by a password. This means an attacker who gets one has immediate full access.
• There's no list of issued certificates and absolutely no way to revoke one. Also see Allow revoking of DB4S certificate(s) #122.
• They are generated on our servers when really they should be generated by the client application which then only transmits the public key for signing by our infrastructure.

Points 1 and 2 make them seem pretty insecure and problematic. Point 3 makes it harder to implement them properly because we'd have to have code in DB4S, in dio, and in Javascript for the web UI - besides basically building a full-fledged CA. And then users are still confused about certificates because they usually don't deal with them.

I definitely don't want to say client certificates for authentication are bad. But considering everything honestly wondering it it's maybe not better to implement 0Auth in dio and DB4S or just use API keys. What do you think?

[justinclift]

Hmmm, we could do that. Client certificates seemed like the right approach when we first started working on this, but they have turned out to be a fair pain in the butt. 😉

For moving to a new approach, what do you reckon our requirements are? We'll probably also need some kind of transition plan too. Maybe supporting both methods for a while or something. 😄