Practice Cryptography!

Okay, so it's time to go back to basics as to just what authentication really is, and try to recognize some things that aren't usually looked at. Please bear with me if you already know this topic; you might find some stuff out that you otherwise wouldn't think of. (And if you comment in reply to this post, I might learn something.)

First off: Authentication is the process of ensuring that a given identity has performed a given task. (We 'authenticate' documents, for example, by verifying that the signature matches, by verifying notary seals, and so on.)

However, 'authentication' is not the same thing as 'authorization'. Just because I sign a contract selling a corporation that I have no interest in to someone else for $1 doesn't mean that I'm authorized to do that. Sure, the document can be authenticated as being from me... but since I'm not authorized to perform the action that I purported to perform, that action is invalid.

'authentication' is intimately tied to 'identity' -- it is our identities that are authenticated and evaluated for authorization. We each hold many identities, as I've said before... and each identity is valid for actions within the context that it is valid within.

Now, the entire process of authentication (verifying that I was born and that it is me who is actually performing an action) is very cumbersome. I'd have to show my birth certificate, social security card, and anything else that I have that might prove that I am who I say I am. This is the concept of the 'credential'.

A credential is a document which is issued by a trusted authority, which authority's signature or manufacturing process or whathaveyou can be authenticated. The act of trusting that authority is 'authorizing' that authority to issue a credential. Confused yet?

My driver's license is a credential. My passport is a credential. My birth certificate and name change order are credentials.

However, these are all "things that I have"... which is one type of credential. Showing these is only showing 1 type -- which could get hairy if my documents are all stolen from me, and someone else who looked just like me attempted to use them to pass himself off as me, basically forging an authentication as me.

This is where two other types of authentication come into play: 'something you know' (some secret you know, such as your bank card's PIN, or how to sign your signature), and 'something you are' (something that is integral to your body -- fingerprints, retinal blood vessel patterns, DNA chains, etc).

An authentication mechanism that combines two of these factors is called "two-factor authentication"; one that combines all three is called "three-factor authentication".

But even then, just because I authenticate does not mean that I'm authorized to perform a certain action. (This is something that programmers need to understand -- even though I can authenticate, just the fact that I'm in the database does not mean I'm automatically allowed to do anything.)

Now, things on the web have historically come down to one (or a half-assed two) factor authentication -- I know my username and password, both pieces of information [thus, 'things that I know']. For X.509 client purposes, I have a certificate which may or may not be password-protected ['something I have']. But how do I get into these databases for possible authentication, anyway?

Normally, I have to prove my identity to some agent that is accepted (authenticated and authorized) by a credential-issuing authority. This system has flaws, obviously... such an agent is only human, and any person can be bribed into creating a false credential. A false credential can be used to gain another credential. And so on.

So. The basic point of this is "just because someone can authenticate doesn't mean that they should be allowed to do what they're requesting to do." Many intranet developers forget this. Many intranet developers just think "oh, they're in the database, they're okay to see the internal memos and such". But what happens when, say, a third-party company decides that they're going to form a two-way trust relationship with your authentication system? Suddenly, anyone in that other company can authenticate, as well -- which may NOT be appropriate.

Another important problem in cryptography and encryption practice that was recently brought up on the NSS mailing list is the problem of "man in the middle" attacks in SSL and TLS -- from the view of the server.

With the way that SSL and TLS handle various aspects of the protocol, it's nigh-impossible for the server to be forged to the client. (This is mostly due to the requirement that the server present a trusted certificate to the client.)

However, the same cannot be said for the reverse path. Since clients do not have certificates (as a general rule), anyone who can capture the data provided by the client to the server can replay that data. (Historically, this hasn't been viewed as a problem, but in these days of worms and viruses and keyloggers and rootkits, the client side is now more vulnerable than the server to attack. Since SSL and TLS only protect the wire protocol from eavesdroppers and malicious intruders, the data is unwrapped at either end of the connection. Servers generally have fairly stringent safeguards as to how the information they process is controlled -- but clients have to deal with users running code that they really shouldn't be.)

As well, there's just too damned many problems with client certificates as they stand anyway. Have to export private keys and certificates to move them from machine to machine (exposing them to rogue processes), have to import them (and hope the new machine isn't running any rogue processes), have to do this for every machine that is used, thus allowing credential information to be stored on many machines when security best practice says "keep it on one machine with one backup"...

There are many issues associated with this; however, one possible solution could be a "temporarily loosely bound" keypair... where the client presents a self-signed certificate with no information other than the public key to the server, and the server builds a new 'identity' from that keypair... gradually adding elements as they're learned, as the server can identify and authenticate the credentials. Then, when the user logs out of the server's context, the identity information associated with that public key by the server can be cleared.

This would prevent the problem of a man-in-the-middle attack for as long as that session lasted, but there needs to be a more reliable and more useful "one-time password" or time-based authentication system (as an example, RSA's SecurID) to prevent the credentials from being stolen by malware.

Some of the research in this field (preventing malware from gaining passwords and such) is actually being done by online game companies, such as MapleStory Global [must use MSIE to access]. Within their game client, they have a "PIN" system that randomizes the location of numbers on an on-screen keyboard, and the user must click in their PIN in order to log in. Combined with another technology which prevents the process from having a debugger attached to it (if you attempt to debug the process, the secondary thread is notified and immediately kills the game client), this helps reduce the ability of key- and mouse-loggers to steal login credentials.

Will this help? Eventually, even this will probably be gotten around. It's a constant arms race -- but it would certainly be helpful for banking applications and the like.