Floating in the Two-Factor Authenticator Tsunami?

gmerideth asks: "Working as a security consultant, I have access to a multitude of clients' networks through physical and VPN connections. Recently, due to the on-going issues of data theft, our clients have started implementing two-factor authentication using different providers. The result is a keychain that I carry around with our company key, clients keys, and a key for online access to my local area bank. I am slowly drowning in a sea of two-factor authenticators with sticky tape on the back of them, so that I can remember which key belongs to whom. What alternatives are there? Are there open projects or private products that provide a remote, secure, trusted authentication service that can provide for network/VPN authentication for Windows and Linux, using a single key among separate, private networks? If not, will step up to the plate and make it, or at least point me to a site that sells big keychains?"

Comments

VeriSign's Unified Authentication

[elawford]

Verisign are trying to solve this problem by introducing their own two-factor authentication solution that is standards based and, at its heart, centrally managed. Its based around OATH (http://www.openauthentication.org/>) which is supposedly an open standard for two-factor authentication. The cool thing about Verisign's offering is that they pledge to be the owners of the backend 'token store' for everyone.

The biggest problem at the moment and the reason we have so many tokens floating around is that these tokens need a 'seed record' stored somewhere secure. The seed record is used to authenticate the numbers you type from the token each time you login . Noone gives out these seed records as they're essentially the 'keys to the kingdom', so we're stuck with one token per service. Theoretically, if your token issuer would give you a copy of your seed file, you could then pass it on to anyone else so you could use that token with their service. Usually, they're reluctant to do this (security reasons, ownership isses, impractical, too difficult etc) so noone really shares tokens at the moment...

Verisign want to take that token store and centralise it - essentially outsourcing part of the token management. This means you can re-use your token with anyone else who uses the Verisign system.

Sounds great in theory, but the real challenge will be getting enough people to switch over. Its a real 'who jumps first problem', not to mention who fronts the cost of the tokens initially ('why should I pay for your token when you're going to use it with 10 other companies, and probably my competitors?' kind of thing). Anyone had any experiences with it, good bad or ugly?

Re:VeriSign's Unified Authentication

[Eivind]

The biggest problem is that all the big comercial players who play this game want to own the game.

So, while for customers (both users of the tokens, AND institutions implementing them) a standardised token usable, anyone with the required market-presence and expertise to pull it off has ZERO interest in doing it.

It's worse than that even. Not only will Verisign, Visa, Mastercard and all the others do NOTHING to help a token that would be standardised and usable by anyone. No, indeed they'll all be willing to spend MILLIONS to hinder the development and adoption of such a token.

The actual design of a standardised token does *not* in any way shape or form require a globally shared secret. (which is a dumb idea for a gazillion reasons anyway.

Here is a simple outline of one of the many ways it could be achieved:

Token contains a secret key, a pin-entry-pad and a lcd-readout, it also has an internal clock.

The corresponding *public* key is known to the owner of the token.

When you wish to be able to authenthicate to someone, say your bank, you somehow convince them that public-key so-and-so corresponds to your token. (for example you can physically show the token on opening an account)

Come login-time you go to the banks site. The bank presents you with a PIN.

You enter this pin into your token, and get a result back that is actually something like: Sign(time+pin+random, your_key)

You enter this and your username in the bank form.

Bank checks that your signature is valid, that the PIN is the one they gave you, that the time is within +-10 minutes of now and lets you in.

The protocol has problems. It's not supposed to be a finished proposal. Rather it's intended to show that designing such a system so that anyone (anyone you wish to be able to that is) can authenthicate you, without any globally shared secret, indeed without any shared secret at all. The only secret is your secret key, and that stays in your token and is shared and known by noone (not even you, unless you somehow do hardware-disassembly and figure it out)

This ain't new or rocket-science. ssh has done something similar to this for literally decades. (well atleast 2 of those)

What's stopping this ain't technology or cryptography. It's politics and greed. Verisign *WANTS* a system where verisign is a needed component between *every* online entity and *every* customer. They *don't* want an open, decentralized system like the one I propose here.

Re:VeriSign's Unified Authentication

[Hes Nikke]

Here is a simple outline of one of the many ways it could be achieved:

Token contains a secret key, a pin-entry-pad and a lcd-readout, it also has an internal clock.

And you should already have one in your pocket - your cell phone.

When you wish to be able to authenthicate to someone, say your bank, you somehow convince them that public-key so-and-so corresponds to your token. (for example you can physically show the token on opening an account)

Come login-time you go to the banks site. The bank presents you with a PIN.

-OR-

The bank injects its seed/key into your phone, then when you want to log into the bank, you find it on your phone and enter the key on screen. This allows everyone to have a separate key for each link of trust, making things just a little bit more secure. :)