About Me!
This blog is about my musings and thoughts. I hope you find it useful, at most, and entertaining, at least.
Other Pages
Presence Elsewhere
Analysis of Login Methods
Date: 2013-03-23
Tags: email login oauth openid password otp skey
I was chatting with a friend about the idea of using email-only logins. While not a new idea (see XOXCO for one example, and its follow-up), I thought I’d talk a little about it here. While writing up that idea, I started thinking about other methods as well.
Traditional Login
The traditional login system is simple, but subject to many security attacks, such as phishing and offline attacks. 
In the traditional system, the user knows sends both a username and plain-text password, ideally not over an unencrypted connection, but not always in practice, to the server. The server then confirms this username/password pair and logs the user in. Ideally, the server uses a strong password hashing technique (bcrypt by Niels Provos and Talan Jason Sutton or scrypt by Colin Percival and Simon Josefsson and with a salt )to store the passwords on the server, but this isn’t always the case.
OAuth and OpenID move the issues with the traditional login from each individual site to a central location. While this makes it more convenient for the user (only a single set of login credentials), it doesn’t solve the other problems present with traditional authentication.
2-Factor Authentication also adds protection to the account itself, but doesn’t do anything to protect the password. Regardless of the order the factors (password and token) are entered, a malicious site could just accept and harvest the password.
Mutual Authentication is a way for both the client and server to authenticate themselves to each other (in traditional authentication, only the user authenticates themselves to the server). There is a paper, PAKE-based mutual HTTP authentication for preventing phishing attacks and IETF Draft. While this improves the phishing aspects of password authentication, the original server still needs to store the password in some fashion. This also assumes the user will only enter their password into the browser chrome, not into a web page, which is questionable. This is very similar to traditional authentication, except that the user is guaranteed to know that the server they’re authenticating to is one that also knows the users credentials.
Phishing and MITM attacks are disasterous for traditional authentication because the user gives the server the password in plain-text. If the recipient isn’t trustworthy, they can then store and use the password for nefarious purposes later on.
Update: Mozilla Persona is also a contender in the space. Like other federated systems, it doesn’t require the user to have multiple accounts: just their email address.
| Pros | Cons |
|---|---|
| Ease of use | Requires the server to store password |
| Requires no supporting apps or support by the User-Agent | No phishing protection |
eMail-Only
The basic workflow of the idea is this:
- User comes to site
- User enters email into login form
- Site sends email with a time-limited login link
- User clicks link in email
- Site logs the user in, if applicable
The link in the email is time-limited so that if the email is found later, it is useless. If the email is intercepted in transit is still an open problem. (The user could place a public GPG key in their profile after their first login, but that, apparently, is too much to ask the general public.)
Because of phishing concerns, (“Click this link to login!” and then enter your credit card information to use the service) this approach only works for something in which the user will reasonable not expect to pay for or be forced to provide additional information (e.g.: commenting on a blog or forum).
In this example, email could be replaced by a lot of things, such as SMS (but I doubt people will give out their phone numbers). The purpose is so that the user isn’t required to share details from other sites (such as Twitter or Facebook) or create an account somewhere else (in the case of OpenID).
Update: Perhaps I’m being a bit too friendly with the idea of email-only authentication. It still requires that you authenticate somewhere, usually with a username and password. I’m also assuming that everyone has an email address (and therefor the overhead to gaining one is nil) and that everyone wouldn’t mind using it to login. Federated login systems such as OpenID and OAuth are similar in many regards and have some inherent security benefits as well.
| Pros | Cons |
|---|---|
| Website does not store password (in any form) | Email is Insecure |
| User doesn’t have to remember username/passwords for every site | Email can be slow |
| No registration | More steps than traditional login |
| Could make phishing easier |
OTP
HOTP and TOTP
I thought about using One-Time Passwords of the form HOTP (RFC 4226) and TOTP (RFC 6238) but that still requires the website to store a piece of information about you. Granted, if found, an attacker could only impersonate you on the attacked website.
These methods work by sharing a secret and then using a moving value, a counter or the current time (both of which need to be in sync with the server). The client and server can then perform rounds of hashing the secret and moving value to produce a one-time use password (in the sense that that time or counter value will never happen again, ergo giving a new value every time).
There are already many apps that will perform this algorithm and many sites that use it. For example, the DroidOTP and Google Authenticator are popular in the Android market. Google, obviously, and MtGox uses OTP for their 2nd-factor and there are plugins for WordPress and Drupal as well. While mostly used as a 2nd-factor, it is fairly widely used.
| Pros | Cons |
|---|---|
| User doesn’t have to remember username/passwords for every site | Site needs to store a per-user secret |
| Minimal registration | Negligibly harder than a traditional login |
| Requires an app or User-Agent support |
S/KEY
S/KEY (RFC 1760 and RFC 2289) is an interesting option as well. While inconvenient to use, OTP Calculator, Opiekey, and OTPdroid could provide the basis for such a system. 
I would envision such a system working as so:
Common for all sites
- User would require an app to be installed on their computer and/or phone.
- User sets up a master-password
Registration
- User enters email address
- Site generates an account and time-limited URL that can be copy-and-pasted or scanned via a QR Code into the app on the phone
- The app would take the domain from the URL and a user-configured password to create the secret for the site
Login
- User enters email address
- Site responds with the current sequence number
- User enters the sequence number into the app and the app responds with an S/KEY password (e.g.: ROY HURT SKI FAIL GRIM KNEE)
- The user enters the S/KEY password into the form provided by the site
However, if the site is not trustworthy, then it’s possible for the attacking server to request a password with a high sequence number.
| Pros | Cons |
|---|---|
| Minimal registration | More steps than traditional login |
| User doesn’t have to remember username/passwords for every site | Requires an app or User-Agent support |
| Site arguably stores per-user secret (one-time-use hash of a 64-bit number) | Possible phinging problems |
Client-Side SSL Certificates
Using client-side SSL Certificates completely side-step the problem of passwords, because it doesn’t use any (that are sent to the server, the certificate should be encrypted). Generating these certificates isn’t difficult and once installed in the browser, “just-works”. One possible issue is that the client-cert is required on every device being used, but I would rank this as similar in difficulty to passwords needing to (or should be) unique per site.
One (major) issue, however, is that the use of client certs doesn’t do anything to prevent a user from believing that they are logged into a phishing site and requesting more data from them. The user would have to be concious of if the site is using the client cert, just as they need to be concious of a site using SSL for e-commerce currently.
Support for client certs is built into all major browsers already, so it wouldn’t require any additional applications or User-Agent support from what is currently available (except possibly notification of client-certs being used).
The only secret being stored on the server is the server’s private key. This, like current SSL keys, should be encrypted and the password-key should not be kept on the system.
Update: In a Reddit thread it was pointed out to me that I have greatly over-estimated the support and ease of use of client-side certificates. Given the problems, I’ve re-assigned the ratings in the chart below.
Summary
Updated: The methods are compared in the following table with each category ranking 1 (no or poor support) to 5 (good support).
- Ease of use – How easy is it for a user to login? inc.: How many steps? How hard is it to manage credentials?
- Ease of registration – How easy is it for the user to create an account?
- No secret storage – How much secret data is the server storing? i.e.: If the server is compromised, what could the attacker gain?
- Phishing Prevention – Does the method have any in-built phishing prevention abilities
- No Additional Support – Does the method require the user to have a special User-Agent or auxiliary applications?
| Method | Ease of use | Ease of registration | No Secret Storage | Phishing Prevention | No Additional Support | |
|---|---|---|---|---|---|---|
| Password | 4 | 4 | 1 | 1 (5 for Mutual Authentication) | 5 | !{width:300px;}/img/auth/traditional.jpg! |
| OpenID/OAUth | 4 | 5 | 5 | 2 | 5 | !{width:300px;}/img/auth/openid.jpg! |
| 3 | 5 | 5 | 1 | 4 | !{width:300px;}/img/auth/email.jpg! | |
| OTP | 3 | 4 | 3 | 3 | 2 | !{width:300px;}/img/auth/otp.jpg! |
| SSL | 3 | 2 | 5 | 3 | 3 | !{width:300px;}/img/auth/ssl.jpg! |
For situations where phishing isn’t an issue, i.e. there is a reasonable expectation of no commerce occurring (e.g.:commenting on a blog or forum), email-based authentication would seem to be the leading option.
(Note: This paragraph may be overzealous) For situations involving commerce, Client-Side SSL keys with user education similar to what is given to SSL now (“look for the green address bar”) would seem to be the most secure option. The only issue is the registration overhead, but for a situation like a bank, this may be worth-while. For this to happen though, the UI used by User-Agents needs to be upgraded and users need to be taught how to look for the signs that the client cert is being used, just like they’ve been taught to look for the SSL notification.