Re: [TLS] Straw poll on TLS SRP status

[Martin Rex <Martin.Rex at sap.com>]

Peter Gutmann wrote:
> 
> The reason I made the comment about TLS client auth being an abject failure
> is that every time anyone mentions the possibility of providing any other
> way of authenticating clients and servers, it's practically guaranteed
> that someone will pop out of the woodwork and state that we already have
> the perfect solution to authentication in the form of client certs

The main reason why I brought it up is because most the installed base
is able to cope with SSL clients certs.  But it did take a few years
to get there.  It is far from perfect, especially in mixed scenarios
for the cert-less users because, depending on the browser, they
might get constantly annoyed with a certificate selection popup.


I would not want to see additional password-based authentication schemes
to be promoted that require significant changes to then entire
infrastructure/middleware, because this will only add new problems,
and not really solve any of the existing problems.

The reason for people still using passwords are (a) legacy password-based
authentication systems and (b) the necessity to be able to walk up
to any network-connected PC and "login" from there by entering
a memorized password.  And the latter is often a phishing-enabling
requirement.


The operational costs of password-based authentication is likely much
lower than the use of strong cryptographic credentials, which require
either a hardware token (e.g. USB-key, smartcard) or a software
credential that is distributed through the network protected
by a traditional password, and which must be at least temporarily
persisted on the PC where it is being used.

Dealing with forgotten passwords is usually much easier for a
helpdesk/callcenter than dealing with a forgotten or lost or
defective hardware token, especially if when you're travelling.


OTP might be seen as one approach to thwart phishing attacks, but
it is also seen as a major inconvenience.   More and more often
you find Single Sign-On (SSO) and in addition to that, credentials
management tools (not just Browsers) aggressively try to persuade
users to memorize and auto-supply credentials (The credentials
manager on my new notebook was a serious nuisance and real security
problem, so I uninstalled it).

 
The problem with SSO is that it allows attackers to perform all sorts
of MITM attacks through active content, trojans and CSRF
(Cross-site request forgery).


The approach taken by online banking to limit the damage from such
attacks is to accept SSO only for reading information, not for
requesting transaction.  Here in Germany, most banks use an OTP-style
approach (TAN) for authenticating transactions.  I think this is
a fairly reasonable and usable compromise, but it requires careful
application design (clearly seperate more dangerous and less dangerous
actions and exclude the more dangerous actions from Single Sign-On)
and I don't currently see how the two different authentication
schemes (Single Sign-On and per-transaction authentication) should
both be provided by TLS without significant architectural changes
to the middleware (session management).


The other thing I feel uncomfortable with is the skewed threat model.
On the one hand there is the attitude that one cannot prevent the
credential from being stolen, so one tries to limit the damage that
can be done to the server (in a cover-your-ass fashion).  On the other
hand there is ignorance about the problem that an attacker that is
able to steal my credentials from my machine can probably just as
easily subvert my browser to perform the fraudulent transaction
itself and therefore bypassing all channel-bindings and
password-concealing efforts that are being proposed.

At the same time the victim Joe User will be in a much worse position
trying to repudiate a fraudulent transaction compared to the majority
of unsophisticated phishing attacks today.  Service providers will
like this because Joe User will have to cover most of the damages
and the attacker will like it because they're less like to get
caught.  As security engineers we can hardly claim tomorrow that
we could not anticipate such a shift in attack methods when tweaking
the technology to thwart the large amounts of low-tech phishing attacks
and cutting into the attackers ROI without adding real security.


If we think that passwords are fundamentally flawed in this
environment, we should not significantly prolong and promote
their continued use by applying band aids.

:-|

-Martin

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls