Common Encryption Pitfalls

I recently came across AcessURL. AccessURL is an online service which offers an easy way to allow access to online accounts without sharing the account password.
Unfortunately, their initial implementation had some security issues. In this post, I will describe and suggest how to fix these issues. It is important to say that AcessURL since solved these issues.

These kind of mistakes are very easy to make and they are relevant to almost any online service. My aim is to provide information that will be useful for both web users and professional web developers. Feel free to skip parts you’re already familiar with.

Passwords security

If you already know how to select and use passwords securely you can jump to Logins and sessions

First let us take a look at the service AcessURL offers, how it works and why it is necessary.

Many people find it useful to share their online accounts with others. For example, you might want to let a friend access your LinkedIn account to touch up your resume or let a family member access Netflix to watch movies. But to allow others access, usually means you need to share your account password, which is a really bad idea.

Passwords should not be shared. Not between services. Not between people. If you use the same password for LinkedIn and Gmail your “friend” might decide to snoop around and have a look at your emails. Even if the passwords are not exactly the same it might be easier to guess other passwords (that’s why you should use a password manager and completely random passwords). And even if you have a unique and random password, once you give it to someone else, she can do with the account whatever she wants.
If your friend (we’ll call her Eve) is a bit naughty she can keep snooping around as long as you don’t change your password. If she is a bit more malicious she can change the recovery e-mail and password and completely take over your account. AccessURL provides a solution for this problem.

Logins and Sessions

If you are familiar with cookies and sessions jump to the part 2 security issues

So we want to give access to Eve, but we don’t want to give her our password. Additionally, we want to be able to revoke Eve’s access once we decide to. How does AccessURL do this?

AccessURL does not rely on or have access to usernames or passwords. AccessURL relies on cookies instead. On most websites, that means if you sign out, everyone using your Access URL will get signed out too. This is one of the ways AccessURL prioritizes security above everything.

What AccessURL are cleverly doing instead of sharing passwords is providing an easy way to share browser cookies. Among other things, cookies are used by websites to know who the user is.
After the user initially logs in a cookie is used to remember him.
For instance another user, we’ll call her Alice,  sends the site her username and password the site verifies the information and asks Alice’s browser to save a cookie with a unique and hard to guess value like “bm4hTGw%vrj701pVIr0newmi“. On each new request to the site, Alice’s browser will send the cookie “bm4hTGw%vrj701pVIr0newmi” and the site will remember that this cookie belongs to Alice and that she must be the one making the request. Once Alice is done using the service and logs out, the site recognizes that Alice is done using the cookie “bm4hTGw%vrj701pVIr0newmi” and will forget it. If Alice or anyone else will try to use this cookie it will not work anymore.

Therefore if Alice uses AccessURL to share her session cookie with another friend (Bob), and Bob’s browser now sends the exact same cookie as Alice, the service they are using will think Bob is Alice even though he never actually logged in. If Alice wants to stop Bob from using the service all she needs to do is log out and Bob will also be logged out.
(Unfortunately many sites fail to forget the user token once users have logged out. They rely on the browser to stop using the cookie. Therefore Bob might still be able to use the service he accessed through Alice although she logged out. In addition, some sites will try to protect users from their cookies being maliciously stolen and might be able to detect someone other than Alice is using the cookie. But these issues are a bit out of scope for this post).

AccessURL even took user privacy and security to a higher level by making sure they encrypt the cookie information before it leaves the browser  –

By design, AccessURL’s server cannot read user’s data. It doesn’t have the password (which is unique for each Access URL). The Chrome extension encrypts the data before it reaches the server and doesn’t give the server the password. For encryption, AccessURL uses the industry-standard: AES.

So this all looks pretty good and secure what were the security issues?
Part two – Security issues with AccessURL original implementation