[Anti-fraud] simple (&secure??) PW-based web login (was Re:Anotherentry in theinternet security hall of shame....)

Amir Herzberg herzbea at macs.biu.ac.il
Wed Sep 14 11:43:27 EDT 2005


Ian G wrote:
> Amir Herzberg wrote:
> 
>> For a stationary user, the extension compares _Iterations_ and confirm 
>> it is at most one less than previous value of _Iterations_ used with 
>> this site.
> 
> (Minor point - if relying on incrementing
> Iterations, this may impact password sharing
> scenarios.  Whether that's a good thing or a
> bad thing depends...)
If by pw sharing you mean using same pw to login to multiple sites - the 
designs tries to solve this (securely) and so, the _Iterations_ counters 
should be kept for each site separately.
> 
>> Also, the extension keeps a table r(PK) mapping the public key PK of 
>> each login site to an independant random value (we need this as real 
>> random value and can't derive them from the PW, to prevent dictionary 
>> attacks by fake sites).
> 
> 
> I suspect this would not work so well in the
> (common enough?) cases where a site uses a farm
> of SSL boxes and certs;  a couple of sites I've
> come across provide different certs every time
> (although admittedly I saw this with IMAP TLS not
> with browsing).
Well, our experiance with TrustBar is contrary to that. We did not come 
across _any_ site that used different public keys in the different 
boxes. Of course, there is sense in using different key per box, to be 
able to identify broken-into box. But this requires many certificates 
and/or making browsers allow sites to sign secondary public keys; the 
first solution is expensive and ugly, the second requires fixing 
browsers, which is not very feasible...

Can you find any real counterexample? [if there are few of these, I can 
add an appropriate workaround easily for them - no major change]
> 
>> Now, using a single PW, extension computes for a site with given PK 
>> the value H(0)=h(PK, h(r(PK), PW).
Oops, that was mistyped: H(0)=h(r(PK), PW)). Server never sees PW, it 
stores only H(i) which is the latest it got; we can always begin a new 
chain by adding its endpoint.
> 
> (Also, you are missing a closing parenthesis there
> so maybe your intent was other.)
Yes - see above
> 
> (Somewhat challenging your assumptions here) your
> design does not seem to cope with MITM.  
Do you see any MITM attack? Don't forget, this entire exchange is 
protected by `standard` SSL (using the server's public key PK).

> (But I may have misunderstood something...)
I think you didn't notice that this entire exchange is all protected by 
the `standard`, server-auth SSL. So I just added client authentication, 
by sending the h^i(r(PK), PW) value, and the server can validate since 
it has h^{i-1}(r(PK), PW). Server never sees PW and cannot mount 
dictionary attack (if r(PK) has enough redundancy).
> 
> iang
> _______________________________________________
> Anti-fraud mailing list Anti-fraud at lists.cacert.org
> http://lists.cacert.org/cgi-bin/mailman/listinfo/anti-fraud
> http://wiki.cacert.org/wiki/AntiFraudCoffeeRoom
> 
> .
> 

-- 
Best regards,

Amir Herzberg

Associate Professor
Department of Computer Science
Bar Ilan University
http://AmirHerzberg.com
Try TrustBar - improved browser security UI: 
http://AmirHerzberg.com/TrustBar
Visit my Hall Of Shame of Unprotected Login pages: 
http://AmirHerzberg.com/shame

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list