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:
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
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.
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.
|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.
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
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.
- The user performs the familiar login by typing in her username and password. The login credentials are sent to the server.
- Instead of logging in the user directly the server sends back a login ticket which is forwarded to the users smartphone.
- The smartphone is performing a bunch of tests and creates an id assertion which is forwarded through the browser to the server.
- 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
- now able to identify the user for each login session uniquely using the public key which is created from the domain name and
- 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.
- SQRL advertises anonymity but there are two separate IPs communicating with the server.
- 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.
- 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.