Steven Bellovin wrote:
This returns us to the previously-unsolved UI problem: how -- with today's users, and with something more or less like today's browsers since that's what today's users know -- can a spoof-proof password prompt be presented?

When the user clicks on a button generated by a particular special kind of html tag, perhaps <loginbutton logintype="SRP" loginurl="/customers/loginpage.script>login</loginbutton>

A not quite rectangular login form which is not an html page rolls out of the url, with a motion like a blind or toilet paper unrolling, and partially covers the browser chrome, thus associating the form with the browser and the url, rather than the web page.

The form will be decorated and prominently watermarked in manner that is customizable by the end user, and if the end user does not customize it, which he probably will not, a customization was randomly selected at install time.

A phisher could do a flash animation that looks almost like the form rolling out, but the flash animation will not roll out of the url, and will not partially cover the browser chrome, and is unlikely to match the customization.

If the url is

Then the content of the login form is controlled by script at login://

The login form will be associated with a public key. If the user has logged in before using this browser, there will be an entry in his bookmarks list for the url *and* public key

If the login form is the browser's bookmark list, the title on the login form will be the petname, that is to say, the name under which it appears in the bookmark list.

If the login form is *not* in the browser's bookmark list, the title on the login form will be "No Previous Login at this site using this browser by this user", with script supplied title and or certificate supplied title somewhere else in smaller print.

The loginpage.script will tell the browser what fields and fieldnames to request from the user - typically username and password, but this needs to be scriptable - for example it could be credit card number, etc. The script will tell the server what database table and what database fields to associate these user supplied fields with when the client responds.

Peter Gutmann has, he believes, a much simpler solution.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to

Reply via email to