W3C home > Mailing lists > Public > www-tag@w3.org > January 2007

Re: Asking too much of User Agents: Passwords in the clear again

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Wed, 10 Jan 2007 15:33:35 +0100
To: ht@inf.ed.ac.uk (Henry S. Thompson)
Cc: www-tag@w3.org
Message-ID: <nnp9q21gu22te5ckol6uq0ufvneukraqs9@hive.bjoern.hoehrmann.de>

* Henry S. Thompson wrote:
>As the draft minutes [1] suggest, another tricky case wrt the proposed
>finding on Passwords in the Clear [2] has emerged: Just because a form
>with an <input type='password'>... is delivered via http and not https
>does not necessarily mean the password will be shipped over the wire
>in the clear -- it's been asserted that it's possible for javascript
>on the page, invoked by an 'onsubmit' hook, to use some form of
>(possibly public-key?) encryption so that what is actually submitted
>is safe from snooping.  Clearly the User Agent can't tell that this is
>being done, and so would be expected to issue a warning to the user as
>the finding currently stands, which would be misleading at best.
>Security experts:  1) Is such Javascript actually possible?  If so,
>                      does it provide an acceptable level of security?

Well, this is easy to implement using session tokens. As part of the re-
quest for the password the server informs the client of some one-time
unpredictable session token; the client uses the token to transform the
password, sends the transformed password, the server applies the same
transformation and compares the results. Since the server would provide
a different session token to the attacker, he would have to crack the
encrypted password before gaining any advantage of knowing it.

However, usually the server would generate a session key for the client
which is then used instead of the password to authenticate the client on
subsequent requests. If the attacker wants to gain access to the system
instead of simply learning the password, he would just use the key to
pose as the authorized client. The server could prevent this e.g. by
asking the client to authenticate again when performing special actions
such as viewing or changing account details; the attacker would then
have to wait for the authorized client to perform such actions before
he can successfully conduct a replay attack.

So, yes, it is possible to increase the level of security using script.
Without knowing the requirements it is impossible to say whether any
level of security provided thusly would be acceptable though, so that's
a bit of a silly question.
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Wednesday, 10 January 2007 14:34:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:14 UTC