Re: [dix] Agenda bashing

Eric Rescorla wrote:
> Eliot Lear <lear@cisco.com> 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.
>   

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.

>
>   
>> 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.  And Eric, keep in
mind one obvious application for all of this: if I want to put an end to
bots at my company, I may want to periodically demand strong
authentication from the PCs for various functions.  Let's see the
malware that is both a useful bot and attempts to fool me into thinking
I'm not sending that email I mean to send.

Eliot

_______________________________________________
dix mailing list
dix@ietf.org
https://www1.ietf.org/mailman/listinfo/dix