[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