To Home page
Cryptography should be written around user concepts, not cryptographer concepts.
The cryptography should be written underneath session management and logon management, instead of session management being written on top of the cryptography. The cryptography should be written to give effect to user expectations, rather than trying to get the users to behave like Ann and Bob in the text book illustrations of how to use cryptography correctly.
The process whereby things go wrong is that one produces a completely sound solution to one part of the problem, waves away the all the rest of the problem as mere details, and then a gigantic mud brick ziggurat gradually accretes around that perfectly sound solution, as for example ssl-https-pki.
When the disastrous abortion know as https was first designed it should have been obvious that everything really important relates to logins and sessions and that the rest can be treated as a login by "anon 37283" with the null password, and that therefore the cryptography and the browser user interface needs to implement logins and sessions, rather than providing a pile of matchsticks and glue with which the website can implement something that sort of mostly behaves rather like logins and sessions.
It should have been obvious that logging in on a user interface provided by a web page, provided by html code, was entirely insecure - the problem of spoofed logins was well known at the time. So what we needed, from day one, was a secure login that was in the browser chrome, not the web page - and no other form of secure login supported.
When the user creates a username and password, this should by default automatically create a bookmark in his contacts folder, much as an email client usually does when you post a reply. To reduce the risk that the user may be fooled into using a hostile client, the user interface for entering password and username should never pop up except by the user clicking on a login button in the browser chrome, or clicking on a login bookmark. Not only should the user never enter his password and user name on a web page, but also there should never be login buttons on a web page.
To make this chrome based login cryptographically secure against active and passive attacks on the wire, phishing, and social engineering.
If the user enters the user name and password incorrectly, then he has to pass a reverse Turing test before entering the password again, to prevent scripts from trying millions of passwords. So if an attacker has tried to guess passwords, the website will inform the user that n unsuccessful login attempts have taken place against his user name and ask him to pass the reverse Turing test.
The user interface to create a connection never pops up spontaneously, but only as a direct result of the user choosing to cause it to pop up, typically by clicking on a bookmark in his account list, or by clicking on the login widget in the browser chrome.
We use password-authenticated key agreement to construct a strong frequently changing secret from the short infrequently changing secret password. Thus if the user logs in to the wrong host – or to an adversary pretending to be the correct host in a man in the middle attack, the false server does not get the password or the session secret. We also hash the password with server global key.
Password-authenticated key agreement also ensures that a passive eavesdropper will not discover the password or the strong session secret.
This tells us how the login will avoid being phished, but how shall we set up a login in the first place. The user needs a secure connection to the correct website. We know how to do secure connections, trouble is identifying the correct website.
To ensure that the website is that which is intended, we use yurls, a form of Zooko identity.
The person using the client needs to login and has to know and manage their logged in status. The user login status should be displayed in the chrome on every logged in web page, and the server has to know that the user knows his login status, has to know the login status not only of the user, but of the web page that the user has clicked on that generated this request to this server.
The state of being logged in should guarantee privacy and authenticity - that only the client and the server can know what they are communicating, and that no one else should be able to pass himself off as client or server, or modify their communications.
Everything should have been written around the user concepts of "logging in" "a logged in page", and "logging out", and should have made those user concepts real, made them into pages with appropriate built in cryptographic behaviors.
The user concept of "logged in" has to be real rather than superficially simulated by server side code, and thus has to really have the cryptographic characteristics that the user expects - which at present it generally does not, leading to such attacks as the session fixation attack.
The user should have a list of contact web sites as he does in Skype and AIM, and when he clicks on that bookmark, the logon page, provided by his browser rather than the website, should provide the true name of the web site, if it has a certified true name, and/or the title of the bookmark, the petname, if it has one. And when logged on, any logged on page should show in the chrome the petname, or truename of the website, and the logon name - who the website thinks is logged on.
Single signon should work like Skype, and should be built into the protocol at the base level, in the cryptography, and in the chrome, and in the bookmark/petname management. You click on a petname in the Skype contact list - the Skype folder of the login folder of your bookmark folder, and lo, because you are securely logged in to Skype, and the web site also securely logged into Skype, you come to be securely connected to each other under your Skype names without any further mucking around with passwords. The web page then displays in the chrome the web site's Skype name, and your Skype name. Single sign on should also allow web site push, if the end user is logged in to the single sign on server and the website is in his contact list and the end user has not prohibited such push. Thus the browser should be, or be tightly integrated with, a messaging service provided by the single sign on service.
The web application framework should ensure that code providing a response to a user's click on a web page that is not logged in does not have write access to database records corresponding to that user - that only a click on a logged in web page in the user's browser can result in changes to user records on the server.
These documents are licensed under the Creative Commons Attribution-Share Alike 3.0 License