Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
Security

Floating in the Two-Factor Authenticator Tsunami? 45

Posted by Cliff from the coming-soon-to-keyrings-everywhere dept.
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?"
This discussion has been archived. No new comments can be posted.

Floating in the Two-Factor Authenticator Tsunami? More

Floating in the Two-Factor Authenticator Tsunami?

Comments Filter:

  • RSA and Blackberry (Score:4, Informative)

    by sam1am ( 753369 ) on Wednesday February 08, 2006 @10:50PM (#14674586)
    RSA does offer the RSA SecurID Token for BlackBerry Handhelds [rsasecurity.com] - multiple tokens from one device may be possible..

  • Here's the best solution (Score:5, Funny)

    by jjbelsky ( 689709 ) on Wednesday February 08, 2006 @11:05PM (#14674660) Homepage
    This fellow pointed a web cam at all his keychains. Problem solved: http://fob.webhop.net/ [webhop.net]
    • 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 automaticall

  • 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?

  • VeriSign's Unified Authentication (Score:5, Interesting)

    by elawford ( 564089 ) * on Wednesday February 08, 2006 @11:17PM (#14674710)
    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?

    • 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 roll
      • > 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 check
    • Comment removed based on user account deletion

    • Re:VeriSign's Unified Authentication (Score:5, Interesting)

      by Eivind ( 15695 ) <eivindorama@gmail.com> on Thursday February 09, 2006 @03:22AM (#14675607) Homepage
      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.

      • 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
        • 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 t

          • "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 th
      • 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 postin
      • 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
        • [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
          • 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 nonsens

        • [[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
          • 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 [wikipedia.org] 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
        • 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

          • 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
            • 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, a



    • 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
  • A tsunami is a giant wave, you're talking about drowning in a sea of tokens. And, before last year, calling something 'a tsunami' outside of oceanographic circles probably would get you a lot of strange looks. So an additional -1,Pop-Culture mod applies.

    Wow, if only we could moderate submissions.
    • 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 [cartoonnetwork.com] network thought there was enough awareness of the word to use it as a pun for a block of shows called Toonami [cartoonnetwork.com]. Or do you think the named it after the disaster?

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

  • Federated Authorization (Score:3, Informative)

    by forsetti ( 158019 ) on Wednesday February 08, 2006 @11:41PM (#14674822)
    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/ [internet2.edu]) or Liberty Alliance.
  • 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.
  • 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/ [projectliberty.org]

    --dave

  • Disclaimer: I work for this company.

    Take a look at Corillian Intelligent Authenication [corilliansecurity.com]. 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.
  • 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 [wikidsystems.com], open source site [wikidsystems.net] & sourceforge site [sourceforge.net]

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

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

Slashdot Top Deals

"The Amiga is the only personal computer where you can run a multitasking operating system and get realtime performance, out of the box." -- Peter da Silva

Close