Remote personal authentication, most often thought of as token-based authentication, is inherently difficult. But the security community is sorting out ways to make it work. We're going to look at how, but first let's look at the background of the problem.

Verona wishes to verify the fact that she communicates with Paul, who attempts to prove to Verona that he is who he claims to be. Verona and Paul are separated by thousands of miles, connected through a data channel. All that Paul can do to prove his identity is to send over some data to Verona--some bits and bytes, that's all.

But whatever he sends over, Harry the Hacker can send the same and masquerade as Paul. And since Verona does not see, touch, or smell Paul, if the data that she expects from Paul comes her way, then she will conclude that she's communicating with Paul.

Whether it's true or not. The challenge is to find some piece of data that Paul would use and Harry would not.

Any fixed, recurrent piece of data, say a password, poses a problem. Harry can figure out what it is, and use it the next time around. This principle applies also to biometric data, encrypted or otherwise. Recurrent authentication data are inherently insecure. So Verona and Paul decide on a protocol that brings about a different data piece each time around. It's an improvement, but this moves the risk to the mechanism that decides which data are to be expected next.

If this new-data-each-time mechanism is embedded in Paul's computer, Harry can find it. If Paul needs to key in an activation code, Harry can scoop it up with his sticky electronic fingertips. So let's say Verona and Paul deposit this data-generation mechanism in a token, an off-line device--beyond Harry's long arm.

On its face, this seems foolproof. Harry has no way to detect the next identification data because they are generated in a device that is removed from his reach. Alas, the celebration is a bit--or two bits--premature. For starters, Paul's connectivity is hinged on a little gizmo that can be lost, stolen, damaged, or copied. And, according to Murphy's Law, any of these things could happen at the worst possible moment. Paul rushes to get online for a critical transaction, fumbles for his authentication device, and finds the token has slipped through a hole in his pocket.

Infrequent users would not even notice that the device is missing, and is being abused.

They would also tend to forget the gizmo at home, drop it in a cab, or leave it in yesterday's shirt pocket.

Moreover, most of these tokens display a different numeric sequence every few seconds.

This requires an itchy routine: It's quite annoying to copy-fast, before it changes!--a sequence of six digits or more (was that 695515 or 695155?) for each online session.

A better solution is to employ a generic token, one that does not house any secrecy. You can lose it, borrow it, or replace it with no problem. To use it, you punch in a memorized PIN. The output display may be some cool graphics. You point to these same graphics within a gallery of graphics displayed by Verona, and thereby you prove to Verona that you are Paul and not Harry. Harry may have the gizmo, but he does not have your PIN.

Nothing competes with the flexibility and the security of a PIN. It can be adjusted for length, replaced in an instant at no cost, and can be memorized. For these reasons, PIN has an edge over biometrics like fingerprints. The latter, once compromised, cannot be replaced.

Now let's say Harry has switched to a more clever attack strategy. He installs a piece of malicious software in Paul's computer. This so-called worm monitors Paul's dialogue with Verona. No sooner is Verona convinced that she is talking with Paul than Harry jumps in and takes over the conversation. While Paul thinks about what he wants to do next, Harry's wily software empties his bank account.

To meet this new challenge, Verona needs to re-apply the identity-proof protocol before any transaction of consequence (several times within one connection session). This repetition makes it necessary for the proof to be smooth, cool, and as unburdensome as possible; otherwise Paul would lose patience.

Indeed, the state of the art today is a "new data each time" protocol, but the new data-generation mechanism does not lie naked and exposed in a unique, vulnerable token. Harry has not given up though. Stay tuned!