We create and use user accounts without thinking about it, but how do they actually work and how do they keep our things secure?
A user account is a digital identity used by a person or piece of software. The identity allows us to associate things in the digital world with a real person or a specific application. In an ideal world, a user account will only ever be used by one person or one instance of a software application. Unfortunately, that isn’t always the case. (More on this later).
How Do User Accounts Work?
Identity and Access Management (IAM) is a framework of processes and technologies that enables us to manage digital identities and the things people do with them. A commonly used model which describes what we need from digital identities is IAAA.
- Identification of an individual as the owner of a user account
- A way to Authenticate the identified individual as the legitimate owner of the user account
- A way to Authorize the authenticated user to do things while preventing unauthorized users from doing them
- A way to hold the owner of the user account Accountable for anything that their account does
Identifying User Accounts
All user accounts need a unique Identifier to distinguish one account from another. Typically this is in the form of a username, a user ID number, an email address, or a phone number. Some applications support several of these at once, but as long as you have at least one unique label then you’ve met the minimum requirements.
From a users perspective, automatically generated user IDs are difficult to remember and work with. My given name is Craig Hays. I can remember this and variations of this easily. I’ll struggle to remember more than one or two software-generated numbers and I’ll definitely never remember a 16 digit UUID randomly generated for me by a piece of software. For this reason, software developers often allow users to pick their own usernames.
Some developers ask people to pick their own username. Other developers or administrators automatically generate usernames. This can be based on people’s names, e.g. ‘Craig.Hays’, adding a dot between the first name and surname. Others default to using your email address or telephone number as a username which means they capture your contact details at the same time as picking your unique identifier.
User Accounts in a Real Application
Take Twitter, for example:
The first thing you see when you open the Twitter website is a login page that asks for your phone number, email address, or username. When you type anything into that input box along with a password in the password field it checks all three types of user identifier for a match, then compares your provided password against the one held against the specified account. While most applications insist on giving just one of these options, accepting all three creates a better user experience. This, however, also comes with some security challenges which must be addressed during software development.
A password is a piece of information that we use to Authenticate the person asking to access a user account. While the user identifier such as a username, user ID, or email address, can be publicly known, the password must be kept secret. When a user provides the correct password we must assume that they are the legitimate owner of the user account. When a password is guessed or compromised, it can be very difficultly to distinguish between the real account owner and someone else who is abusing it.
Once a user has identified themselves and verified that they are who they say they are with a password or some other piece of secret information, it doesn’t necessarily mean that they’re permitted to do anything within an application or data. To grant access to resources we set and check a user’s permissions to Authorize users to perform some while denying other actions.
At a very basic level, Twitter’s permission model for user posts has just two permission levels:
- Public – tweets by a given user are visible to everyone
- Private – tweets by a given user are visible only to followers, (other users who have requested and been granted permission to see that user’s tweets)
Even if you successfully log into your own Twitter account, you won’t be able to see posts from anyone with a private account unless you request permission to follow them. If your request is ignored or denied, you won’t be able to view them.
Logging Actions Performed by a User Account
In order to hold a user Accountable for actions they perform with their account, we need a way to record what they’ve done. We generally refer to this as logging. Every action performed is documented in a transaction log somewhere. For some applications, this information is kept private and accessible only to the application developers. For other applications, such as Facebook, you can see your Activity Log of everything you’ve ever done with your account.
In some situations, accountability isn’t very important. If you ‘like’ a photograph on Instagram it is unlikely that anyone will want to know about it in future. (Unless you’re stalking someone and a court wants to use it as evidence). If you’re sending money between bank accounts, however, an audit log of what actions have been performed is very, very important. Without an accurate log of what has been done, how can we guarantee that the information that we hold is correct and hasn’t been tampered with? How can we prove that it really was you who sent a large sum of money to someone else?
Tokens and Other Forms of Secrets
Sometimes we want to give others access to a user account on our behalf. The easiest way to do this would be to give them our username and password, but that would be bad for many reasons. If we let them someone else log in with our password, they look just like us and can do anything we can do, including changing our password to something else.
Instead, when we need to give someone else access to an application on our behalf, we tend to use some form of token. A token is usually a long string of characters which is generated by an application. The software creates it for us when we first log in with the correct username and password, or when we ask for it.
The most basic form of token is a session token. When you log into a web application you’ll receive this in the form of an authorization header or a cookie. Regardless of the form used, it’s just a string of random letters and numbers which only you know. Rather than sending your username and password with every message you exchange with the application, you simply provide the token. The token proves that you have already identified yourself, authenticated yourself as the real you, and links to a list of things you’re permitted to do.
Another form of token is one which other pieces of software can use to operate on your behalf. Rather than giving out your password you can generate and pass this token to the third-party software and it will use it to prove that you’ve given it permission to do things for you. One of the benefits of this method is that you can limit the permissions set against the token to only specific things. “Yes, you can post on my Twitter feed, but no, you can’t change my password or delete my account”.
Previous: Course Introduction