Choosing the right authentication method for your business

Choosing the right authentication method for your business

Date: Dec 22, 2009

These days, there are so many different authentication options for so many varied devices that it's hard to know what to choose.

In this video, Mark Diodati of Burton Group explains what's new in the world of authentication and how to know what's right for your enterprise.

About the speaker:
Mark Diodati is a senior analyst for Burton Group's Identity and Privacy Strategies.

Read the full transcript from this video below:  

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

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.

Challenge No. two: 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.

So challenge No. three is universal device access, and what does that
really mean? 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 options that are available here.

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

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.

Moving on to our next section on authentication options. 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.

Moving to our next authentication option, 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 a
biometric 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.

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.

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.

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.

Eric Parizo: Mark, a question from the audience. Can OTPs prevent man-in-the-
middle effects?

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

More on Two-Factor and Multifactor Authentication Strategies

  • canderson

    John Pescatore: Evasion techniques aiding advanced targeted attacks

    VIDEO - Video: SANS Institute's John Pescatore says though new evasion techniques are aiding advanced targeted attacks, defense matters as much as response.
  • canderson

    Get up to speed on FIDO Alliance efforts to secure online authentication

    VIDEO - In this webcast, expert David Strom reviews what FIDO Alliance efforts mean for online authentication methods.
  • canderson

    PayPal CISO hopes FIDO Alliance can help replace weak passwords

    VIDEO - Video: PayPal CISO Michael Barrett discusses the FIDO Alliance launch and how the open standard for online authentication might help replace weak passwords.
  • soft token

    Definition - A soft token is a software-based security token that generates a single-use login PIN. Traditionally, a security token has been a hardware device that produces a new, secure and individual PIN for each use and displays it on a built-in LCD display. Soft tokens are an attempt to replicate the security advantages of multifactor authentication, while simplifying distribution and lowering costs.
  • FIDO (Fast Identity Online)

    Definition - FIDO (Fast ID Online) is an open standard for a secure and easy-to-use universal authentication interface created to address the lack of interoperability among strong authentication devices. The FIDO standard supports multifactor authentication and strong features like biometrics.
  • Multifactor authentication key to cloud security success

    News - Following the collapse of an AWS-based cloud hosting provider, experts say enterprises should prioritize use of multifactor authentication.

    ( Jul 08, 2014 )

  • multifactor authentication (MFA)

    Definition - Multifactor authentication (MFA) is a security system that requires more than one form of authentication to verify the legitimacy of a transaction. MFA combines two or more independent credentials: what the user knows (password), what the user has (security token) and what the user is (biometric verification).
  • SlickLogin acquisition: A game changer for Google and 2FA industry?

    Answer - Google's recent acquisition of two-factor authentication vendor StickLogin could push it ahead in the secure identity management industry.

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
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
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: