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 http://exampledomain.com/somedirectory/somepage.html
Then the content of the login form is controlled by script at
login://exampledomain.com//customers/loginpage.script
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 majord...@metzdowd.com
