fred/wallet
1
0
Fork 0
forked from cheng/wallet
Code Pull Requests Activity
a6b700a45d
wallet/docs/how_browser_security_should_be_done.html

221 lines
7.7 KiB
HTML
Raw Normal View History

Checking in html files
2022-02-17 22:33:27 -05:00
<!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.&nbsp; </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.&nbsp;
</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.&nbsp; </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.&nbsp; </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.&nbsp; 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.&nbsp; </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.&nbsp; 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.&nbsp; </p>
<p>
To make this chrome based login cryptographically secure
against active and passive attacks on the wire,
phishing, and social engineering.&nbsp; </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.&nbsp; 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.&nbsp; </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.&nbsp;
</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.&nbsp; 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.&nbsp; </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.&nbsp;
The user needs a secure connection to the correct
website. We know how to do secure connections, trouble is
identifying the correct website.&nbsp; </p>
<p>
To ensure that the website is that which is
intended, we use yurls, a form of Zooko identity.&nbsp;
</p>
<p>
The person using the client needs to login and has to
know and manage their logged in status.&nbsp; 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.&nbsp; </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.&nbsp; </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.&nbsp; </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.&nbsp; </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.&nbsp; 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.&nbsp;
</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.&nbsp; 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.&nbsp; The web
page then displays in the chrome the web site’s Skype
name, and your Skype name.&nbsp; 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.&nbsp;
Thus the browser should be, or be tightly integrated
with, a messaging service provided by the single sign on
service.&nbsp; </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.&nbsp;
</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
cleanup, and just do not like pdfs Also, needed to understand Byzantine fault tolerant paxos better. Still do not.
2022-02-18 15:59:12 -05:00
Commons Attribution-Share Alike 3.0 License</a></p>
Checking in html files
2022-02-17 22:33:27 -05:00
docs build still broken
2023-08-25 19:38:32 -04:00
</body></html>
Copy Permalink