On Sat, Sep 17, 2016 at 05:37:12PM +0200, Rene 'Renne' Bartsch, B.Sc.
> everyone knows the problem:
> We have dozens or hundreds of services to login and every service wants
> a user-name and a password. Most users reuse their passwords and a lot
> of services do not protect the passwords securely (no hashing, salting,
> etc.). If a service is hacked or malicious, the perpetrator can be quite
> sure to be able to reuse the credentials at other services. Not to
> mention passwords like 12345.
> In TLS operation, a user can be authenticated with a client-certificate.
> The password is neither transmitted over the wire nor to the
> service-provider. There is only one single password for the
> client-certificate instead of multiple passwords for multiple services.
> So I suggest to add this case to the application description in section
> 6 of draft-ietf-dane-smime-12 or a successor/errata. (Sorry, I lost
> track of the current state of SMIMEA).
Unfortunately, client certificates tend to be UX disaster. Things only
get worse if one needs to consider multiple services, as using one key
for multiple services tends to have bad security consequences.
These tend to be the reasons browser vendors are phasing out <keygen>
and client certificate installation, pretty much meaning one has to
have physical smartcard for TLS client certificate authentication.
And such smartcards with the necressary equipment are pretty rare
(I happen to have one) and tend to be built around real-world identity,
which is great for some services, but not-so-great for most.
I have once experimented on what it would take to implement client
certificate authentication in a site, and pretty quickly gave up,
given the horrible UX it had (not to mention technical problems,
even with all the PKI baggage I could short-circuited).
dane mailing list