Forgot your password?
typodupeerror
Security Technology

Two Factor Authentication Systems? 69

Posted by Cliff
from the something-you-know-and-something-you-have dept.
HerculesMO asks: "I've been given a project to undertake that involves setting our internal network systems up to have two factor authentication. I need suggestions to take in front of our CIO that shows how the security model works, cost vs benefit/features, and the different options. At this point, the name brand is RSA and I'm pressed to find any others even though I've done looking around. We are open to biometric tokens as well, because they may be used for digital certificate signing for e-mails. Sadly, it has to integrate with our Windows 2003 Active Directory set up... it's not Linux, but I figure Slashdot readers can come up with lots of Linux security tokens that will work under Windows too, so please have at it! :)"
This discussion has been archived. No new comments can be posted.

Two Factor Authentication Systems?

Comments Filter:
  • RFQ (Score:5, Insightful)

    by chris_mahan (256577) <chris.mahan@gmail.com> on Wednesday October 26, 2005 @07:39PM (#13885333) Homepage
    RFQ to vendors. Let the CIO compare the proposal. Don't do his job. He's not cutting you a slice of his salary.

    What you might ask /. is what to put in the RFQ together.

    But you know your system and requirements best.
    • Re:RFQ (Score:3, Funny)

      by QuantumG (50515)
      because he's lying. He doesn't have a job, or a CIO, he's a kid in his parents' basement submitting to Slashdot.
  • Can weaken security? (Score:4, Interesting)

    by molo (94384) on Wednesday October 26, 2005 @07:43PM (#13885373) Journal
    My corp just switched to a two-factor auth. Previously, things were based on the cisco VPN where the client had to have a certificate (but not an individual-per-client certificate). We then had to log in with our domain login and password.

    Now we have switched to cisco VPN plus RSA software token. This is not any better. Now we have a certificate, rsa token, and then we enter a pin number, as short as 4 digits.

    This has not improved security one bit, it has actually weakened it. If a laptop is stolen, the "piece you have" went with it. The software token doesn't provide any security over the vpn certificate. Then, the "piece you know", the PIN, is significantly weaker than the old piece you had to know, the domain password (which was a real password with moderately strict rules on complexity).

    The whole thing is a counterproductive wankfest. Perhaps you can do it better, but this should be an example of what not to do.

    -molo
    • DOn't you have to enter in a number off the RSA token? At our company, we have a certificate as well, but we have to enter in a PIN + number off the token. that number changes every minute and more accurately represents the thing you have than the certificate.
      • We use the same RSA/Cisco setup where I work. And no, you don't have to enter any other numbers. A few people still have the hard tokens, or key fobs, and they do have to enter the number plus pin. With the soft token, you can open it up in one window and see the same sort of numbers, but they are evidently fed into the VPN client automatically. All I enter is a 4-digit numeric PIN!
    • If a laptop is stolen, can't that "piece you have" be de-authorized? If not, there's hardly any point in having it.
  • by emag (4640) <slashdot&gurski,org> on Wednesday October 26, 2005 @08:10PM (#13885559) Homepage
    You've got a couple choices if you want a token-based dual factor authentication scheme. Of course, there's RSA's SecurID that you already know about. There's also CryptoCard, which IIRC can emulate some of the RSA tokens, and has its own scheme.

    Now, what's nice about SecurID is AFAIR it's the only token that does *time*-based auth (ie, the displayed number sequences change constantly as a function of elapsed time). However, there's a really ugly problem with their auth servers that we accidentally discovered trying to set up a replicated server for failover purposes. To wit: the servers only sync based on a timed (as opposed to event-based) schedule. So, in the normal course of events, you can sometimes reuse the same token (# stream on the hardware device) even though they supposed to be single use. This happens when you attempt to have both servers service requests, and login 1 uses server A to authenticate against, and login 2 ends up using server B to authenticate in a very short period of elapsed time. Server A hasn't had a chance to tell server B yet that it's already seen that particular number sequence, so B happily accepts it.

    Now, the devious-minded can see a problem here... You can be sniffing a network connection, get the token, pin, and password from the network ("hey, we have these hardware tokens, why should we ssh/ssl/vpn?" or what annoyed me, "we can't use ssh key authentication, we *must* use password auth with this"), then DoS one of the auth servers, and attempt a login with the same credentials, hoping to get an alternate, not-yet-synced auth server. Bang, you're in (eventually). So much for the whole non-replayable 2-factor authentication thing.

    I don't think this problem was ever solved satisfactorially (I've since moved off that contract), but you can "solve" it by only having a single auth server...

    Unfortunately, I know a lot less about CryptoCard, since we went with SecurID ourselves and didn't find the warts until later.

    Oh, yeah, good thing this is just windowss, as linux was ok, but Digital Unix and Irix were a bitch to get working with SecurID.
    • 1. If your network runs in the clear, with no network crypto protecting your connection, you've always got a potential risk of session hijacking, let alone more elaborate schemes to subvert the an array of networked authentication servers. The connection between an RSA Authentication Server and it various application-based ACE Authentication Agents that report to it is encrypted, but that doesn't protect other network links, nor the integrity of the TCP/IP session itself.

      2. Neither CryptoCard, nor any oth

  • Think bank cards (Score:3, Insightful)

    by redelm (54142) on Wednesday October 26, 2005 @08:14PM (#13885584) Homepage
    Something you have PLUS something you know. One without the other is no good. Neither needs to be extremely strong. A number of companies make "smartcards" that plug into kbds, USB devices and PCMCIA cards. Use them with "PINs"

  • easy. (Score:3, Funny)

    by croddy (659025) on Wednesday October 26, 2005 @08:34PM (#13885719)
    just encrypt the usernames. now you can leverage your existing authentication to move forward with a two-factor security plan!
  • by embobo (1520) on Wednesday October 26, 2005 @08:41PM (#13885751) Homepage
    http://www.smallbusinesscomputing.com/webmaster/ar ticle.php/3498116 [smallbusin...puting.com]

    It gives pointers to various offerings, including one-time passwords, hardware tokens, smart cards, and biometrics.
  • by Anonymous Coward on Wednesday October 26, 2005 @08:58PM (#13885835)
    Two-factor authentication was a big part of the recent eBay-VeriSign deal. The headlines all mentioned eBay buying VeriSign's payment processing unit for $370 Million. But the agreement also calls for eBay to buy up to 1 million two-factor authentication tokens from VeriSign for use on Paypal [netcraft.com]. eBay will start rolling out the two-factor authentication tokens to Paypal and eBay users in 2006, including marketing and security programs designed to "promote customer adoption."

    This is significant, since you have a lot more phishing attacks targeting Paypal and eBay than the major banks these days.

  • Secure Computing has what appears to be a very strong competitor to RSA's SecurID. Their SafeWord product is similar to SecurID, but appears to have some advantages. For one, it only generates tokens when you request it to. I believe it's cheaper too. It supports Active Directory. I've not used it, but their demo was impressive. And Secure Computing is a fairly good security company.
    • I used to think this was an advantage, but it is not. The reason is that if an attacker tricked a user into typing in their next few passwords, they could use it at their leisure, instead of having to use it immediately.

      It's still more secure than a static password though.
      • Wow, excellent observation. I was just considering that it saved a lot of battery over the SecurID. But the time restriction for each token is sort of an extra factor in the authentication. (Although it's a pain in the ass when the SecurID tokens get out of sync.)
  • Smart cards (Score:5, Insightful)

    by swillden (191260) <shawn-ds@willden.org> on Wednesday October 26, 2005 @11:37PM (#13886615) Homepage Journal

    There are several providers of smart cards for use as a second authentication factor. The one I'm most familiar with is ActivCard [activcard.com]. Their stuff is reasonably good, and if it helps in your corporate environment IBM Global Services has a team that does a lot of ActivCard integration, so you can get plenty of support from a reliable provider (for a price :-) ).

    IMO, smart cards are a better solution than SecurID tokens. They're cheaper, allow your logical authentication token to be the same card you use as an ID badge (and perhaps for door access) and can do a lot more things. They can act as one-time password generators, just like a SecurID (but guarantee non-reusability of the passwords, unlike SecurID, as mentioned by another poster) but they can also:

    • Store public/private key pairs and certificates for strong web authentication, e-mail signing and decryption, PKI-based login, etc. Most cards can even generate the key pair on-board so that the private key *never* leaves the card, for when non-repudiation is valuable (signatures, mostly).
    • Store username/password pairs for situations where one-time password or PKI authentication isn't workable. Done properly, it can be arranged so that cardholders never need to know the passwords, which are large, randomly-generated and changed automatically and frequently. That makes password-based systems nearly as secure as one-time password or PKI, but doesn't require fixing all of the apps.
    • Store biometric templates to allow a third authentication factor to be deployed without a central database of biometric data. Note that, IMO, biometrics are highly overrated as a security device for logical access control. Still some people want them, and smart cards can help make them more manageable.
    • Provide other services, like electronic cash for the cafeteria, etc.

    The major disadvantage of smart cards as compared to SecurID tokens is that smart cards have no display, so you need a smart card reader to use them. This means that, for example, you could use a SecurID to authenticate to a corporate web site from an Internet cafe, whereas you might not be able to attach a smart card reader to some random PC. As a partial solution, handheld, calculator-like smart card readers exist that can retrieve a one-time password from the card and display it on a screen. I say it's a partial solution because carrying two devices is less convenient than one SecurID. The cost of such a device, plus a card, plus a regular PC-attachable card reader all totals to something less than a SecurID token.

    Disclaimer: I work for IBM Global Services, in the group that does smart card stuff, including ActivCard integration work, so I have some biases, but I also have a deep knowledge of the industry and, at present, I think the ActivCard product set is the best choice available, overall. Cryptocard has some good stuff as well, but it's not as complete or as mature, especially in the area of enterprise card management (issuance, re-issuance, revocation, etc. all needs to be integrated and automated, complete with automatic key escrow and recovery, etc.). Both ActivCard and Cryptocard support Linux and OS X, though ActivCard's support for Tiger isn't there yet, and Cryptocard's is, mostly. ActivCard also supports Solaris, including SunRay environments. IBM has some nice assets that we use to build customized solutions, but our stuff is focused more on multi-factor biometric authentication for physical security than logical security.

  • "Two" means two.

    "Factor" means factor. ...

    This concludes your intensive six-week training course.
  • A few pointers... (Score:2, Informative)

    by eldub1999 (515146)
    First, two-factor authentication is pretty much two-factor authentication. There are moderate differences in the various forms, but that is usually not the driving factor.

    The biggest and most overlooked issue is the requirement for client-side software and drivers. The various OTP solutions (SecurID, etc.) are zero footprint. They can be used from any computer. If portability is as imporant as strong authentication, you should consider an OTP solution.

    Smartcards and biometric devices require drivers at a mi
  • On the flip side (Score:3, Insightful)

    by QuantumFTL (197300) * <`moc.liamg' `ta' `kciw.nitsuj'> on Thursday October 27, 2005 @03:12AM (#13887362)
    As with all other so-called "security" schemes, it comes down to trusting the luser. Unfortunately in today's climate, this seems to be a losing proposition. "Something you have, and something you know" becomes "Something you can lose, and something you can forget."
    • Re:On the flip side (Score:3, Interesting)

      by psykocrime (61037)
      Unfortunately in today's climate, this seems to be a losing proposition. "Something you have, and something you know" becomes "Something you can lose, and something you can forget."

      Or worse yet, "Something that can be removed from your body with a saw;" in the case of biometrics. This is why biometrics don't appeal to me... if somebody wants my id with a password or smartcard, they don't have to do serious physical damage to me to get it (granted, they might anyway just to be malicious) but with biometrics
      • Or worse yet, "Something that can be removed from your body with a saw;" in the case of biometrics. This is why biometrics don't appeal to me...

        You said it, man.

        P.S. It's this kind of thing that makes me want to vote libertarian, as maybe companies won't be as stupid as the government about such biometric identity...
    • I think the poor user gets a bum rap on this, and on many other aspects of the technology that gets laid upon them. It wasn't the users who stuck themselves with multiple passwords, of limited length, each of which can be typically cracked with a moderate amount of time on a password cracker.

      It wasn't the users who, as passwords became more vulnerable, laid upon them these Draconian rules which mandate routine changes in all passwords, each to conform to some standard of sufficient complexity that guarran

    • As with all other so-called "security" schemes, it comes down to trusting the luser. Unfortunately in today's climate, this seems to be a losing proposition. "Something you have, and something you know" becomes "Something you can lose, and something you can forget."

      I'd say this is why a great many security schemes fail: contempt for the user

      Contrary to what many believe the computer is there to help someone do a job, not to be an impenatrable vault for information. Anything you do that makes things o
  • by antlope (926281) on Thursday October 27, 2005 @05:49AM (#13887678) Homepage
    Combining SSL, username and password together with a simple One Time Password delivered by pager, mobile text (SMS) or even voice mail, gives good two factor authentication. Several companies provide good solutions that are of differing level of complexity to integrate.

    Check out this link for more information on one time password authentication. I work for this company so of course I'm biased =) but its the best OTP service I've used. It will integrate fine with your AD or any other LDAP/SQL user source.

    http://www.nordicedge.se/produkt_otp.shtml [nordicedge.se]

    The major reason why hardware tokens are not so popular in my experience is that people think they are clumsy to lug about everywhere. Even the keychain versions are annoying. Smart cards are great but you need a computer with a smartcard reader.
    I think we'll be seeing more and more applications aimed at users mobile phones, for the simple reason that everyone likely to use an online service is also likely to have a mobile phone.
    Most people are much more likely to notice a lost or stolen phone, than a lost or stolen token device...

    Good Luck in your solution.
  • The server asks you to hash a string.

    You run a program locally (here's some [demon.co.uk]) or incorporate it into your client in which you enter your password and it spits out the 5 digit hash. Tell the server what the hash was, it compares it to what it thinks you should have entered.

    All very simple and works just fine over unencrypted links !

    plan9 uses it for ftp access

    Apache / Firefox also support something similar for HTTP Authentication - your password is md5'd with some salt instead of just being base64'd

    that is al
  • vasco ? (Score:2, Informative)

    by ncostigan (127923) *
    one of the largest players, at least in europe, for 2 factor is vasco security (belgium?)

    my bank (SEB in sweden) has been using them for years.
    the system is pretty easy to use. you don't need a CS major to work it. /nc
  • PortWise (Score:2, Informative)

    by pehag (926320)
    check out PortWise, it will give you one solution for OTP with lots of different authentication channels like Blackberry, Mobile Text, Mobile Token and so on. www.portwise.com
  • Sadly, it has to integrate with our Windows 2003 Active Directory

    Why troll?
  • PassGo (Score:2, Informative)

    by petegc (926326)
    I work for a company called PassGo Technologies. We have a two-factor authentication system called Defender that is fully integrated with Microsoft's Active Directory. All of the administration for the product is performed using the standard "Users and Computers" interface and all of Defender's information is stored in AD. As fas as I am aware, ours is the only two-factor authentication solution to provide this level of integration. Defender can provide strong authentication to VPNs, SSL VPNs, UNIX devi
    • Please, please tell me PassGo is not using the same broken ANSI x9.9 authentication as the old Axent Defender products (e.g. SNK-004).

      The Defender Hand-Held Token [defender5.com] looks exactly like the old (physically unreliable) Axent Defender tokens, which used the (withdrawn in 1999 [x9.org]) x9.9 Asynchronous authentication algorithm which was later proven to be extremely weak crytographically.

      Many existing token products, including Vasco, Safeword, and ActivCard include support for x9.9 for backwards compatibility, as do a

      • PassGo supports the Hand Held Token for customers already using the token and who wish to continue to use it. PassGo has working relationships with all the current major token vendors including Vasco, ActivCard and Aladdin and support for their latest devices has been added into Defender.
  • by cr0sh (43134) on Thursday October 27, 2005 @12:29PM (#13889697) Homepage
    Probably one that violates half-a-dozen patents, but is fairly easy to implement.

    • Something you have
    • Something you know

    The second piece is simple - this is your password, just as it always has been. The second piece is not as simple, but not as hard as you think.

    First, determine (or guesstimate) the average number of logins a user will do in a day to your system (whatever it is). Let's suppose it is three times a day (that may be a ridiculously low number, I know). Take that number, and multiply it by the number of days that you want to allow the use of "something you have" - let's say 30 days (or approximately 1 month). So, there you have 90 unique instances. Multiple that number by something I will call the "secure factor" - that is, the number of "somethings I have, to type in" - let's say in this case "4", for a total of 360. Take the square root of that and round up to the nearest whole number (in this case, 19), square it again to get your "number of values" - or in this case, 361.

    Now, have your system generate 361 keyboard typeable characters and store them as a string in the user's login profile. Present this list to the user as a grid of numbers (in this case, a grid 19x19), marked off along the X-axis by letters, and the Y-axis by numbers. For a website this system would be VERY easy to implement.

    When the user updates their password (which expires each month), they get a new grid of numbers to print out and keep with them. When the user logs in, the system presents a challenge to them for them to type in as part of thier login procedure - in our case, 4 "secure factors", like "A7 D9 A18 E10" - and they would have to type those characters from their grid into the provided area. The system would then take this, check it against what it has stored in the user's login profile, and if those numbers match, the login matches, and the password matches, the user is allowed access. Those numbers used are "marked off" as used in the user's profile, and a different set is picked on the next login. When all sets are used up, the user is prompted to change their password, thus generating a new set for the user as well (with instructions to throw away the old set). This system should allow for 3 logins a day for 30 days, or a shorter combo which expire quicker because you run out of values (longer combos will expire on the password expiration).

    Thus, essentially, the "what you have" becomes a grid one-time-pad, generated when the password for the user is updated. For this system to be truely secure, the grid should be delivered over a secure channel (in the case of a web server, SSL) when it is generated. Other issues to think about is what to do if someone is trying to guess the one-time pad (maybe they have a scrap of it?) - maybe flag the account on a wrong attempt and have the user update the password? You would also need to think about what to do if the user has lost the pad.

    All in all, this solution or something similar could be pretty robust, fairly compact (if you make the printed OTP compact), and portable across all systems. Plus, it is fairly easy and cheap to implement (and train for). However, as I cautioned in the start, it is probably a patented method, but I think such a system is so obvious I wouldn't be surprised if there existed a PEAR (PHP) or CPAN (Perl) module for it...

    • This is insecure for three reasons:
      • At every log in the user exposes some of the 19x19 grid, so an attacker can just eavesdrop until he has a fair part of the matrix and then keep trying to log in until he get only squares that he knows. This will take a fair amount of the attacker, but with a little patience he'll know alot of the matrix at the end of the month so he would prob. need (know half the matrix) ~2^8 to (know 1/4 of the matrix) 2^16 tries before succeeding.
      • It's very susceptible to
      • The poster said that each element in the matrix is only requested once.

        So no part of the matrix is every repeated; the eavesdropping attacker can't do anything with learned matrix elements, because the system will never ask for those elements again.
        • Ok then do the following: Initate the log in 19x19 / 4 times and the system will be totally locked. Note you can't reuse unanswered request - problem easy for 1st year cryptology students, so left to the reader.

          And the 2 other problems still pose a big problem.

          Face it - the idea is crap. Don't fix a bad problem (passwords are weak) with crap - all you get out of it, is a system that stinks.
          • Yes, the idea is "crap" but the fact is it's a one-time pad. The attacker cannot gain unauthorised access in the way you described. The attacker can cause a Denial of Service, but they won't get access.
            • It might prevent a purely eavesdropping attack - at the cost of easy denial of service attack, but both phishing and man in the middle will work (very well at that).

              And there is no one-time pad in the suggested solution. One-time pad is a (secure) encryption. There is OTP = One time passwords, which can be secure. The above would work I guess if you threw in
              • SSL conenction at log on
              • server certificate
              • educated users that actually check the complete correctness of the certificate each time
              • and a secure connec
              • I'm not sure what your point is. I was just clarifying that the eavesdropper could not learn the contents of the user's OTP card in the way you described.

                Whilst I don't pretend to have the knowledge of even a first year undergrad specialising in cryptography, I have studied basic cryptographic techniques as part of my EE degree, and my understanding of the term "one time pad" is that it describes Alice and Bob both being in posession of the same list of arbitrary sets of data which can be utilised as secret
                • Note - I am the original poster...

                  I have read over all of the comments, and yes, they all have merit. I may not have made it clear, but I was hoping to get across the idea that both the delivery of the OTP and the entry of the factors from it would be done via an SSL (or other) secured method.

                  Since my knowledge of crypto is weak (as clearly demonstrated by the numerous and insightful responses), I am curious as to how, if the delivery of the OTP and entry of the factors is done via SSL, how a man-in-the-mid

                  • Don't take my word for it, I'm just a lowly EE with a passing interest in crypto... but as far as I can tell, your propositition isn't particularly any more vulnerable to a man-in-the-middle or phishing attack than other methods.

                    You probably know already what MITM is about, but let me waffle on some more :-) It behaves totally transparently to both the end-user and server, as if it wasn't even there, and making itself a part of the un-encrypted communications path - monitoring all your actions in plaintext.
                  • My main comments was that this was particular more secure than normal OTP passwords, so why bother to make a matrix with the information ?

                    And no there isn't anyway that you can make this secure (as the other poster have said in his reply there is always the man in the middle).

                    What you need to make this secure is some advanced cryptology (or said in other words - don't try this at home kids).

                    The are several approaches, one being Zero-Knowledge (ZK). ZK is a proof that you know a secret without telling the r
                • Bob and Alice sharing the same secret is called shared secret.

                  A one-time-pad is when you use a shared secret to encrypt a message by taking the message and the shared secret and xor'ing them together.

                  Note that:
                  1. The key and message must have exactly the same length
                  2. The shared secret must be a uniform random (i.e. a shared sentence will not be enough)
                  3. The shared secret can only be used once

                  If that is satisfied it gives you the only provable 100% secure encryption (provided the shared secret is secret fo
  • Clearly your company lacks the skill set to submit an RFP outside of Ask Slashdot. You can temporarily hire an outside consultant to manage this process. Once the selection is made you'll need someone to manage the contract, then the product and vendor relationship and problem tracking . . . .

    Dogbert Consulting Services
    We secure your cash so you don't have to

  • Did you consider WiKID Systems?

    Available in both open (https://sourceforge.net/projects/wikid-twofactor/ [sourceforge.net]) and closed source (http://www.wikid.com/ [wikid.com] versions. Closed source supports wireless devices such as Blackberries, Palm, PocketPC J2ME. Unlike certs, there is no need to manage white & black lists (CRL) etc. Unlike RSA soft tokens, the PIN is stored on the server and communication between the token and the server is encrypted asymmetrically. If the token is stolen, the PIN must be checked at the
  • tokenrevolt.com
  • I have to wonder if you don't mean three-factor authentication. After all, most systems already have two-factor authentication:

    - Username
    - Password

    A system that simply lets walk-up users enter with no regard to who it is uses no authentication (think of a Windows system that boots to the desktop with no password prompt). A system where you have to identify yourself (username) but not verify the identity (password) uses one-factor authentication (think of a Windows system where there's a password prompt, so
    • Simple answer: No

      Why: UserID and Password are both from the same factor: Something the user knows

      http://en.wikipedia.org/wiki/Authentication [wikipedia.org]

      The methods by which a human can authenticate themselves are generally classified into three cases:

      Something about the user
      e.g., fingerprint or retinal pattern, DNA sequence (there are assorted definitions of what is sufficient), voice pattern (again several definitions), signature recognition or other biometric identifier
      Something the user has
      e.g.
  • Not all One-time Password tokens are created equal.

    Not even all OTP tokens from, say, RSA Security -- the vendor I know best -- are created equal.

    Specific mechanisms for "strong authentication" -- since the 1970s, by classical definition, an app which relies on at least two of the three factors (something known, something held, something one is) by which a computer can validate the identity of a pre-registered human user -- are designed for a particular threat environment.

    Typically, in a variety of f

  • We probably have what you are looking for. It's just released so there's an excellent reason why you couldn't find anything like it.

    Features:
    smart-card authentication for Active Directory clients.

    It's really easy to convert as few or as many clients/users as needed.

    Users can be enrolled and administered from any PC. (With proper authority and token)

    If you have HID prox cards for physical security, we can manufacture a combination prox/smart card. If you have an ID card system, you may be able to re-issue
  • Have a look at TriCipher: They let you use cookies, generic USB drives, or smart cards as 2 factor mechanisms. . . .
  • I work with a company called Entrust and we have a competitive product to RSA's SecurID that suits the criteria you've outlined above that you may be interested in looking into. Entrust IdentityGuard is a comprehensive strong authentication platform for Internet and enterprise applications. This suite of strong authentication capabilities enables your organization to take a risk-based approach to tailoring your security deployment. The flexible deployment options enable you to match strong authentication m

Those who can, do; those who can't, simulate.

Working...