Re: [TLS] Straw poll on TLS SRP status
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] Straw poll on TLS SRP status
Peter Gutmann wrote:
>
> >Here in Germany, most banks use an OTP-style approach (TAN) for
> >authenticating transactions.
>
> In a previous message I commented that the use of hand-over-the-password,
> circa 1965, had to be the ultimate indictment of the failure of browser
> authentication mechanisms, but I think this is even more damning: Banks are
> having to resort to printing and mailing out lists of TANs (i.e. physical
> distribution of codebooks), a technique going back to the middle ages, because
> security protocol designers haven't been able to provide them with anything
> better. Instead of requiring organisations who care about security to get
> medieval on your keyboard, let's give them something they can use.
If the threat model is phishing and trojaning of the PC and browser,
then printing and mailing out lists of TANs is a cheap and low-tech
"trusted hardware OTP" solution to this problem, that works remarkably
well and is easily understood by large parts of the population and
is quite similar to all "password-based credential distribution"
that banks (and mobile telcos) have been using.
The economic incentive for the service providers is what drives
that decisions. The end user has no say in this, and frankly,
neither do we as the technology providers.
As you know, smartcard technology isn't new. But the adoption is
limited to those areas where there is an economic incentive for the
security level of the technology for the service providers.
What really worries me is that it is difficult to protect against
CSRF (cross-site request forgery), because sites like eBay fully
rely on this architectural flaw to work. (But for a notable exception,
eBay itself seems to work fine with active content disabled).
-Martin
_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.