221 lines
7.7 KiB
HTML
221 lines
7.7 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="en"><head>
|
||
|
||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
||
<style>
|
||
body {
|
||
max-width: 30em;
|
||
margin-left: 2em;
|
||
}
|
||
p.center {text-align:center;}
|
||
</style>
|
||
<link rel="shortcut icon" href="../rho.ico">
|
||
<title>How Browser Security Should be Done</title>
|
||
</head><body>
|
||
|
||
<p><a href="./index.html"> To Home page</a> </p>
|
||
|
||
<h1>How Browser Security Should be Done</h1>
|
||
|
||
<p>
|
||
|
||
Cryptography should be written around user concepts, not
|
||
cryptographer concepts. </p>
|
||
|
||
<p>
|
||
|
||
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.
|
||
</p>
|
||
|
||
<p>
|
||
|
||
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. </p>
|
||
|
||
<p>
|
||
|
||
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
|
||
<em>and the browser user interface</em> 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. </p>
|
||
|
||
<p>
|
||
|
||
It <em>should</em> 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. </p>
|
||
|
||
<p>
|
||
|
||
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. </p>
|
||
|
||
<p>
|
||
|
||
To make this chrome based login cryptographically secure
|
||
against active and passive attacks on the wire,
|
||
phishing, and social engineering. </p>
|
||
|
||
<ul>
|
||
|
||
<li><p>
|
||
|
||
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. </p></li><li><p>
|
||
|
||
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.
|
||
</p></li><li><p>
|
||
|
||
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. </p></li><li><p>
|
||
|
||
Password-authenticated key agreement also ensures that a passive eavesdropper will not
|
||
discover the password or the strong session secret. </p>
|
||
</li>
|
||
</ul>
|
||
|
||
<p>
|
||
|
||
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. </p>
|
||
|
||
<p>
|
||
|
||
To ensure that the website is that which is
|
||
intended, we use yurls, a form of Zooko identity.
|
||
</p>
|
||
|
||
<p>
|
||
|
||
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. </p>
|
||
|
||
<p>
|
||
|
||
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. </p>
|
||
|
||
<p>
|
||
|
||
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. </p>
|
||
|
||
<p>
|
||
|
||
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. </p>
|
||
|
||
<p>
|
||
|
||
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.
|
||
</p>
|
||
|
||
<p>
|
||
|
||
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. </p>
|
||
|
||
<p>
|
||
|
||
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.
|
||
</p>
|
||
<p style="background-color : #ccffcc; font-size:80%">These documents are
|
||
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
|
||
Commons Attribution-Share Alike 3.0 License</a></p>
|
||
|
||
</body></html>
|