These days, there are so many different authentication methods for so many varied devices that it's hard to know what to choose. In this video, Mark Diodati of Burton Group explains three common authentication challenges, different types of authentication methods, the future of authentication solutions and recommendations for selecting the right authentication method for your enterprise.

Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact editor@searchsecurity.com.

Choosing the right authentication method for your business

Eric Parizo: Hello, and welcome to today's SearchSecurity.com webcast, “Choosing the Right Authentication Method for Your Business,” featuring guest speaker Mark Diodati of Burton Group. My name is Eric Parizo. It's great to have you with us. The world of enterprise authentication is changing and there's no going back to the ways of old. Today's businesses need authentication systems that support partners and contractors in addition to standard users, offer secure access to high-risk Internet applications, and are compatible of myriad of mobile devices. To that end, today's webcast will drill down into the authentication piece of the enterprise in 2010 and beyond. We'll evaluate the current crop of authentication technology. Our speaker today, Mark Diodati, has nearly 20 years experience in development and deployment of information security technology. He is a senior analyst for identity management and information security at Midvale, Utah-based research firm Burton Group. He is a noted industry expert and author. Thank you for joining us today, Mark.

Mark Diodati: Oh, my pleasure Eric, thanks for having me.

Eric Parizo: We will begin today's live webcast with Mark's presentation in just a moment. Slides will automatically be pushed to your screen. And it's my pleasure to present today's special guest speaker, Mark Diodati. Mark?

Mark Diodati: Thanks so much, Eric. Today, I'd like to talk about choosing the right authentication method for your business. As we go into the agenda, there are really three things that I want to start talking about. The first is talking about this new world of authentication that really has three principle challenges with it, that may have existed in the past but are definitely becoming more acute. Then I'd like to talk about some authentication options that might be able to help in this space. Let me just say from the outset, that this problem of the new world authentication and, we'll talk about all the different constraints and parameters of that. There is no one solution that will work, and there's also an immaturity of some products in this space. But to get to the recommendations a little bit, there will be opportunities for you as an organization to be able to choose successful things and to watch out for other things as well.

Let's take a look at the new world a little bit. What we're finding when we talk to our customers is that enterprise authentication technologies are really struggling to meet the needs of the business, in a cost-effective secure and usable manner. There are really three principle challenges that have existed in the past but are becoming more acute, and I'll go into some of these in-depth shortly. There are more user constituencies besides employees, for example. We're also exposing more high-security applications over the Internet. They could be patient records in a clinical scenario, in a health care scenario. It could be the exposure of our ERP applications. We're exposing more applications to more users outside the firewall. And finally, not only users, but lines of business are asking for universal device access and we'll talk about what that means as well.

Authentication challenge #1: External users

So the first challenge: more user constituencies. We all know that employees, partners and contractors are part of this equation. This isn't a surprise. What's happening is that partners and contractors are becoming a larger part of the equation; and they're asking for more and more employee- like access, and they're doing that because we're partnering so much more. We also have the impact of the emerging cloud in place here. So if you're a service provider or you're providing a service, by definition you've got external users coming into the system. The other attribute about these partners and contractors is that they're originating from non-managed work stations. You don't own those work stations, so some of the tricks you could pull in the past in terms of managing the security of that work station, being able to force a specific kind of authentication mechanism that might require software installation, for example, are gone. You can't do that anymore. You don't own those machines. And with these partners and contractors, we're finding that hardware-based authenticators like smart cards and particular hardware-based one-time password devices are a difficult sell to everybody, because of usability concerns, but also cost recovery concerns. So, in the good old days when you deployed hardware-based tokens, you were able to make sure that you got those back and could re-use them because you were dealing with your employees. Unlike smart cards or other devices, one-time password devices can be re-used. So, there's a cost recovery component that's introduced with these external users. And with respect to usability, we're also hearing that these employees, the other part of the equation, are demanding simple to use authentication types. As we go through some of the other challenges in this new world, you'll start to see that this plays out in a variety of different ways.

Authentication challenge #2: Increased exposure of high identity assurance applications over the Internet

We're exposing more of our core applications, like ERP, and lines of business units are demanding this. They're demanding that their internal users and their partners and contractors be able to access these things. Purchasing applications would be another example of this. And in the case of challenge No. two, the exposition of these applications, is almost always, but not absolutely, over a Web interface.

The customers really are asking for two different things when they say this, and they're two distinct things. The first is that they want access from unmanaged PCs or Macs, which is readily achievable today, but it limits your hardware-based authentication options. The other thing we're seeing in terms of universal device access being demanded by lines of business and users, is that access from Internet capable devices. So, the idea that we can access anything we want to from our mobile phone. For example an iPhone or a Blackberry or other such device. It's not typically possible, not because of authentication concerns, but because of the issue of modifying the application to interface. And so to make it usable, frequently things need to be done, for example, writing a skin for the application so that it can be exposed. Let's talk about some of the authentication methods that are available here.

Software-based OTP for mobile devices

The first one, and it's very promising, is a software-based one-time password module on a mobile device. It's been available for at least a decade. The earliest deployments, however, were unsuccessful, and this is in spite of the fact that there were some raving fans within the enterprise. Particularly technically savvy people that really like the ability of carrying, for example, their device on a Palm. Those have since changed. They were unsuccessful. The problem was that the scalable distribution of these things was difficult. So, when we talk about distribution, we're talking about things like distribution of the seed, which is the secret, the symmetric key that makes that stuff work. Also, the software. But we've seen some vendors improve in this space, in particular Verisign and RSA offering an ability for users to self-enroll an existing token perhaps that they downloaded from iTunes, for example. So, essentially a self-service is a requirement in this space.

One other issue that remains, though, is the token necklace, which is about this idea that if I'm going to multiple security domains, let's say I'm accessing an application at this organization site, and an application at that organization site, different places, OTP on a mobile device doesn't work. It mimics the characteristics of a hardware device in that, it's very difficult to be used out of two different places. Now the major OTP vendors have offered a shared service, but that certainly hasn't reached mainstream, so this remains a concern. Moving to the next slide continuing on this topic. The thing about the OTP on mobile devices it that it's convenient, which means that the user can carry device with the phone. It's in the phone, there's no need to carry an additional device, like a hardware-based OTP.

Another thing that organizations like about this capability is that the user bears the cost of the hardware. So if the user has the phone, there's no need for an upfront hardware cost for the hardware based one-time password device, provided you've got your identity proofing embedding strategies nailed down, this will work perfectly. As we mentioned before, there are some challenges with the deployment of the seeds and the software and that's improving over time. This is one of those areas that as we talk about in the recommendation section that we recommend you to continue to watch for in this space.

Authentication methods and hardware-based OTP devices

Moving to the next slide on authentication options and hardware based one- time password devices. It's been the go-to strong authentication device in the enterprise for at least 15 years, and there are a lot of reasons for its popularity. It's portable. It's easily carried, it can be put on people's key chains and so when they when they take their keys with them, they can carry this device. It's also clientless, which means it doesn't require any client software. It's ubiquitous, because it works with many applications. The OTP vendors have created agents for Web applications and other applications. And also, the software vendors themselves have integrated hardware-based OTP capability into these platforms. And there's also radius, which is an approach that many organizations have used for remote access, but provides some level of interoperability when it comes to hardware-based tokens.

And finally usability. The OTP model itself is very similar to a password. So, people are used to taking something they know, which is their ATM PIN, and then they type that in and then they type in the password that's displayed on the screen and they're on their way. Continuing on hardware OTPs, they may not be appropriate for new world authentication. The reason is this cost recovery issue and also some push back by partner and contractor constituencies, in particular partner constituencies, who may say "I'm not carrying that around to do business with you." And as we mentioned before with the software based OTP, the token necklace issue still remains because you can have some concerns with trying to use this single hardware device among many organizations. That said though, the hardware OTP definitely has its place in new world authentication with employee or similar constituencies and very high identity assurance applications, because the hardware based OTP isn't subject to man-in-the-middle attacks or seed distribution attacks. It's its own stable device. That's not to say that it's not subject to man-in-the-middle when it comes to generalized phishing attacks. But for high identity assurance applications with relatively sophisticated users, it makes a lot of sense. Also, for non-Web applications, so for example if you're doing some things with virtualization and desktop virtualization, then the OTP, hardware-based OTP can come in handy as well.

OTP via SMS

Moving on to our next section on authentication methods. So looking at OTP via SMS, it's a trend that began back in Europe in the late 1990s. I saw this and it was very popular. The nice thing about it is that there's no token necklace issue. So when I need a one-time password device, it's sent to me so I can contact as many organizations as I want and authenticate, and the SMS will deliver the OTP that's needed at that moment. We're aware of several large financial institutions which are now using it for identity proofing. And identity proofing are those things that you do during the authentication life cycle. To make sure that you're dealing with the user who is who they say they are, for example, account unlock or an establishment of a device identification, which we'll talk about. When we talk about identity proofing, we're not really talking about the main authentication mechanism that's in play. This is the stuff that you do to make sure that main authentication mechanism is working. The nice thing about SMS-based OTP is that if it works with hardware-based OTP, it will work with SMS-based OTP, because the back end infrastructure is exactly the same; the delivery of the SMS is a little different, but the use of it is exactly the same. And the same would be true for software-based OTPs as well on mobile devices. If it works with a hardware-based OTP, it will work with a software-based OTP.

Moving to our second slide talking about SMS, one of the things that you're going to start to hear us talk about right now with the rest of these authentication mechanisms, is this use of occasional access. When you use a password or a hardware-based OTP or an OTP that's generated on the phone, every time that you want to use an OTP, it's pretty easy to get it and use it pretty quickly. But when we start talking about things like SMS, where something is required for delivery, it gets to be much more of a challenge for your users who are starting to mimic employees. So, if you have users that are authenticating frequently, then OTP via SMS is going to become a usability drag because they have to wait for this thing to be delivered to them. And they may have to go to a website first in order to initiate the delivery of this. So, usability will definitely increase if the user is required to use it frequently, so we'll talk about some ways to make that better.

There's also some residual concerns about cellular coverage, particularly in building, so if I can't deliver the SMS, how valuable is it? And general cryptographic weakness of the SMS protocol. Again, when we talk about authenticators, there's not authentication method that's bullet proof, even from something like the gold standard of smart cards, working on down to basic passwords. Everything is subject to attack, and so this would be an attribute of those kinds of attacks for OTP via SMS.

Out of band telephone authentication

Moving to our next authentication method, which would be out of band telephone. So far, along with things like OTP via SMS and OTP on a mobile device, this is one of those I consider very promising. So, when the user attempts to authenticate to a website, the user is contacted at a phone number on record. It could be an office number or a home number or a mobile number. Now, the implication here is that you have a good enough relationship with that user that you know this information about them. So, this wouldn't be good for example, for financial institutions doing account origination, I wouldn't recommend using this approach. So anyway, they're contacted at this phone number, they pick up the phone, they press a few keys on the phone and that's it. They're authenticated. And from an integration perspective on the application side of the house, it's pretty trivial to implement this stuff. The two vendors that do this are Authentify and PhoneFactor, and the way that they do it is the application makes a simple SOAP call. They don't really need to understand the underpinnings of telephony or a plain old telephone that works or cellular networks. They're just making a call. In fact the out of band telephone people may not even know who that user is. They don't really care. All that they care is that they dial a phone number and they get some successful response and they send that back.

One of the things that's really nice about out of band telephone is that it takes a lot of the risk out the channel where the transaction is occurring. So, in this case we're talking about Web-based applications. If you can do an out of band telephone authentication, you get this nice effect where you take the risk out of the channel because you're going through a phone system to authenticate the user and that's pretty nice. Moving to authentication options out of band telephone continuing. Like I said, it's promising because of its excellent security characteristics, which I summarized, but also, it requires no hardware of software, so you have something that approaches what a hardware-based OTP looks like, but there are no requirements to manage work stations or install software at all or carry additional devices.

We talked before about SMS based OTPs. This occasional use case keeps coming up, which means if I'm an employee, this out of band telephone authentication mechanism is probably going to drive me crazy. Because if I have to do it every time I authenticate to a target system, it's going to be a drag from a usability perspective. Moving to keystroke dynamics, another particularly promising area of authentication. Typically it uses a Flash browser plug-in, and based on some of the estimates I've seen, Flash is more ubiquitous than Java on people's workstations anyway. So, this is nearly clientless and nearly ubiquitous. And if you've heard me speak before where I've talked about this technology, it measures the speed, how fast you type between keys, and it measures the dwell, how long you hold down keys. And the technology has been around for at least five years, but is has seen a resurgence recently. And it's because of a revenue enhancement, ironically. For example, if you're running a real estate listing site, if you're an investment site that sells information, you want to limit the amount of account sharing that's done because that represents additional users that you're not getting revenue for. This is in information-based style services. So, unlike other techniques including device identification, keystroke dynamics can prevent account sharing, even from the same computer. So if you think about a realtor's office where there are many realtors who want to access some information that is paid for via subscription, you could have multiple users coming from the same work station, and it would still look like one user even from a device identification perspective. But with the keystroke dynamics, you can actually distinguish the difference between users.

Moving towards device identification. Now we're starting to talk about some authentication techniques that enterprises really want to use when I talk to them. But they're not quite there yet for broad enterprise usage.Device identification is an example of that; it's part of the consumer authentication ecosystem; part of the snack of the consumer authentication suite. And it essentially does a pre-authentication by doing a device identification of the system. So it may look at all those things that it can look at publicly from a Web session and build a fingerprint for the system. It may subsequently store that fingerprint in a cookie, or it may put it in a Flash storage mechanism. The idea here is that we're trying to raise the identity assurance just a little by looking at where that user is coming from. If they're coming from a work station we've seen before, we can rely on the authentication a bit more. Like all authentication techniques, this one has some down sides, too. Because it's not cryptographically based, for example, we're not storing a certificate and private key on the user's client, so it is subject to some impersonation and we've seen some of these attacks. That said, I think it's a valuable tool still, because it provides some elevated identify assurance during the pre-authentication phase.

And as I said before, organizations are really into using this and they're trying to make it work, but the problem is it's only Web-based today and it doesn't work with Active Directory-based authentication. So I've heard several large financial institutions want to use this capability, but currently, it's just not available or mature enough to pull it off. Transactional analytics as an authentication option. Again, part of the consumer authentication system, and it analyzes user activity over time. So, for example, if I'm banking Monday through Friday during central time hours, then a large fund transfer on the weekend might be something that's flagged. And it could be flagged one of two ways. It could be flagged so that the fraud department can follow up on it after the transaction goes through. We're also seeing some forward-looking financial institutions begin to implement transactional analytics as an active kind of authentication, where if they see something they don't like, they're going to stop the transaction right then and there. And perhaps issue an out of band telephone call to further authenticate that user. And once that happens, the transaction can go through.

Now, the problem with all of this is that the technology first is like abiometric technology. It's measuring user behavior, and that's sort of becoming a biometric. So, it does require some care and feeding to limit the number of false rejects and false accepts. You don't want to lock users out unnecessarily and you don't want to let in unauthorized users. And you're always going to have some percentage of that, but you need to manage that and change the rule set to make that work. The other thing about transactional analytics is that the rules engine today is defaulted towards financial institutions transactions. That's what it's based on. That's where it is in its maturity in the life cycle of the product. We know that there are many organizations that want to use this for many more applications, health care, other kinds of financial services, purchase ordering, everything. The problem is that in theory, anyway, the rule set can be reprogrammed, but in practice it's too difficult to do. So, what I expect to see over time is that the consumer off-vendors are going to introduce transactional analytic engines that are focused on industry verticals. So we'll see that over time and that will improve this issue of being so tweaked towards financial institution transactions to be a value for other things.

Mobile PKI authentication

I feel compelled to talk about mobile PKI as an authentication option. It does come up occasionally and we all know the value of certificates and their ability to do digital signatures and authentication and do encryption in a scalable way. The problem though is that mobile PKI is generally unsuitable for new world authentication scenarios. Let me explain why a little bit. If you want to have PKI that's interoperable with the Microsoft Web stack be that Internet Explorer, to do mutually authenticated SSL which is what really people want to do. They want to authenticate the user in a standard space way that won't break their Web server. You need administrative privilege on the Windows client to install a mobile PKI client. Because of the installation of the cryptographic service provider, even in a post XP world in Vista and 7, there's still some privilege that's required to pull that off. And so this is a big problem is the user's work station is managed. So, if I work for a company and they own my work station, they've locked it down. The chances of me being able to install a cryptographic client and to do mobile-based PKI authentication is going to be pretty slim. I'm personally aware of several mobile PKI deployments that have been pulled back, because of that very issue. So mobile PKI may be a good play within the enterprise. Also, mobile PKI within the enterprise you might want to consider the use of the Microsoft profile provided you're running in a Windows 2003 server in XP environment and above and you've got good trust, you might be able to do mobile PKI without all of this stuff. But within the enterprise this stuff makes sense. Outside the enterprise, we just haven't seen it be a success factor.

What we've seen the mobile PKI vendors do is water down the solution a little bit to make it more useful where it doesn't require the installation of the software. You don't get that mutually authenticated SSL thing, but you do get some for example, better cookie security and so on. There are ways to use this technology in a different way, but you're not getting exactly what you think. It does provide value but not that standard space mutually authenticated SSL thing that we're all looking for.

Authentication method recommendations

I'd like to move to some recommendations right now. And of course I'll start with the assessed risk recommendation and it sounds like analyst's platitude I know, but it's something that absolutely essential. So, when you're looking at your applications, you need to match the authentication mechanism to the level of risk, user constituency and application protocol and cost. So you need to measure all of those things. And what you certainly don't want to do is build a $10,000 barn for a $5,000 horse. You don't want to build a security solution that is more expensive than the cost of FROG for example. Some other recommendations, watch for technological improvements. In this new world, things are going to be getting better, in particular transactional analytics. Expect, as we said, some industry-specific vertical solutions that will come out and help in that space. Also, with OTP's on a mobile device, the platform support is improving over time, and the distribution and binding mechanisms. Distribution being getting the OTP out to the user, binding being, being able to associate the OTP with the user in an application. Those are continually improving and they must improve and it's logical that they will continue to improve. It's such a valuable technology because again we all carry mobile devices now and so if we can do this in a secure way, this makes a lot of sense.

Moving on to our next slide on recommendations, layer for warmth. As we talked before, there's no single authentication mechanism that's bullet proof; they all have deficiencies. So, if you layer these technologies you get a higher level of identity assurance. We see this frequently as a best practice across many organizations. So for example, you may want to do an OTP-based SMS kind of thing when you set up a device identification. So it's an initial way to do some good identify proofing, that will enable you to be able to set up a good device identification moving forward. Another one would be the example I gave before which is in a case of using transactional analytics in an active modality, you may want to, as the user gets stocked, do an out of band telephone mechanism. That would enable you to validate that the transaction is authorized before they move forward. There's good cost reduction there because you don't have to have the fraud department follow up in a separate instance and chase the user down.

Finally, mix and match technologies. What we've seen for large enterprises is that there's no single one technology that will work, no primary mechanism that will work across the board. So expect to have multiple authentication mechanisms even to the same application based on your user constituencies. It's just going to be that way. It's going to be difficult to do that. So just have that expectation. Finally, our last slide on recommendations, look for easy integration points. So, one example might be radius aware applications. You can bolt a variety of different OTP technologies underneath that. So things like Web applications, VPM, they can leverage these authentication techniques without you having to go through an application development life cycle to make it work.

Another one would be key strokes dynamics authentication. Again that's typing stuff. What we've seen is that these applications integrate pretty well if your application for example, can consume a [SAML] insertion, or a Web-access management cookie. So for example, if you're running Siteminder or Tivoli Access Manager for e-business, these keystroke dynamics products will do the authentication for you and then they issue a cookie so that the user is properly authenticated, and you don't need to modify your Web access management application to make that work. Other things to take a look at are transitional analytics and device identification. These products in the consumer authentication suite are beginning to be integrated with Web-access management systems. So, one of the problems that you have if these things aren't integrated from WAM systems to transitional analytics, is that you have the problem with two police officers being out there, two authorizations police officers. So you need to have systems, transitional, analytic and Web access management systems, that are harmonized from an authorization perspective. With that I'd like to transition it back to Eric for some Q & A.

Q&A: Authentication methods

Eric Parizo : Mark, thank you so much. Great presentation. We'll start the Q&A. One of the biggest security problems facing industry today is Web applications that haven't been properly secured during development. Can adding authentications to those applications block the risk for this?

Mark Diodati: I think in some respects they can. What needs to be fixed, though, at a fundamental level is if the application isn't architected securely, then really you've got a foundation that's not sturdy at all. So, if you tried to put authentication on top of that, you're likely to run into some troubles, because you can't trust the fact that the authentication will be validated and accepted. So, I think these things go hand in hand. The presumption is that you've done some reasonable work on Web security of the application itself to make sure that it is properly developed. And if you're developing Web apps it's not uncommon, and it's quite frequent actually that you hire White Hat folks to test these kinds of things for you to make sure that there aren't any things like SQL injection attacks or other kinds of application specific security issues. Then you can layer the authentication. So once you layer the authentication on top of that you've got a higher level of identity assurance and it can mitigate the risks associated with online transactions.

Mark Diodati: Well, there's one specific area where OTPs are subject to man-in-the- middle and that's in a phishing attack. And so, for example, let's say you distributed, and this is certainly not true in America, but maybe true in Asia-Pac, particularly China. Let's say you distributed one-time passwords to your financial institution customers, your banking customers. If they're phished and they click on a URL that isn't accurate, they could be redirected to a proxy server that is a man-in-the-middle proxy server. And there are universal man-in-the-middle kits that do this for you and basically will suck the content and graphics from your own site and build a site that looks just like yours. And then they'll take that one-time password device and since it's valid for a minute or so, they'll use it right then and there. But those kinds of attacks are functional in the environment of broad consumer usage, so I'm not particularly concerned about that kind of attack when it comes to employees. The chances of employees getting phished to click on something like that and they recognize it doesn't look like their own site, I think is pretty small. It's really those public kinds of phishing attacks that are more of a concern.

Eric Parizo: Next question for you, Mark. How common is SAML (security assertion markup language) and do you see application vendors adopting it?

Mark Diodati: That's a great question. And SAML is security assertion markup language as you said Eric, it's a federation-based protocol that enables enterprise to enterprise single sign-on. So the ability to provide single sign on to, for example, your retirement planning site or your health care site, those are basic use cases for SAML. SAML is becoming mainstream. We're seeing it being used across the board. Now where the integration points reside are, you may have application servers that can consume SAML assertions natively. But in many cases what you have is that you've got a federation product out there, and its job is to consume the SAML assertion when it comes in, and then turn that into something else that the local applications can consume and understand. And the most common thing in here is when you come in and you authenticate via SAML, you'll get a Siteminder cookie or utility access manager, EB cookie, a WAM cookie. And that's where the integration point resides. That said some WAM systems can consume federation credentials natively. And another use case too might be the use of Microsoft-style federation. Where you'll come in and you accessing a Microsoft-specific style resource that requires service tickets. And then you would transition from the WS federation assertion to a local Windows identity. So there are very different ways to integrate that and there are helper products that enable that integration to other applications.

Eric Parizo: Mark, I wanted to talk for a minute about the device identification technology that you spoke about during the presentation. You mentioned that it's designed to kind of raise identity assurance just a little bit. But I'm curious if you can maybe give an example of a use scenario, because I'd imagine, and this may be a broad generalization, but to a certain extent it probably represents good enough multi-factor authentication. So what kind of scenarios are you hearing that companies want to use this?

Mark Diodati: I think that's a really great question, and the idea here is that most of us probably used device identification and not recognized it, because it's something that's set up with the banking community. And so, an example of that kind of assurance level coming up just a little bit would be I'm authenticating to my financial institution, and my primary mechanism for authentication is password. Before I get access to the website, the website does a device identification, and it says ‘I recognize this device’ and frequently other things are combined with this device identification, too. Like is this a known botnet site, is this coming from a blacklisted IP address, is this coming from a geo location perspective, is it coming from somewhere that I don't necessarily trust? All of those are fed into this device identification equation. So before I even get to authenticate, I need to make sure that I pass just this initial test. And so it can eliminate some of the white noise out there in terms of what's happening. That's the primary use case for device identification. Organizations internally want to use it for much more than that I think, that's a different use case.

Eric Parizo: And Mark you mentioned a lack of Active Directory support today is a big drawback. When do you see that coming up front?

Mark Diodati: I don't see that changing for a while. It's unfortunate. It's going to require if the consumer off-vendors or the off-vendors want to begin to provide that integration, it's going to be a long, long, steep hill to climb. And frankly, there may be an end scenario where this can't happen at all. I recall one OTP vendor's desire to do Windows-based authentication, and as you know Windows is so tightly coupled to Kerberos credentials and either a password or smart card with certificate. That's the only native mechanism that can work. So they spend a lot of time trying to build around that infrastructure. And in the end some of the functionality about network-based access could never be secured anyways because the product couldn't get enough information from Active Directory to adequately identify the work station. So, it's going to be a long time coming I think when we start to see that native Active Directory integration for device ID.

Eric Parizo: Mark, another question coming in regarding a specific authentication product from a well-known large database company. I know we won't put you in a position of talking about the pros and cons of specific products. But what's your boilerplate recommendation when it comes to thinking about vendors, specifically larger vendors vs. the smaller vendors out there?

Mark Diodati: That's an interesting question and I think one of the ways it can be answered is around OTP where you have choice: You have application ubiquity vs. cost. So, if your applications are primarily radius-based, or perhaps have a little bit of Web technology in play, you may be able to go to an OTP vendor that's much less in cost, because really the hardware device itself has really become a commodity. What isn't a commodity is the application ubiquity aspect. So, if you go to a larger vendor, you'll get a wider ecosystem of partners that support that product and can support many different platforms besides radius and a couple of Web apps. And so there's an example of where if you're looking for application ubiquity you're going to pay a bit more, but if you just kind of need a bare bones things, you can look more towards the other OTP vendors.

Eric Parizo: So as a rule of thumb perhaps, the broader and bigger your implementation plan, perhaps the broader and bigger vendors you should start your search with.

Mark Diodati: Yes, I think that's true. That's a good way to put it.

Eric Parizo: All right Mark, I think we'll wrap things up with just one more question for you. Our final question of the day. As you mentioned the hardware token continues to be kind of king of the authentication world despite its commoditization, if you will. Do you see any other method, software otherwise, significantly changing the landscape in the short term? I'm talking about big game-changers.

Mark Diodati: Sure. I don't really see a big game-changer. What I see continually bubbling up on the side and continuing to grow is the use of smart cards inside the enterprise. Now, for this new world authentication scenario where you really can't touch the user's workstation and hardware is kind of a no-no, then the smart card isn't really a good play there. But, internally the smart card makes a lot of sense, particularly because one, it's the only native strong authentication supported in Windows at the work station. There is no other. And if you're doing OTP at the workstation, you're doing biometrics at the workstation, you're playing hide the Active Directory password game and you're replaying it. So there's this nice synergy there. We're getting native Windows support plus the ability to securely store a private key associated with a certificate, means that you can do all kinds of PKI things like mutually authenticated SSL and so on, in a very high identity assurance and portable way because the credentials travel with you.

So, that's pretty interesting. And the other area where that fits nicely is around physical and logical convergence initiatives where you're going to use a smart card not only for things like access to applications, but also access to the building. So this smart card can become a Swiss army knife that lets you into both of those kinds of applications. So it's continuing to grow. I think with the economic downturn in late 2008 and 2009, there were a lot of smart card projects that were put on hold but I'm expecting to see those increase and continue.

Eric Parizo: Mark, we have one more question, are you game?

Mark Diodati: Absolutely.

Eric Parizo: All right. Here we go. Are there any integration to public authentication infrastructure, aka Open ID, that cross over into the enterprise for global business?

Mark Diodati: Boy, Open ID is just a real controversial topic within the security community on just the security aspects of it. So, when we talk to enterprises, with some notable exceptions, they're not really interested in using Open ID. I did speak to a power company recently that's interested in Open ID because they've got three million subscribers and they want to enable them to come in a look at energy usage and so on. That's kind of a low-risk style application, so I think Open ID may make sense there. But you're not seeing Open ID specifically or information cards generally becoming something that's becoming a bigger enterprise play. It's just not happening.

Eric Parizo: All right. Very good. And with that our thanks once again to Mark Diodati of the Burton Group for joining us today. And for more information you can read Mark's exclusive tip on privileged account management implementation. There's a link on your screen. Also, be sure to check out Information Security magazine 2009 Reader's Choice award which has your choices for the year's top products, including enterprise authentication. You can find that by going to SearchSecurity.com and clicking on the ISM icon on the right side of the home page. And thanks to all of our listeners for joining us on this SearchSecurity.com webcast. I'm Eric Parizo. Stay safe out there.

About the Speaker

Mark Diodati is currently the Conference Chair, Cloud Identity Summit and Technical Director, Office of the CTO, for Ping Identity.

1 comment

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy