Permalink
Browse files

Starting to write the paper :D

  • Loading branch information...
ept committed Sep 3, 2012
1 parent b2c642a commit 64d1b93ce4c4714616df5991f7a598129000bfd1
Showing with 215 additions and 0 deletions.
  1. +6 −0 paper/.gitignore
  2. +16 −0 paper/Makefile
  3. +117 −0 paper/intro.tex
  4. +7 −0 paper/mobile.tex
  5. +23 −0 paper/octokey.tex
  6. +46 −0 paper/references.bib
View
@@ -0,0 +1,6 @@
+octokey.aux
+octokey.bbl
+octokey.blg
+octokey.log
+octokey.out
+octokey.pdf
View
@@ -0,0 +1,16 @@
+.SUFFIXES = .tex .bib .aux .bbl .dvi .ps .pdf
+
+all: octokey.pdf
+
+octokey.pdf: octokey.bbl
+ pdflatex octokey
+ pdflatex octokey
+
+octokey.bbl: references.bib octokey.aux
+ bibtex octokey
+
+octokey.aux: *.tex
+ pdflatex octokey
+
+clean:
+ rm -f *.{log,aux,bbl,blg,dvi,ps,pdf}
View
@@ -0,0 +1,117 @@
+\section{Introduction}
+
+For a majority of consumer web use cases, an authentication system with the following properties is
+desirable:
+
+\begin{itemize}
+\item The system should not depend on any trusted third party, to avoid risks arising from failure
+of the third party (security compromise, going out of business, change of policies etc).
+\item It is not necessary, and often undesirable, for the system to authenticate the user as a
+physical person. Many websites allow pseudonymous signup, which is desirable for privacy, freedom of
+speech and other reasons. The purpose of the authentication system is thus only to verify that the
+current user is the same person as the one who originally signed up under a particular username; no
+authentication is performed at signup.
+\item To ease adoption, the system should be easy for end-users to install and use, and easy for
+website owners to deploy. Since user signup and user activity rates are important business metrics
+for many websites, the system should make signup and login extremely easy and enjoyable for users.
+\item The system should minimize its exposure to human error. Whilst human error is unavoidable,
+especially amongst non-technical users, the system should be designed so as to minimize the impact
+in the case of error.
+\item Users should have the freedom to use the system on a variety of devices, including shared or
+public computers that are only partially trusted, whilst minimizing their exposure to attackers.
+For example, a user may choose log in to `unimportant' services (e.g. casual online games) on a
+shared or public computer, knowing that their account on that service may be compromised; however,
+they limit their use of `important' accounts (e.g. online banking) to trusted devices. Since there
+is no generally agreed boundary between `important' and `unimportant' websites, the same
+authentication system should be able to support both use cases.
+\end{itemize}
+
+
+\section{Existing web authentication systems}
+\subsection{Passwords}
+
+Despite their many well-known flaws, passwords are still by far the most commonly used
+authentication system on the web. They have many of the desirable properties mentioned above: no
+dependence on any third party, pseudonymity, simplicity, familiarity and cross-device compatibility.
+However, they are highly susceptible to human error: use of weak passwords, reuse of the same
+password across different services, phishing attacs and leaks of unhashed or weakly hashed password
+databases are unfortunately commonplace.
+
+The problem is not ignorance of the risks, but rather the inconvenience of the alternatives.
+[TODO cite something about the number of passwords that people are able to memorize.]
+Password manager products such as 1Password or LastPass make it feasible for users to maintain a
+strong, unique password for each service they use. However, even when a unique password is used, an
+attacker who succeeds in stealing a password (e.g. by phishing, keylogging, man-in-the-middle attack
+or eavesdropping when it is accidentally sent over an unencrypted connection) has access to that
+user account until the password is changed, which is practically forever [citation needed].
+
+Password managers also have grave exposure to human error. For example, consider a user who wishes
+to log in to an `unimportant' website on an untrusted computer. They may be carrying their encrypted
+password database with them on a trusted device (such as their smartphone), in which case their best
+option is to enter the encryption passphrase on their smartphone's tiny keyboard, find the record
+for the desired website, read the random password from the smartphone screen and type it letter by
+letter into the browser on the untrusted computer. By contrast, it seems much more convenient to
+\emph{(``just this once'')} type the master passphrase into the untrusted computer to decrypt the
+password database there, and copy\&paste the password for the `unimportant' website. Of course this
+has the effect of exposing the user's entire password database to an attacker. This characteristic
+of password managers -- making it so tempting to commit a grave security mistake -- should be a
+cause for concern in an authentication system with mainstream adoption.
+
+\subsection{One-time passwords}
+
+A better solution for users who want to log in to their accounts on untrusted or partially trusted
+devices is to use one-time passwords (OTPs). The user must in advance, on a trusted device, download
+a list of one-time passwords, or register a cryptographic device that generates a sequence of OTPs,
+or register a phone number to which OTPs can be sent on demand. (Systems involving a device or phone
+are also known as two-factor authentication.) OTPs are supported by an increasing number of consumer
+web services, such as the email providers Gmail, Hotmail and Fastmail, demonstrating consumer demand
+for temporary access to their accounts on untrusted devices.
+
+With OTPs, the exposure to attacks is more closely aligned with non-technical users' mental model of
+website security [citation needed]: from the time they enter the OTP on an untrusted device until
+the time they click the logout button, they are vulnerable to an attacker impersonating them on that
+particular website. However, unless the attacker has a means of extending their privileges (e.g. by
+granting themselves OAuth access to the account, or exploiting another vulnerability), the exposure
+ends when the user's session is invalidated, and the exposure is limited to that particular website.
+This is still far from ideal, but it is better than an indefinitely long exposure window, or
+exposing the user's accounts on other websites, as is often the case with regular passwords.
+
+The downside of OTPs is that they tend to be so inconvenient to use that very few websites are
+willing to adopt them as their only or primary authentication mechanism. Especially when logging in
+on a trusted device, it is widely considered too much effort for the user to pull a smartphone or a
+piece of paper out of their pocket every time they want to log in, and to print off a new list of
+passwords before the old one runs out. Thus OTP authentication tends to exist only alongside other
+authentication mechanisms that are more convenient, and OTPs tend to be used only by a particularly
+security-conscious subset of users. [citation needed]
+
+\subsection{OpenID and OAuth}
+
+OpenID~\cite{OpenID} is probably the best-known attempt to relieve users from the burden of
+remembering or storing passwords, and as of 2009 was used for authentication on over 9 million
+websites~\cite{OpenID09}. Although in theory OpenID allows the user to choose any identity provider
+by entering a URL, in practice many implementations provide a menu with a small selection of
+well-known OpenID providers. In cases where the OpenID provider is also an OAuth service
+provider~\cite{OAuth}, the line between OpenID and OAuth becomes blurred from the user's point of
+view. Some providers, such as Google Federated Login~\cite{GoogleOpenID}, even combine the
+protocols.
+
+OpenID does not solve the fundamental problem of authentication: it only delegates the problem to
+the OpenID provider, who must then use some other authentication method (most commonly a password,
+possibly in conjunction with a code from a hardware token). This means that all the security
+characteristics discussed above apply to the OpenID provider, with an additional privilege
+escalation problem: if an attacker is able to gain access to the user's OpenID provider account,
+they can access any account associated with that OpenID. Sooner or later, a user is likely to be
+tempted to type their OpenID provider password into an untrusted device, and the authentication
+system would amplify, rather than dampen, this error.
+
+Moreover, in OpenID, the relying party needs to trust the OpenID provider to correctly authenticate
+the user. If the OpenID provider is compromised, the relying party has no way of detecting
+unauthorized logins from that OpenID provider. If the OpenID provider goes out of business, many
+users of that provider will lose their ability to log in (unless they had set up delegation of their
+identity URL, which is unrealistic to expect of non-technical users).
+
+Delegated authentication systems like OpenID are thus lacking in some of the desirable properties of
+authentication systems outlined above.
+
+\subsection{Client certificates}
+\subsection{BrowserID}
View
@@ -0,0 +1,7 @@
+\section{Delegated login by mobile device}
+Browser and phone meet at rendezvous point (URL in QR code) / communicate over rendezvous channel
+
+We must assume that the contents of the barcode can be read by an attacker: it may be
+electromagnetically snooped~\cite{Kuhn05}, or an attacker may simply point a camera at the victim's
+screen. In order to establish a secure channel between the smartphone and the desktop browser, it is
+therefore not appropriate to embed a symmetric private key in the barcode.
View
@@ -0,0 +1,23 @@
+\documentclass{article}
+\usepackage{cite}
+\usepackage{hyperref}
+
+\begin{document}
+\title{Octokey: Public key authentication for the web}
+\author{Martin Kleppmann \and Conrad Irwin}
+\date{\today}
+\maketitle
+
+\begin{abstract}
+TODO Abstract
+\end{abstract}
+
+\input{intro}
+\input{mobile}
+
+% TODO: key revocation (check revocation list on every login/periodically? key splitting? what about
+% denial of service risk?)
+
+\bibliography{references}{}
+\bibliographystyle{plain}
+\end{document}
View
@@ -0,0 +1,46 @@
+@incollection { Kuhn05,
+ author = {Kuhn, Markus},
+ affiliation = {Computer Laboratory, University of Cambridge, 15 JJ Thomson Avenue, Cambridge, CB3 0FD United Kingdom},
+ title = {Electromagnetic Eavesdropping Risks of Flat-Panel Displays},
+ booktitle = {4th Workshop on Privacy Enhancing Technologies},
+ series = {Lecture Notes in Computer Science},
+ editor = {Martin, David and Serjantov, Andrei},
+ publisher = {Springer},
+ isbn = {978-3-540-26203-9},
+ keyword = {Computer Science},
+ pages = {88-107},
+ volume = {3424},
+ url = {http://www.cl.cam.ac.uk/~mgk25/pet2004-fpd.pdf},
+ year = {2005}
+}
+
+@misc { OpenID09,
+ author = {Kissel, Brian},
+ title = {Open{ID} 2009 Year in Review},
+ month = {Dec},
+ year = {2009},
+ howpublished = "\url{http://openid.net/2009/12/16/openid-2009-year-in-review/}"
+}
+
+@misc { OAuth,
+ author = {Eran Hammer-Lahav},
+ title = {{RFC} 5849 -- {T}he {OA}uth 1.0 Protocol},
+ publisher = {IETF},
+ howpublished = "\url{http://tools.ietf.org/html/rfc5849}",
+ month = {Apr},
+ year = {2010}
+}
+
+@misc { OpenID,
+ author = {Open{ID} Foundation},
+ title = {{O}pen{ID} Authentication 2.0 -- Final},
+ howpublished = "\url{http://openid.net/specs/openid-authentication-2_0.html}",
+ month = {Dec},
+ year = {2007}
+}
+
+@misc { GoogleOpenID,
+ author = {Google Inc},
+ title = {Federated Login for {G}oogle Account Users},
+ howpublished = "\url{http://developers.google.com/accounts/docs/OpenID}"
+}

0 comments on commit 64d1b93

Please sign in to comment.