Everyone knows what passwords are, and how they work. Right?
The basic concept is simple enough, and has been around for quite a long time. Before the advent of electronic computers, soldiers would use a password to identify themselves as “friendly” at least as far back as the time of the Roman Republic (https://en.wikipedia.org/wiki/Password).
Of course, it’s never quite that simple. To understand passwords, first we need to define the term, then establish some context.
Defining your terms is vitally important, especially when using terms which have common meanings in addition to technical ones. As an example, I remember an all-day meeting, many years ago, in which a group of Finance professionals argued over the definition of “revenue” for about a half-day! (This was in the context of data warehouse for management reporting.) Do we include “pass-through” revenue from sub-contractors? Do we include receiveables older than 90 days? What about receiveables older than 120 days? In the end (after about another year), we had at least three different “types” of revenue – and I still have nightmares!
Or, what about defining an “office”? Do you mean the physical office in which we (at least prior to COVID-19 lockdown) sit? Or the “HR office” for our reporting hierarchy? Or the “GL office” for invoicing? Or - but I digress.
In Information Security, we normally talk about “Identity and Access Management” (IAM), which is listed as “Domain 5” of the CISSP exam (https://www.isc2.org/).
Three key concepts in Identity and Access Management are “Identification”, “Authentication”, and “Authorization”. Or, more simply: “Who are you?”, “How do I know you are who you say?”, and “What are you allowed to do?”.
Let’s say that Alice (https://en.wikipedia.org/wiki/Alice_and_Bob) is trying to log into the newest social media site, “sociallyawaremedia.com” (Which does not exist, at least when I first wrote this).
Who are you?
Alice begins by creating a new user account. Most of the time, this will be a unique user ID which identifies Alice, and her alone. Much ink (both physical and virtual) has been spilt discussing different ways to identify people, such as name, Social Insurance Number / Social Security Number (SIN/SSN was once used fairly frequently, but is no longer acceptable for most systems), student ID, last name + first initial, etc. Among the more common approaches nowadays are to use the email address of a person, or allow the person to select their own user ID.
It’s worth noting a few of the challenges associated with identifying users. If the user ID is user-selected, the user may end up with different user IDs for different sites, which can quickly become difficult to manage. Using an email address seems like a convenient approach, until you think about the fact that you may have multiple email addresses, or may change your email address (for example, if you change jobs). More on all of this in future posts, probably – it’s a fascinating topic.
In any case, Alice decides to create an account named “alice” (fortunately, no one has selected this user ID previously), and this will be her identity on this site.
How do I know you are who you say?
What if someone else goes to “sociallyawaremedia.com” and enters the user ID “alice”? This could be “our” Alice, someone else named Alice who has forgotten the user ID, or maybe someone who wants to see what Alice is up to... <ominous music>
Let’s call this last individual “Malice”. How can we stop Malice from looking at Alice’s private information? This is where we get to the password. If Alice sets a password, only someone who knows the password will be able to access the user ID “alice”. This ensures that only Alice can be authenticated on this site. Or does it? More on this later.
What are you allowed to do?
What a user can do depends on a number of factors, which may vary by system, type of user, membership status, even age! Once a system knows who you say you are (identity), and you prove that you are who you say you are (authentication), you will be allowed to do certain things (authorization). In our example, once identified and authenticated, Alice will be able to post updates, read posts, and make friends.
So, now that we know what passwords are, and what they are for in theory, we can consider how they work in practice. In some older (or insecure) systems, the password was simply stored in a file somewhere on the computer being accessed, and the system would simply compare the entered password with the password associated with the user ID entered. (Selecting a “good” password is another topic. See https://www.til-technology.com/post/infosec-bullshido-password-complexity-rules for a bit more on this)
So, Alice would log into “sociallyawaremedia.com” and enter her user ID (alice) and her password (ecila). The system would check the password file under “alice” and ensure that the entered password (ecila) is the same as the password it has in the file.
What could possibly go wrong?
Assuming the login page and processes are secure (by no means guaranteed, as such processes should be considered to be under near-constant attack), the password file is a prime target. If Malice can get it, ALL accounts on the system are available any time Malice wants, with no one the wiser. Not good.
So, what if we encrypt the password file? Better. Malice would need to access the password file AND find the encryption/decryption key. If it’s well-protected, Malice may not be able to get at it. Unfortunately, systems are attacked every day, so there is no guarantee that the encryption/decryption keys are 100% safe. Also, Malice could take a copy of the file and spend as much time as necessary to try and “break” the encryption/decryption key. If successful, Malice again has access to all accounts.
Can we do better? (Incidentally, the answer to this question is almost invariably “yes”)
Now that we know what hashing is (https://www.til-technology.com/post/infosec-basics-hashing), what if we store a HASH of the password instead? Much better! Alice would enter a password, the system would hash it, and would then compare the hash with the hashed value in the password file. The actual password would not be stored.
However, if the hashing algorithm is “weak”, or the password is relatively short, Malice could try to use a “rainbow table” (https://en.wikipedia.org/wiki/Rainbow_table) to pre-calculate the list of possible hashes, then try to match the values in the file of hashed passwords. It can be extremely time- and resource-intensive, and generates huge files, but Malice is persistent, and it only needs to be done once for a given hashing algorithm. If successful, Malice would be able to “crack” most or all of the passwords on the system. If we use a strong cryptographic hash (particularly if designed specifically for password hashing) and enforce long passwords / passphrases, we can make this process much harder.
Still, Malice has a lot of time and resources... Is there anything more we can do? As it happens, yes. We can add salt.
Er, what?
A “salt” (https://en.wikipedia.org/wiki/Salt_%28cryptography%29) refers to a random string that is added to a password before hashing it. While the origin of the term appears uncertain (https://stackoverflow.com/questions/244903/why-is-a-password-salt-called-a-salt), the idea is to add an additional string to the password to make it harder to use rainbow tables.
To see this, consider that the size of a rainbow table will increase exponentially as the length of the password increases. If the password/passphrase is sufficiently large, it becomes “computationally infeasible” to use a rainbow table. An additional benefit is that, if two users select the same password, the salt will be different, so the resulting hash will also be different. All of this means that Malice would need to find the salt for Alice’s account, then spend a lot of time/resources to generate a rainbow table using that salt. Even if successful, that rainbow table would only be effective for Alice’s “salted” password – to crack all accounts, Malice would need to find the salt values ahead of time, then generate a unique rainbow table for EACH ACCOUNT. (Also, if Alice’s password is changed, Malice would need to start all over again)
To correctly implement a salt, the system generates a random string of sufficient size and stores it with the password. (It doesn’t need to be encrypted, but should be relatively large, and unique for each password stored). A system using a good, cryptographic hash designed for password use and a large, random salt for each password is a nighmare scenario for Malice. In practice, it makes the password file nearly useless.
How about pepper?
(Facepalm) Really?
Yes. Really.
A “pepper” (https://en.wikipedia.org/wiki/Pepper_%28cryptography%29) is an additional value which is added to the password and the salt, prior to hashing. It differs from a salt in that it should be “secret” (ie, NOT stored with the password), and applies to the system, not the individual user account. So, to break the password, Malice would need to know the pepper ON TOP OF all the cracking required to deal with the hasing and the salt.
The use of a user ID / password is very common, and easily understandable, but a LOT of the security depends on the system. It can be very hard to judge this from the outside, because it’s not visible, but you can make some educated guesses. Is there a documented security policy which describes issues like password length and the protections used? Does the service offer / encourage / require multi-factor authentication (MFA)? Does the system limit the length of passwords? (In general, there should be a minimum length, but NOT a maximum length – a topic to address at some other time)
How about adding cinnamon? Ok. That one doesn’t exist. (at least so far as I know...)
Cheers!
Comments