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 [email protected]
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 [EMAIL PROTECTED]
