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

This will work if nothing else does

[Profane MuthaFucka]

http://www.targus.com/us/product_details.asp?sku=O CN700

Here's the best solution

[jjbelsky]

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

Why do it the hard way?

[techno-vampire]

Instead of using sticky-tape, have each one engraved with an approprate ID. If nothing else, you won't have to worry about the tape coming off. Your clients can't even really complain, because how's engraving less secure than what you're already doing?

Re:Why do it the hard way?

[Baikala]

If not, will step up to the plate and make it, or at least point me to a site that sells big keychains?"

here you are

Re:Why do it the hard way?

[techno-vampire]

What it the world has your reply to do with my post?

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

[austad]

I had this idea about a year ago and started working on it, and then RSA beat me to the punch. How do you compete against a company for services when you require their equipment and software (that they get for almost nothing)?

They are selling it as a way for banks and other sites to avoid phishing attacks, while allowing customers to only carry around one token. There are some issues with that theory though, and while it may reduce the problem, it cannot eliminate it in its current form. There is a way to fix that though. :)

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

[fyonn]

also, everyone would have to use the same tokens, and some way would have to be found about how to keep everyone's token servers in sync with your token.

when you log in with a token, the server will accept several numbers. if it's something like an RSA time based token, the serveral numbers are accepted due to the time it takes you to read and enter the number (and some clock skew) means that when the server receives the number, the next number is up. this isn't such a huge problem for multiple servers.

the other kind of token has a keypad on (such as safeword), and it generates ba new number whenever you input your PIN. if you log into one of your 6 sites every day, and the other only once every 6 months, then how does the server at the second site keep sync? you've gone through hundreds of numbers at the first site so what number should it expect?

dave

Re:VeriSign's Unified Authentication

[Eivind]

Yes. Sure. Both are workable. And there's lots of other variations that may or may not be worthwhile too. Having the Token be a device that does not communicate with anything in any way other than the lcd-readout and pin-entry-pad has obvious security-benefits though. You don't have to worry about a virus on your smartphone or wonder what info is *really* exchanged between your phone and the bank.

Anyway: designing the protocol is the easy bit (and I say this with a degree in crypto, I'm very much aware that there's a large number of potential pitfalls in this area), the hard bit is the politics of it all.

Re:VeriSign's Unified Authentication

[jonadab]

> It could easily be rolled in to the setup fee on your checking account, for example.

Umm, that would only work if your bank charges exhorbitant setup fees for starting a checking account. My bank (First Federal Bank of Ohio) charges only the cost of having checks printed. You can, of course, order the checks from another supplier if you find a better price on them, so that makes the checking account itself entirely free. Of course, they don't pay you interest on any balance you maintain in your checking account, so they essentially have the (temporary) use of your money in exchange for whatever costs they incur handling your transactions.

Incidentally, I'm not advocating this bank. (In fact, I'm thinking of switching, for reasons having to do with hours of operation.) All I'm saying is, rolling extra stuff into the cost of setting up a checking account may not be universally acceptable. It is my understanding that free checking accounts like this are a relatively _common_ practice, which banks use to get customers.

Two-factor authentication? In small towns and rural areas, people don't even like having their ID checked. "Come on, Bob, you know it's me, and I have to be at work in ten minutes!"

Re:VeriSign's Unified Authentication

[dschuetz]

I've been saying for ages that something like that would be ideal. I hate to suggest that it be maintained by the government, but, really, that's the best place for it. At least the government has to respond to FOIA requests, while Verisign doesn't.

But I'd go even further. Provide a way to key in information specific to a transaction (order number, total cost, and today's date) and you have a way to sign any transaction anywhere, like a phone order or a credit card application.

I managed to find my posting on ths from, OMG, 5 years ago: that goes into a bit more detail.

[blockquoth me]"For large documents, obviously, you're not performing a signature operation on all the text. But, maybe at the bottom of the page, you put your unique public key ID (which is then used to find your public key in a big database), then another line with, say, date, cost, and PO #, then the calculated result. If you lose your little card, you simply go down to the post office (or somesuch), get a new one, and they invalidate the old one for any new use after date X."

The only vulnerability here (aside from someone stealing your card & beating you for the key) is if the service you're signing for doesn't use some transation-unique ID. As long as each transaction has a unique ID, this won't be vulnerable to a replay, no matter who finds a copy of your order.

I also suggested in that post that we find a way to share proximity card information, to reduce all the various speedpasses, gym cards, grocery store cards, etc., to a single thing I can swipe anywhere.

The "nice" thing about all this is that we'll probably finally start to see some motion on this real soon, 'cause isn't there a requirement for US banks to start using some kind of two-factor authentication for websites soon?

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.

Re:VeriSign's Unified Authentication

[dschuetz]

[first, a reply to another comment in this thread...to consolidate the conversation...] OP: You enter this pin into your token, and get a result back that is actually something like: Sign(time+pin+random, your_key) AC: OK, that will prove to the bank that it's really you, but will also expose your PIN to anyone who can intercept the message and has your public key. The "PIN" was probably a bad word choice. That's not your personal PIN, but something the bank gives you specific to the current transaction. Though I'm not sure what the "random" bit was. Basically, it'd be a way to avoid replays from another site with the same timestamp, by making the signature unique to the current login session. Think of it as the bank saying: Here, sign this string: "12345", and you do so, and return the signature. [now, to the other comment] With RSA, the signatures are the same size as the key. Is that really the case? I thought that the ciphertext was just as long as the plaintext (and isn't a signature really just ciphertext?) I think part of what makes a signature long is that you include additional relevant information, like a key ID, as part of the signature. I'd imagine sending the key-id as a separate data point with the signed data, something like this:

plain: 2005-02-09 12345-3 38.45 [date, order #, and cost]
key id: 246-01-0006 19 [SSN and key #]
cipher: 9857 13 87 14238-0 33 12

Doing this over the phone, the droid would give you the first line, you'd type it in, then enter your personal PIN, and then read back the cipher and your key ID. Heck, the thing could even have a display showing all three lines at once for verification. For paper-based systems, you'd fill all three lines into blocks on the form or something. For a web login, they'd presumably already know your key id, so it would just give you a 5 digit code, you'd sign that, and punch in the 5-digit response. Anyway, that's way more than I wanted to respond with. The real question that I haven't been able to verify is whether the ciphertext is significantly longer than plaintext, or if it'd be of similar length (say, within 2 or 3 digits for a 20-character string to be signed). Again, that's presuming we avoid whatever overhead GPG-like systems might add to the signature. I did find that "very small plaintexts" need to be padded, but I got the impression that was only for 0-3 character long plaintexts, so it might not be as big a risk here. Unfortunately, this whole thread is moderated pretty low, so I doubt anyone else will be chipping in to answer the question.

Re:VeriSign's Unified Authentication

[dschuetz]

[[oh, crap, my formatting got screwed up. here's a second attempt at replying.]]

[first, a reply to another comment in this thread...to consolidate the conversation...]

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

AC: OK, that will prove to the bank that it's really you, but will also expose your PIN to anyone who can intercept the message and has your public key.

The "PIN" was probably a bad word choice. That's not your personal PIN, but something the bank gives you specific to the current transaction. Though I'm not sure what the "random" bit was. Basically, it'd be a way to avoid replays from another site with the same timestamp, by making the signature unique to the current login session. Think of it as the bank saying: Here, sign this string: "12345", and you do so, and return the signature.

[now, to the other comment]
With RSA, the signatures are the same size as the key.

Is that really the case? I thought that the ciphertext was just as long as the plaintext (and isn't a signature really just ciphertext?) I think part of what makes a signature long is that you include additional relevant information, like a key ID, as part of the signature. I'd imagine sending the key-id as a separate data point with the signed data, something like this:

        plain: 2005-02-09 12345-3 38.45 [date, order #, and cost]
        key id: 246-01-0006 19 [SSN and key #]
        cipher: 9857 13 87 14238-0 33 12

Doing this over the phone, the droid would give you the first line, you'd type it in, then enter your personal PIN, and then read back the cipher and your key ID. Heck, the thing could even have a display showing all three lines at once for verification. For paper-based systems, you'd fill all three lines into blocks on the form or something. For a web login, they'd presumably already know your key id, so it would just give you a 5 digit code, you'd sign that, and punch in the 5-digit response.

Anyway, that's way more than I wanted to respond with. The real question that I haven't been able to verify is whether the ciphertext is significantly longer than plaintext, or if it'd be of similar length (say, within 2 or 3 digits for a 20-character string to be signed). Again, that's presuming we avoid whatever overhead GPG-like systems might add to the signature. I did find that "very small plaintexts" need to be padded, but I got the impression that was only for 0-3 character long plaintexts, so it might not be as big a risk here.

Unfortunately, this whole thread is moderated pretty low, so I doubt anyone else will be chipping in to answer the question.

Re:VeriSign's Unified Authentication

[BeBoxer]

With RSA, the signatures are the same size as the key.

Is that really the case? I thought that the ciphertext was just as long as the plaintext (and isn't a signature really just ciphertext?)

I won't go into detail here. The Wikipedia entry for rsa explains it better than I can.

I don't know enough about other asymmetric algorithms to be able to say that this is always the case though. Elliptic Curve for example makes my head spin. But according to Wikipedia it is believe to require a key size only twice the "security parameter". So if you were happy with 64-bit level security you would only need 128-bit elliptic key. If you encode into 64 valid characters [a-zA-Z0-9()] for example, you get 6 bits per typed character. So you are down to 21 characters to type, and I would say you are pushing the upper limit of what users can be expected to type for a login and at the same time barely meeting a minimum level of security.

Re:VeriSign's Unified Authentication

[turbidostato]

"designing the protocol is the easy bit"

Which, down to the bare bones reads like this:

You don't want the company you play with to provide you the "secure token", or else you fastly will end with a ton o'such tokens: you want to be the one to provide *them* the tokens so, somehow, you can provide them all using the same one.

"the hard bit is the politics of it all"

Which, down to the bare bones reads like this:

There's the perception of quite a lot of money around this, so quite a lot of companies want to be the ones taking their piece of the cake (or the biggest piece of the cake if allowed). That you will end up with a worse, uncomfortable and more expensive service is just neglegible "collateral damage".

Re:VeriSign's Unified Authentication

[Eivind]

There are digital signature schemes where the signature can be small and still secure. (obviouslz if you want the likelyhood of guessing no higher than 2**80, you obviously need a 80 bit signature, but it doesn't need to be 512 bit. (yes RSA works like that, the world is bigger than RSA)

That being said, you may be rigth that it'd be more practical for the device to be connected to the computer somehow, for example USB. That does however bring a whole host of new security-problems. First of all you need to ENSURE that the device CANNOT sign-off on something without the user actively asking it to, and that it CANNOT sign-off on something other than what the user thinks he is signing.

Those are tricky in a world where you cannot, for example, assume that no malicious code is running on the users computer with superuser-rigths. But tricky doesn't mean impossible -- it just requires great care.

In any case, my main point wasn't how to do this -- it seems we both agree it's possible. My main point is that VISA, Verisign and the other major players does not WANT to do this. *THAT* is the reason it won't happen aslong as payments are handled by them, aslong as they're not forced to do it.

Re:VeriSign's Unified Authentication

[Eivind]

The random bit was just an implementation of the idea that in general you *never* want to sign something that someone else gives you, unaltered. This is so because of the birthday attack.

Finding two messages that has the same has has only the sqrt of the complexity of finding a message with a given hash.

Thus, because you don't (completely) trust the bank, you want to make sure you're not signing one out of a PAIR of messages they produced with the same hash. You can acomplish this by adding some nonsensical random bit before signing.

Re:VeriSign's Unified Authentication

[BeBoxer]

There are digital signature schemes where the signature can be small and still secure. (obviouslz if you want the likelyhood of guessing no higher than 2**80, you obviously need a 80 bit signature, but it doesn't need to be 512 bit. (yes RSA works like that, the world is bigger than RSA)

It would still be a pain to use. Can you imagine standing behind folks at the grocery store as they try to enter even 80 bits of information into a keypad?

That being said, you may be rigth that it'd be more practical for the device to be connected to the computer somehow, for example USB. That does however bring a whole host of new security-problems. First of all you need to ENSURE that the device CANNOT sign-off on something without the user actively asking it to, and that it CANNOT sign-off on something other than what the user thinks he is signing.

If you make it a dedicated piece of hardware, it's pretty easy to ensure no malicious code is installed on it. When you start moving into the realm of "let's use the cell phone, because everybody carries one" or "we'll just do the signing on the PC itself" of course it becomes much harder.

My main point is that VISA, Verisign and the other major players does not WANT to do this. *THAT* is the reason it won't happen aslong as payments are handled by them, aslong as they're not forced to do it.

Yes, that's the frustrating part. Knowing that there is a better way, and we'll probably never see it deployed. A dedicated signing device would be useful in tons of situations, and I doubt the hardware would cost more than USD$50 at most in bulk. While the initial deployment might be costly, the long terms savings in reduced fraud, time saved from dealing with forgotten passwords, etc would pay for it in no time I would think.

Re:VeriSign's Unified Authentication

[Eivind]

The hardware would *certainly* cost no more than $5/pc in bulk.

Another example of something useful that'll never happen because it's not comercially/politically wanted is truly secure, anonymous, digital cash. The needed protocols have been known for over 20 years, and the infrastructure is basically there. But it just won't happen.

Someone will wave the "It'll make it possible for criminals to anonymously transfer money", or "The terrorists will use it!", or "It'll be used to pay for child-porn" card, and instantly render the entire idea moot.

Sad really. There would be *large* benefits to a secure, desentralized standard that achieves over the net what normal cash does in person. (If I give you a dollar-bill you also don't need to know who I am, you only need to be reasonably confident that the bill itself is valid)

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

[ePhil_One]

And, before last year, calling something 'a tsunami' outside of oceanographic circles probably would get you a lot of strange looks

Right, nevermind that The Cartoon Network network thought there was enough awareness of the word to use it as a pun for a block of shows called Toonami. Or do you think the named it after the disaster?

Re:-1, Bad Metaphor

[Somegeek]

Just because you didn't hear the word used don't extrapolate that to mean that no one else knew it either. Most people who lived on the ring of fire were probably already familar with the term, as well as anybody who was decently well read, even if you didn't see it in the media. Some of us acually learn things from other sources than TV.

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.

Cellphone

[mattr]

Leave your tokens at the office/home and call your coworker/wife. Won't work in an underground data center though, unless you can run fast. I don't think I'd recommend a webcam.

Re:-1, Bad Metaphor

[karnal]

Isn't tsunami the default cisco wireless access point SSID? or is it Extreme?

I forget....

Re:-1, Bad Metaphor

[jonadab]

> And, before last year, calling something 'a tsunami' outside of oceanographic
> circles probably would get you a lot of strange looks

All educated persons in the English-speaking world know what a tsunami is. This has not changed since the events last year. Granted, a lot of vocabulary-impoverished people have _also_ picked up the word now, but that's a temporary effect. The phonemics of the word are sufficiently foreign to the English-speaking ear that in a couple of years many people will go back to calling it a "tidal wave". This is neither here nor there. This is slashdot, so we assume you know how to use the internet: if somebody uses a word you don't know, you can head over to dictionary.com or Wikipedia or someplace and look it up.

> A tsunami is a giant wave, you're talking about drowning in a sea of tokens.

A sea is stationary. He appears to be implying that he's been suddenly deluged with tokens, overcome by a plethora, inundated under a veritable torrent, buried under an avalanche of tokens. Sure, there's a bit of hyperbole going on, but we understood what he was saying. Well, some of us did.

Project Liberty

[davecb]

Liberty is 150-odd companies working on common authentication, because ordinary one-factor authentication doesn't scale either (;-)).

Participants who use two-factor authentication, and supposedly there are a few, only need one token card.

See http://www.projectliberty.org/

--dave

Another alternative...

[stungod]

Disclaimer: I work for this company.

Take a look at Corillian Intelligent Authenication. It performs 2-factor authentication without the need for a token. While it won't help you keep track of your existing key fobs, it's a good alternative to using those when you have a choice.

Re:-1, Bad Metaphor

[RandomLetters]

It's been Toonami for years. It's their japanese animation and anime-esque block. I think most people knew what the pun was and those who didn't probably didn't care because it was a cartoon block.

Actually, this isn't a bad idea...

[cr0sh]

With a few of modifications, this system could actually work for the submitter's (and maybe other's) needs:

• Multiple USB (or other) cameras pointed at each fob
• All connected to a webserver which is accessed via it's own 2-factor fob, held by the owner

That's the basics. It could be simplified or expanded in numerous ways. You could have a single camera, for instance, and a stepper-motor controlled by the server rotating a turntable on which the fobs are mounted, to take the pictures of the fobs automatically in-turn. Add in a high-contrast lighting scheme, couple the camera with some edge-detection and/or OCR software, and have the computer interpret the numbers (or enhance the image) so that you know exactly what to type (when I went to the site it was difficult to read the fob image). Put the whole thing inside a modified safe or lockbox, inside a locked room, for better physical security (even better than carrying them around, I would think).

The server itself would have to have its own 2-factor security token fob to access it, so the user of all the fobs would only have to carry around a single fob, instead of a "keychain" of fobs. Also, though I don't know if this is practiced where these fobs are used (or if it breaks the system and isn't?), if multiple users need access to all the fobs, then they each can carry their own fob to get to the fobcam system, which can be set up to allow this (I would imagine). Perhaps in certain setups, a 4-factor auth scheme could be done - with the user's fobcam access fob, and the "fobcam" stored fobs providing the numbers (would prove who access which system).

Please note: here is a niche problem in need of a solution - I have just outlined step 2 of the business plan above - we all know what steps one and three are, of course...

Mutli-domain compliant, open-source solution

[nowen]

Tokens and other shared-secret systems can't support multiple domains for obvious reasons. WiKID is a commercial open source solution that uses public key cryptography. Thus it can support more than one authentication domain without a drop in security.

commercial site, open source site & sourceforge site

We are currently killing bugs in the OSS system, adding more app support and adding mutual authentication. Then we will make it less 'rpm-based' for other distros. feedback is very welcome. disclosure: i am with the company.

these things are a stupid idea

[ecloud]

Why not just use smart cards? One card could handle multiple keys anyway. Combine that with a PIN and you have 2-factor auth without the hassle of having to manually type in long strings of random numbers every time.