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

RSA and Blackberry

[sam1am]

RSA does offer the RSA SecurID Token for BlackBerry Handhelds - multiple tokens from one device may be possible..

Here's the best solution

[jjbelsky]

This fellow pointed a web cam at all his keychains. Problem solved: http://fob.webhop.net/

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

[Peterl]

Of course this leaves us stuck with Verisign being the single vendor and the single point of failure. No doubt they're going to price themselves accordingly once they get a commanding share of the token market. And, of course, they're sure to protect our records and not resell that data. Um, yeah.

Ideally, you could use any token that met the standard. Buy your own, or the company you need to use it will will sell you one (perhaps subsidized or free depending on their business model). It could easily be rolled in to the setup fee on your checking account, for example.

Smartcards aren't particularily expensive these days.

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. :)

Re:VeriSign's Unified Authentication

[BeBoxer]

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

I don't think this actually works in practice. Who wants to type a digital signature into a web form? No, really. It would be such a collosal pain in the ass nobody would do it. Think about it. You could go with a 512 bit RSA key (quite weak by todays standards.) With RSA, the signatures are the same size as the key. So to type the signature into a web form you need to enter 512 bits of information. If you could actually enter all 255 ASCII codes in directly, it would be 64 key presses. A more realistic example would be entering a 1024 bit signature in hex. That's 256 characters to enter!

Even standard tokens, which use symmetric ciphers, don't have the users enter the entire output of the encryption. Just enough to make guessing unlikely (7 or 8 digits usually.) This works because both sides know the correct "answer" and can calculate the subset which is actually being transferred. But with a public key signature, only one side can calculate the answer. The other side can only verify it. And to verify it, they have to know the entire result. You can't take half of an RSA signature and verify it.

Which isn't to say your idea is totally off base. It would work great IF your token connected to the computer via USB or something. But doing that requires software on the PC, and some sort of more sophisticated web authentication. Entering something into a field in a form won't work. It's a great idea, but has much higher hurdles to adoption.

Federated Authorization

[forsetti]

Oddly enough, I'm at a Identity Management conference in Tempe AZ right now. Although in practice, getting all of your service providers (customers, bank, etc) into a single federation is probabably near impossible, getting them into a smaller number of bridged federations may happen through business needs and market pressure within the next few years. Check out technologies like Shibboleth (http://shibboleth.internet2.edu/) or Liberty Alliance.

Re:-1, Bad Metaphor

[gstoddart]

who doesn't know what a tsunami is?

Now? Absolutely nobody I should think.

Eighteen months ago? Probably at least 3/4 of the entire planet.