Eliot Lear <[EMAIL PROTECTED]> wrote: > Eric Rescorla wrote: > That the password is at all related to the hash result at all is an > (IMHO) unnecessary risk that would in our scenarios impact more than a > single service. There exists methods where this is NOT the case.
Yes, there do. But they all involve lugging some object around, in which case the problem becomes vastly easier. We need a system which doesn't require a token. > >> It remains up to the end server as to what > >> transactions might require additional authentication. So for instance, > >> a bank may choose to authenticate on new payees for online billing or > >> for particularly large transactions. Or not. > >> > > > > The problem is that this only sort-of protects you against host > > computer compromise because the token that the user authenticates with > > generally isn't cryptographically bound to the request the user > > is making. This allows the crimeware to claim it's requesting > > you to use your token for innocuous purpose X (e.g, routine > > security check) but to actually be using it for malicious purpose > > Y. So, it's a liveness check, but not a misuse check. See also > > [BF99]. > > > Indeed if you don't trust your browser to function properly you are left > with tradeoffs. As we've seen even in the mobile world, a browser can > get hacked. But there are approaches to further reduce the risk, like > describing the transaction on a display of the card. Yes. The reference I provided was to one such system. -Ekr _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
