Eliot Lear <[EMAIL PROTECTED]> writes: > Eric Rescorla wrote: >> Well, you could clearly use PwdHash this way. In fact, that's how >> your industry standard challenge-response token works. But it doesn't >> really help because you don't have HRA against an attacker who >> controls the victim's computer. So, they don't capture your >> authentication string but they capture the immediately following >> session. >> > > PwdHash as an algorithm doesn't protect you from a host computer > compromise. For that you need architectural separation, which is why > smart cards etc exist.
Yes, Eliot, I'm really quite familiar with the principle of two-factor authentication. My point was that the algorithm that PwdHash employs is basically the same one that your average challenge response token uses. It's purely a matter of location. > 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]. -Ekr [BF99] "Hand-Held Computers Can Be Better Smart Cards." Dirk Balfanz and Edward Felten. Proceedings of USENIX Security '99. Washington, DC. August 1999. _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
