In Cryptography, the concept of Authentication serves to provide proof that the other side of a communication is indeed who they claim to be, and who you intend for them to be.
There are multiple ways to verify the opposing party’s Authentication. We will look at three of the most common:
- Username and Password
- Digital Certificates
Username and Password
Using a username and a password to identify who you are to a server is extremely common. Each user on a website can create a unique username, as well as a password tied specifically to that user. If the user is able to reproduce the password, then we can be assured that they are indeed the user they claim to be.
This is how most bank websites and email clients identify who you are.
The password itself should not be sent across the wire. That would easily lead to potential compromise. Instead, the password is run through some sort of hashing algorithm, and the resulting digest is then sent across the wire.
On the receiving end, it would be poor security practice to store the user’s passwords directly. Instead, all that is stored is a hash of the password. Then, the digest sent with the user can be compared to the digest in the server’s password database to see if they match. If they match, then the user must have had the expected password.
This is why most online websites that use a username and password are unable to recover lost passwords — all they can do is reset them. The password itself is never stored, only the digest of the password — which, as you recall, is impossible to reverse engineer and ‘decrypt’.
Within this Authentication scheme, there are three different types of passwords that can exist:
- Something you know
- Something you have
- Something you are
Something you know
This is is the common password. You memorize a series of letters, special characters, words, and/or numbers, and you prove you know them when asked for the password.
This scheme is susceptible to users using weak passwords, storing them insecurely, or reusing them for different websites.
Something you have
This requires you to reproduce a physical object that only you can have in order to validate you are who you say you are. An ATM card or a employee badge are examples.
Today, many websites will send a random code to your phone via SMS when you are trying to log in, forcing you to have possession of your phone to log in. In such a case, even though you are inputting the random code to prove you are who you say you are, the code’s purpose is simply to validate that you have your phone.
This is also the same concept behind the various authentication tokens in use today. You carry it around, and when you need to identify yourself, you input the code on the token (which changes every 30-60 seconds). If you can put in the code the server is expecting, then you must have had the token.
Often, the code you input is further prefixed or suffixed with a password known only to you. This would then create a system that validates who you are with both something you know (the password), and something you have (the token).
Something you are
Lastly, the various types of bio-metric identification fall under the category of something you are. Systems like fingerprint scanners or retina scanners or hand-print scanners all identify you based upon an attribute that is physically tied to who you are. Only you can have your hand. Only you can have your eyes. And so on.
Facial recognition, or even voice recognition, also falls under this category.
A password can be eavesdropped or shoulder-surfed. A token or mobile phone can be stolen. But bio-metrics can not be compromised without seriously maiming or killing the user being impersonated.
Many websites or security services offer or require what is known as Two-factor Authentication. This means the user is being identified from a password scheme from two different categories above.
For instance, the example above of a random code sent to your phone via SMS and your regular username and password is a perfect example of Two-factor authentication. To successfully authenticate against such a system you would need to both know your password, as well as have your mobile phone.
If a website simply required you to enter two passwords, or a password and a pin, this would not qualify as two-factor authentication because both methods of authentication fall under something you know.
The concept of Pre-Shared-Key authentication is to share a secret key or passphrase between two communicating nodes, then see if the two nodes can show proof of having said key.
This Pre-Shared-Key (PSK) should be shared out-of-band. For example, if you mean to use PSKs to prove someone’s identity on the other side of the Internet, you should not use the Internet to share the key. You might use the phone, or a fax machine, or carrier pigeons.
Later on, if either node can show they have the correct PSK, it proves that the party on the other side of the wire is indeed the same entity which you initially exchanged the PSK with.
Obviously, simply sending the PSK across the wire to prove you have it would be a huge security flaw. We also can’t simply run the PSK through a hashing function and send the resulting digest, because an eavesdropper could then capture the digest and spoof our identity in the future by reusing the same digest.
Instead, you would want to combine the PSK with values that are tied to that particular authentication session, so that the hash of the PSK is only good for that one session.
For example, in the case of IPsec, both parties generate and publicly exchange a random number. The PSK is then hashed together with both random numbers, and the resulting digest is shared. If both parties can generate the same digest, then they must have had the correct PSK. Furthermore, if an eavesdropper captures the verification digest and tries to reuse it to spoof the identify of one of the parties in a future session, they will be unable to because the future session will have different random numbers.
There are two primary differences between Pre-Shared-Key authentication and Username and Password authentication. The first: the PSK must be initially shared out-of-band. It can not be initially established using the medium upon which you want a secure connection. The second: the PSK is shared among two individuals, whereas a username and password is always unique to each user (or ought to be, at least).
The final authentication scheme we are going to discuss is that of Digital Certificates. This is the primary method of identification in use on the Internet. The protocols securing your browsing session when visiting a webpage of HTTPS make heavy use of Digital Certificates (SSL/TLS).
A digital certificate works similar to a driver’s license. It contains the identity of a particular individual or website, and it is issued by a governing entity (the state you live in).
Inside a digital certificate is a very important piece of information: a Public Key of an Asymmetric Key Pair. This key is used to verify that the entity who presents the certificate is the true owner of the certificate. Much like your picture or signature on your driver’s license.
Recall that with an Asymmetric Key pair, one key is kept private and never shared with anyone, and the other key is made public. Anyone can get a hold of anyone else’s digital certificate (and therefore, public key), but theoretically, only one person can exist with the correlating private key. Before accepting a digital certificate as proof of someone’s identity, that someone must provide evidence that they are in possession of the matching private key.
There are two ways this can be verified. We’ll take a look at an example of Alice presenting a Digital Certificate to Bob, and how she can provide evidence that she is in possession of the private key.
- If Alice presents Bob with her Certificate, Bob can generate a random value and encrypt it with Alice’s Public Key. Alice should be the only person with the correlating Private Key, and therefore, Alice should be the only person that can extract the random value. If she can then prove to Bob that she extracted the correct value, then Bob can be assured that Alice is indeed the true owner of the certificate.
- Alice can encrypt a value known to both parties with her Private Key, and send the resulting Cipher Text to Bob. If Bob can decrypt it with Alice’s Public Key, it proves Alice must have had the correlating Private Key.
These two methods are the basis for how authentication works with digital signatures.