Some clarification of the proposal:
Initialization:
===============
client has dedicated pw(server) to each server (today's situation).
Client is supposed to be able to identify server based on the server's
certificate etc., e.g. using TrustBar over regular browser.
Client also installs the pw-based login extension, and provides it with
a `master pw` MPW.
Init1: client establishes SSL connection with server, to access login
page. Let PK be the public key of the server.
Init2: server sends login form, with indication of support for secure login
Init3: extension identified this is a secure login, presents special
window asking client to provide pw(server), and MPW if not provided yet,
and to authenticate server (based on certificate).
Init4: extension generates random number and saves it as R(PK) - random
number for this particular server (as identified by its public key PK)
Init5: extension sends to server, inside the SSL connection, a secure
login submission, containing:
1. pw(server) as (only) current means of client authentication
2. h(h(MPW, R(PK))) - The value h(MPW, R(PK)) will be the `one time
password` to be used in next login (we could also use a `hash chain`
here but I removed it for simpicity and since it does not change much)
Init6: server verifies pw(server) (old password) and stores the received
h(h(MPW, R(PK))) as the hash of the new PW. It sends ack to the client
(again protected by SSL).
Init7: upon receipt of ack, client knows pw was updated.
Regular login is pretty similar:
=================================
RL1: client establishes SSL connection with server, to access login
page. Let PK be the public key of the server.
RL2: server sends login form, with indication of support for secure login
RL3: extension identified this is a secure login, presents special
window asking client to provide MPW if not provided yet.
RL4: extension sends to server, inside the SSL connection, a secure
login submission, containing:
1. h(MPW, R(PK)) - The `one time password`
2. h(h(MPW, r')) - a new one-time-pw validator for next login
R5: server verifies OTP (i.e. h(MPW, R(PK))), if OK, login is approved
and saves new OTP validator h(h(MPW,r')). It sends ack to the client
(again protected by SSL).
R6: upon receipt of ack, client knows pw was updated: R(PK)=r'.
This description glosses over dealing with failures, but this is not
difficult; I also don't discuss how to support users of `public` PCs and
changing PCs, solutions are possible.
--
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]
