Hi Eliot,

It's actually possible to get your secure opaque channel without smart
cards.

Merely some nifty graphics, HTML, and shared secrets (traditional
meaning) are one implementation, while non-smart tokens are another
(eg: printed or electronic tokens)

Servers can't communicate "securely" unless something is able to
"authenticate" the *server* before it is allowed to authenticate the
user.  Smart cards and PwdHash don't/can't do this, at least not
without extra hardware at the client, which almost nobody has of
course.

Kind Regards,
Chris Drake


Thursday, July 6, 2006, 4:12:31 PM, you wrote:

EL> [EMAIL PROTECTED] wrote:
>> I believe that PwdHash does rely on a certain level of proof of the
>> server's identity.  The browser needs to decide that
>> the domain name that the server is presenting actually belongs to it.
>> This is usually done by relying on SSL/TLS.
>> If the false server can convince the browser that it is in fact the
>> targeted domain, then the browser will happily
>> transmit the full credential (H(password, domain)) to the server.
>>
>> PwdHash does NOT require that the proved domain match anything the
>> user has in mind.  That is, the identity
>> does not need to be presented to the user, or compared against
>> anything the user is doing. This seems to be the
>> primary problem in phishing attacks (the last foot).  That's where the
>> real advantage of techniques like PwdHash are.

EL> Pretty neat.  There are two problems that still really need to be
EL> addressed.  The first is that you need to manage a transition.  It must
EL> be clearly visible to the user when PwdHash is used and when it is not.
EL> Otherwise someone just phishes the original password and that's the ball
EL> game.

EL> Second, PwdHash still relies on the underlying security of the user's
EL> computer.  I don't know about you but that is a goal I would like to
EL> address.  I want a means to have a secure opaque channel of
EL> communication between the server and the smart card.  That's what I'm
EL> looking for from the IETF.

EL> Eliot

EL> _______________________________________________
EL> dix mailing list
EL> [email protected]
EL> https://www1.ietf.org/mailman/listinfo/dix




_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix

Reply via email to