Joschka Tillmanns

Web Service Authentication


I recently wanted to try out some new authentication schemes for my personal applications that I host at my server. I tried to find something close to SSH because I find the idea of simply storing my public key as an identity token very appealing. Thus I began to setup TLS client certificates that I can now use to easily access my services that I host at my own server without the need of a username/password.

Upon this journey I thought about ways to replace the username/password approach publicly as I am fully aware that TLS client certificates are never going to be picked up by Google as their default authentication scheme..


Figure 1: As always xkcd leaves us with a great impression on the topic

Nonetheless I think it is worth exploring alternatives, as passwords expose a very broad attack vector (mostly due to incorrect usage). Users often times use poor passwords. Users often disclose passwords quite easily. Users generally reuse their passwords which generally doesn't lead to the compromise of a single account but multiple accounts (of multiple users if a whole online service was compromised). Also the DigiNotar attack showed us that TLS is often times not sufficient enough to prevent man-in-the-middle attacks.

During my investigation I discovered a very broad field of research that I never before thought existed with very unique ideas, some of which I am going to depict in this post. First and foremost I came to the conclusion that passwords aren't doomed to be abandoned but may be strengthened security wise in order to offer the user a familiar login experience.


Halfway through my research I stumbled upon a framework which makes it very easy to evaluate authentication schemes. Bonneau et al. presents us this method which is also able to justify the broad usage of passwords even after so much progress in cryptography and tech in general. The framework names 25 different benefits which should be sufficiently addressed by any authentication approach. These 25 benefits are considered under three major topics: Usability, Deployability and Security. Examples for such benefits are:

  • Scalable-for-Users
  • Browser-Compatible
  • No-Trusted-Third-Party

Using this framework the authors are able point out the advantages that passwords provide us and therefore give us an educated answer to why passwords are still the dominant method for user authentication. First of all passwords are easy to learn. This approach has been around forever and possibly will be. Next passwords are really easy to reset which provides the user with some sort of transparency. Personally I think this is the most important thing when it comes to web applications or applications in general. If the user asks herself 'How do I configure my workspace' and the answer is 'I don't know' the approach is doomed to failure. Passwords impose low cost per users. Thus the approach is extremely scaleable for service providers. Next passwords are compatible to the majority of servers and all popular browsers. Hence users are assured that if they sign up for twitter.com they will be able to login on their mobile device. Passwords are non-proprietary. I think this fact really added up to the initial success of this approach.


Initially I want to introduce a rather simple but also in a lot of ways very appealing approach. Ross et al. presents us a simple but powerful idea. Passwords are simply generated on the fly, invisible to the user and on an on-page basis. The approach solves the problem of users having to manage a unique password for each online service. Additionally the approach is able to protect the user from phishing.


Figure 2: PwdHash protects the user from phishing attacks

As previously mentioned the idea is pretty straightforward as can be seen in the figure. The user chooses a single password. When entering the password in the HTML form of the website a browser extension replaces each character entered to preserve keystroke logging attacks. When submitting the HTML form the appropriate browser plugin hashes the user submitted password using the URL as seed value. This hash value is now used as the final password. This way the user automatically ends up with a unique key for each web service. The browser plugin even includes some routines to help the user replace their currently used (unsafe) password.

As depicted by the original paper this approach has some limitations. For instance passwords for amazon.com are not available to amazon.co.uk. A more severe thread to user experience comes from services using a different domain for the password generation, or reset page than for the login page. In this case the user ends up with an unusable password and has to use the service's password recovery function.

The authors thought about a possible workaround for this problem: Use the service's TLS certificate as salt. Though this approach imposes another set of problems:

  • Phishing is now possible again (by generating self signed certificates that generate the same value as the original certificate).
  • The approach is only selectively compatible.
  • Certificate may not always be static. A simple spelling mistake in the organization / common name may cause a change in the certificate thus leaving the user with the only option to use the service's password recovery.

Additionally under certain circumstances PwdHash is not as secure as it initially suggests. Malware modifying the users hosts file bypasses PwdHash's security against phishing as any attacker now receives the correct password. In the same manner PwdHash is not safe against DNS spoofind attacks (without a secure TLS connection). Also PwdHash may be attacked using Javascript attacks such as FocusStealing. Users may access PwdHash if they are using one of the more popular browsers. For instance a Google Chrome extension may be found here.

I am now going to evaluate PwdHash using the previously presented UDS-Framework. Benefits written in bold letters depict differences to password based authentication schemes.


Memorywise-Effortless user has to remember one password
Scalable-for-Users repetitive action for each website
Nothing-To-Carry doesn't require any utilities
Physically-Effortless password needs to be typed
Easy-To-Learn requires same actions as passwords
Efficient-to-Use requires same time as passwords
Infrequent-Errors is as easy to use as passwords
Easy-Recovery-from-Loss doesn't impose any additional action

The strongest characteristic of this approach is the fact that the user now only has to remember a single password. Even in the case of a successful phishing attack other accounts of the user are protected.


Accessible action only changed marginal
Negligible-Cost-Per-User no additional costs to passwords
Browser-Compatible all major browsers supported
Mature full legacy support
Non-Proprietary open source project

The simple approach to user security ensures that there are non deployability issues.


Phyiscal-Observation example: FocusStealing
Targeted-Impersonation users might still use weak password
Throttled-Guessing if the server protects the user
Unthrottled-Guessing provides same as for passwords
Internal-Oberservation eavesdropped connections unsafe
Leaks-from-Other-Verifiers different password for each service
Phishing attacker receives wrong password
Theft no physical defice is needed
Requiring-Explicit-Consent password must be typed
Unlinkable different password for each service

The framework describes Resident-To-Targeted-Impersonation as a benefit which secures the user even when a possible attacker knows personal information about the user. PwdHash does not provide this benefit as users still may use passwords like Joe1986.

As previously said users are now protected from leaks from other versifiers as PwdHash provides the user with a unique key for each web service. Furthermore users are generally protected from phishing as previously stated.

Origin-Bound Certificates

Next up I want to present an approach that also focuses on a familiar user experience while providing protection against TLS MITM attacks and Cookie stealing. Dietz et al. present Origin-Bound Certificates. The approach is based on a TLS extension and is therefore deeply dependent on implementations of TLS being adopted.


Figure 3: OBC used with cookies to end up with a secure channel that isn't limited by TLS connections

Though the approach is simple enough to grasp for anyone with a basic understanding of how TLS certificates work. Initially client and server establish a TLS connection as usual. Additionally the server sends a certificate request upon which the client may send a per origin generated self signed certificate (hence the name). As this certificate may not be used to authenticate the user, the authors thought of another way to establish a secure connection which survives multiple TLS sessions. After the user authenticates herself using the usual username and password the server, as always, the service provides the user with a cookie. Though if the server is sent a origin bound certificate the cookie also contains the footprint of the OBC encrypted with a per service generated symmetric key.


Figure 4: OBC bound cookies allow security against TLS MITM attacks

Now when there has been a certificate authority compromise an attacker may establish a man-in-the-middle-connection. Using OBC's there will be 2 separate TLS sessions established. When the user now sends her previously received cookie containing the footprint of the correct OBC the attacker has no chance but to forward this cookie. The server may unpack the cookies value compare the OBC id's and notify a difference. At this point the server authenticates the client and is able to take further steps, like notifying the client that her account is compromised.

Obviously this method may only secure the user on subsequent logins when a secured cookie is already established. The paper addresses this limitation by referring to another research paper presenting the concept of 'secured login'. In order to install this sort of login further steps have to be involved as described in the next section.

Additionally OBC's are not able to sufficiently secure the user from phishing attacks.


In order to circumvent the shortcomings of OBC's Czesksis et al. present PhoneAuth. PhoneAuth utilizes the user's smartphone to protect the user from password theft (phishing), man in the middle attacks on subsequent logins (as provided by OBC's) but also on the initial login. This includes scenarios where an attacker is able to steal a certificate of a service. Additionally PhoneAuth survives any possible malware installed on the user's machine.


Figure 5: PhoneAuth initial login procedure

PhoneAuth works (as the name suggests) by utilizing the users smartphone. The initial login procedure is performed by going through 4 steps as can be seen in the figure that the original authors present in their paper.

  1. The user performs the familiar login by typing in her username and password. The login credentials are sent to the server.
  2. Instead of logging in the user directly the server sends back a login ticket which is forwarded to the users smartphone.
  3. The smartphone is performing a bunch of tests and creates an id assertion which is forwarded through the browser to the server.
  4. Upon receipt of the id assertion the server sends back a cookie which is protected by the users channel-bound certificate. From this step forward the user is protected as described in the previous section.

So how does this work under the hood? The actual security stems from what is performed in part 3. The main idea is that the server, as well as the browser each present the phone with their view of the TLS connection. Therefore the login ticket contains the users TLS channel ID which is based on the origin-bound certificate the user presented the server beforehand. The browser sends this ID directly to the phone. The phone may now compare these ID's and decide whether to submit an id assertion which is basically a token which tells the server that everything is correct. Additionally the login ticket is encrypted by the server with a previously exchanged per-phone key, which only the phone as well as the server have knowledge of. The id assertion is signed by the phones private key. If there is a man-in-in-the-middle attack the ID's that the phone are presented will differ. Similarly if the user inserts her credentials accidentally into a phishing site and the attacker wants to login in a further step by utilizing the user's phone the ID's will differ as well. In this case the phone is left with a couple of option which are described in the original paper. Basically the authors present different mode's which allow the phone to either stop the login process completely by not issuing an id assertion or by simply notifying the user and or the server that something shaky may be going on. I won't go into the exact details of this subject.

I now want to present the authors evaluation using the previously presented UDS-framework. Again achieved benefits written in bold letters are different to the password approach.


Memorywise-Effortless user has to remember on password
Scalable-for-Users passwords are safe to be reused
Nothing-To-Carry phone must be present
Physically-Effortless password must be typed
Easy-To-Learn no additional action required
Efficient-to-Use no additional action required
Infrequent-Errors missing browser-phone connection
Easy-Recovery-from-Loss doesn't break password recovery

As previously stated the greatest advantage in terms of usability is that the user now only has to remember a single password which may even deployed safely on possible phishing sites. Though the approach is based on a stable connection between browser and phone which the authors want to provide using bluetooth. If that connection is lost (maybe due to technical difficulties) the phone will not be able to hand out an id assertion in order to correctly login the user.


Accessible no additional tasks for user
Negligible-Cost-Per-User storage cost of OBC is negligible
Server-Compatible providers need to patch server setup
Browser-Compatible browsers need to be adjusted
Non-Proprietary system is freely implementable

For this approach to work server as well as browser implementations have to adopted.


Phyiscal-Observation user's phone is required
Targeted-Impersonation user's phone is required
Leaks-from-Other-Verifiers login without phone not possible
Phishing channel ids don't match
Theft password is necessary to trigger login
Requiring-Explicit-Consent user has to type in username/password
Unlinkable phones MAC address is shared

In this section the approach can show it's greatest strength. PhoneAuth is able to comply with all the benefits but Unlinkable. Users of a compromised service may be linked through the phone's MAC address which need to stored at the server. The server needs to post this information to the browser such that the browser is able to communicate with the correct phone.


Next I want to present SQRL which tries to take a completely different approach by not utilizing the username/password approach the user is familiar with.


Figure 6: SQRL operates using a challenge-respond mechanism

The browser presents the user with a QR-code that the user then scan's using her smartphone. The QR-code encodes the URL which is shown in the figure above. On the phone the user stores a master key which is paired with a user provided identity password. This password needs to be provided upon each login. To ensure that a possible attacker is not able to recreate this passphrase the PBKDF key derivation function is used which intentionally uses a lot of computational load to encode the password. The result is used to create an HMAC over the domain which may be extracted from the URL provided by the QR-code. The result of this HMAC forms the user's private key which in turn is used to create a signature over the complete URL. Also the phone creates a public key from the previously computed private key that the server may then use to identify the user. Public key and identity authentication are sent to the server. The server checks these values and returns to the browser which then is able to login the user.

The server is

  1. now able to identify the user for each login session uniquely using the public key which is created from the domain name and
  2. able to ensure that the user is in possession of the private key by checking the signature the server previously received.

Observe that the private, public key are generated from the domain name. This means that there is a unique key pair generated for each domain. Let me again evaluate this approach using the UDS-framework.


Memorywise-Effortless user doesn't need to remember any password
Scalable-for-Users same procedure for each service
Nothing-To-Carry user needs to carry her smartphone
Physically-Effortless user needs to put out her phone
Easy-To-Learn easy instructions to follow
Efficient-to-Use arguably short amount of time to scan QR image
Infrequent-Errors simple enough tasks to perform
Easy-Recovery-from-Loss loss of KEY means loss of per-site-public-key

Again the user has to only remember a single passphrase for every web service. Nonetheless this approach does not comply with the Nothing-To-Carry benefit as the user needs her smartphone to login.


Accessible visual impairment makes approach unusable
Negligible-Cost-per-User service only needs to store users public key
Server-Compatible server setup needs to be adjusted
Mature very slightly used
Non-Proprietary spec may be implemented freely

Also approach doesn't comply with the Accessible benefit. Users with visual impairment may not be able to correctly identify and scan the presented QR-code. Additionally the server setup needs to be adjusted.


Phyiscal-Observation phones master-key prevents impersonation
Throttled-Guessing based on PBKDF
Internal-Oberservation mailware may log user input and access master key
Leaks-from-Other-Verifiers per service key pair
Phishing different domain creates different key pair
Theft user key required
Requiring-Explicit-Consent user needs to scan QR code
Unlinkable different keypair for each service

Security wise this approach presents a pretty good solution. Users can't be impersonated by physical observation as the phone's master key is necessary. Similar to the PwdHash approach this approach is also resilient to Leaks-from-Other-Verifiers as well as Phising. Though there are a few critique points security wise that are not depicted by usage of this framework.

  1. SQRL advertises anonymity but there are two separate IPs communicating with the server.
  2. One could think of a phishing attack where an attacker is forwarding a correct QR-code challenge to a phishing site. Security is now fully based on the users interaction as he has to detect the false URL presented through the phone.
  3. Without TLS the phone may even present the user with the correct domain name when under influence of DNS spoofing.


I want to mention that I didn't include the most popular approach which is used on a broad spectrum already: federated login. Examples for that are OpenID or OAuth. While these approaches may provide great advantages, especially for small scale services (as problems like spamming or security issues are outsourced) they don't really address the most important security issues I wanted to address here: Phishing, as well as TLS MITM Attacks as performed after the DigiNotar attack.

I was surprised that I found such a broad spectrum of research in this field that present really exciting ideas and I am curious on what to expect in the future.