What do YOU need out of two-factor authentication?

Two-factor authentication continues to grow in popularity and emerge as a security requirement for many people I meet with. At Microsoft, we use smartcards internally for VPN access right now; soon we'll be requiring smartcards for domain logon, too.

We are also looking at ways to require two-factor authentication for web-based services, like Outlook Web Access, published SharePoint servers, and other bits in our extranet. I love smartcards, and it's Microsoft's preferred product direction and corporate IT approach. But here we encounter a problem with them: most public workstations (kiosks, Internet cafes) don't have smartcard readers. So how do we require two-factor authentication when the infrastructure can't support it?

Ideally, my answer would be: too bad. Public workstations are too great a risk. No self-respecting organization would ever allow access to corporate resources from unknown machines, right? What possible business justification would ever permit exposure to such risk?

A lot, it turns out. Any organization (Microsoft included) that permits access to corporate resources, like OWA, is making a risk statement, whether they know it or not. That statement is this: "Our business activities require access to certain resources from any device, anywhere, at any time. We accept the risks associated with this because the value to the business is determined to be higher."

But just like us, many organizations are starting to become wary of these risks. Two-factor authentication can help to mitigate some, but not all, of them. The choice, then, is which kind of two-factor authentication to use? If smartcards won't work because readers aren't yet ubiquitous (they will someday -- remember, once upon a time a mouse was a rarity), what's left to choose? (I wish we'd include smartcard readers in every box of Windows we ship, just like we included mice in Office.)

Some form of token card with a one-time password is generally the option, with RSA SecurID being the most popular. Lately I've been reading about VeriSign's Unified Authentication product -- a number of you have mentioned your success with it, and you like that it integrates natively into Active Directly without requiring a separate authentication infrastructure (unlike SecurID, which requires an ACE/Server). I would like to play with this myself someday (hint hint).

I want to hear from you, though. What do you need from a two-factor authentication mechanism? What are your requirements? Have you used the products currently on the market? What do you like or not like? What do you want to see done differently? Would you like for Microsoft to develop something, or do you prefer to rely on partners?

Tell me what you think. Our IT department is engaged in a lot of research here; I'd like to know what you've learned in your research and through your experience, too. Post a comment here or email me if you'd prefer to remain private. Either way, I'd really like to get a good body of customer thinking on this. Thanks!

Comments (41)
  1. Anonymous says:

    Steve Riley sent me an email message about a post on his blog.  He needs feedback from all of you…

  2. Anonymous says:

    Steve Riley is trying to get a good body of customer experience with various forms of two-factor authentication. …

  3. Anonymous says:

    Steve Riley always makes me think, sometimes so much that it hurts.  Thanks, Steve.  His latest…

  4. Anonymous says:

    Andy made an interesting comment regarding his interest in Trusted Platform Module (TPM) hardware…

  5. Anonymous says:

    Steve Riley asked me to post this little plea. Turns out he wants to know what *YOU* want from two-factor…

  6. Anonymous says:

    I’m a big fan of Vista. I see a lot of potential in the new features and function as it relates to security. I love UAC, even though it has a ways to go with its popup dialogs that are annoying many a beta tester. But this post isn’t about talking about

  7. Dan Halford says:

    During one of your talks last year at TechNet New Zealand, you questioned why a particular form of two-factor authentication wasn’t utilised by more online banking services. The problems with two-factor authentication is that very few form of tokens / smart-cards etc are ubiquitous. Well, one type of token is: the mobile / cellular phone.

    Everyone has one. They’re all interoperable (SMS). My online banking service uses SMS-based two-factor authentication for certain types of transaction over a certain dollar amount. After selecting the amount and payee, I re-enter my password, and then type in the 8 digit code that gets sent to my phone.

    Now obviously there is a per-transaction cost to this, but one would have to make a lot of transactions to even come near to the cost of the tokens, server, maintenance, card-readers etc. No doubt, should the product be marketed properly, it could even be resold through telcos who could offer some form of guaranteed SMS QoS as an advantage.

    The system my bank introduced is simple enough that they’ve now made it compulsory. If my 80 year-old aunt can manage it, it should be simple enough even for staff in HR or marketing too.

  8. Phil Jackson says:

    We have recently implemented RSA logon for domain authentication.     All I can say is wow what a pain.  I’m all for two factor authentication but MS and RSA need to work together better.   For example we use ISA server and could never get the combination of ISA, RSA and OWA to work and play together.   Another issue we have run into is many people use the Exchange published through ISA so that they can use the outlook client.  Again this is a problem that requires a lot of workarounds.  

    Finally user acceptance is really low and people go and run to their boss and just ask why they can’t use their old password.  (mainly because I could guess about 90% of them).   So over and over you have to sell it.   Fortunately for me one of our partners “gets it” and is a big believer in the technology so I have executive buy in.  Without that I’m afraid this project would have been canned for political reasons.    We are a small company I can’t imagine what it would be like for a large enterprise.   I think two factor is where all companies need to go.  Long pass phrases still don’t deal with things like keyboard logging but one time passwords do.   The other reason we choose OTP is that we use a lot of terminal service and thin clients that wouldn’t have worked with smartcard readers, or at least not without a lot of effort.  

    As it related to the Verisign product, we did look into it and there were two reasons we went with RSA.   My understanding is Verisign is tokens are event driven, you press a button, so in theory people could just write down a bunch of numbers on a sheet of paper.  Second the product isn’t as mature and after all the challenges with RSA I’m not sure a newer product would have the vendor support.   But I could be wrong on both accounts since we don’t use the product

    Bottom line these products need more support from all kinds of vendors, becuase two factor is still "out of the box" for most.

  9. n0one says:

    I’m sure RSA (along with all of us trying to use it) will be delighted to know how Microsoft was able to implement it for owa, sharepoint, and rpc exchange. If that day ever comes, it will make my life easier.

  10. steriley says:

    n0one, thing is, we DON’T yet have two-factor authentication for web-based resources. Our IT department is evaluating a number of alternatives now.

  11. Rodney Buike says:

    I agree with the idea Keith Combs posted on his blog to use a USB stick.  What I would like to know is peoples thoughts on encrypting and copy protecting the certs on the USB key.  Otherwise what is to stop a malicious user from copying the contents to another USB key and accessing data they normally wouldn’t/shouldn’t have access too?

  12. castrunk says:

    Okay…strictly my opinion here, but if the company – not IT – has determined that the information accessed at said website is valuable enough to require 2-factor authentication, then public kiosks are out of the question.  Even if the kiosk has a smartcard reader, there’s no guarantee that there isn’t a keylogger or some other nefarious device that isn’t recording your session.  Something as simple as checking e-mail could reveal valuable company information.  It would be like locking the front gate with an excellent lock when the fence is only waist-high!

  13. Keith Combs says:

    FYI, I received a few comments on my blog post at http://blogs.technet.com/keithcombs/archive/2006/04/21/425934.aspx.  I tried to get them to comment here but obviously wasn’t as effective as I wanted to be.

  14. Roger says:

    At my company we use SecurID for remote access through VPN, and to access OWA through ISA.  We’ve used RSA SecurID for over 10 years so its well engrained with the users.  I would really like to use RPC over HTTPS but I haven’t seen any indication this is supported. (although I last asked my TAM about it when it first came out).

    I’ve had MS professional services types tell me username and password is good enough for microsoft so I shouldn’t require securID for remote rpc over https through isa.  :rolleyes:

    I had expected that if we do implement smartcards that I’d be able to use that with sharepoint and with pretty much any IIS based system like OWA, I’m a bit surprised to find that may not be the case.

  15. Keith Pawson says:

    We use tokens with the Citrx Access Gateway which caters exactly for this problem and does it very well. You can use this device with Advanced Access Control so it can tell what device is connecting to the corporate network and based on this provide different levels of access from read only to full editing and accessing mapped drives.

    See more here:



  16. mkaess says:

    I took over in my current position, as IT Manager, nearly 3 months ago and (while I love the idea of two-factor authentication) it is the LEAST of my concerns. If you do not have security configured once you are authenticated – how hard it is to get there is of little consequence.

    One other thing to consider is your risk factor. Our organisation is not the NSA so I do not have a huge potential for disaster vs. the complexity of implmenting additional authentication methods. I cannot justify the expense and would find it difficult to get buy-in from management.

    My concerns are much more fundamental.

    My predecessor was using the domain admin password for nearly everything. There were three others who were in the domain admins group besides himself (one was the finance manager). Most of the servers were left logged in and not set to password or screen lock so ANYONE could just walk up and have a ball! Weekend cashiers were responsible for changing backup tapes ‘layer zero’ wasn’t secure at all.

    We all need to remember what Steve has taught in some of his TechEd presentations. Without the basics of security at these levels – two-factor authentication is merely security theatre (love that term)…

    Needless to say, I am not Mr. Popularity with some at the moment. 🙂

  17. Arne Lovius says:

    What I need out of two factor authentication is

    1/ Reliable and Secure

    2/ Cheap to implement

    3/ Simple to integrate

  18. mkaess says:

    There is one immutable law that you need to consider in this equation – One can have two of the three (Secure, Cheap or Simple) but not all three.

    Secure and Cheap – but it’s not simple.

    Cheap and Simple – but it’s not Secure.

    Simple and Secure – but it’s NEVER cheap.

  19. Stefaan Pouseele says:

    We use Smartcards for VPN access. That works great because VPN access is only allowed from corporate managed devices (read domain members). However, I would like to see better Smartcard support (or maybe the Belgium ID card instead) for authentication with delegation on the ISA server for web based services such as OWA, RPC over HTTPS (why has MS not implemented this?), Sharepoint, etc..  

    Take note that if smartcard readers would be installed everywhere than make sure you use those with a buildin keypad so we can securely input our pin  😉

    If other two-factor authentication devices should be used because of they portability, than make sure the generated pin is not an add-on on the existing ‘id’ and ‘password’, but rather a replacement of the existing ‘password’. The reason for it is that otherwise the domain credential are already entered and that is very bad, especially on a non-managed device.

  20. n0one says:

    I understood your situation Steve, your IT department just has a long road ahead.

  21. Gary says:

    A USB key that:

    1) Has a time based OTP ala secureID in a window so it can be used on machines where a USB port is unavailable.

    2) Fingerprint access control to the key contents if not using the time based OTP.

    3) Support for management of PKI material

    4) OATH compatible:


    Cheap, easy to use, and reliable. 🙂

  22. anonymous coward says:

    Poor reliability, ease-of-use, provisioning and application support are the biggest barriers to two-factor.  


    1) Make a device that is hard to lose/break. When the devices are lost/broken, fixed passwords are issued and getting back onto two-factor requires communication and coordination.  

    2) Solve the RFID reader problem so that the devices can be used for physical security.  

    3) Allow flexibility in the systems so that the hardware can be used without the PIN.  End-users don’t like to type in passwords and/or PINs.  They write their PIN on a sticky and attach it to the device anyway.  Leverage the intelligence of the device to automate sign-on.  Make it easy to authenticate from a friend’s machine or a home PC without typing a bunch of passwords.  Ease-of use in exchange for requiring two-factor is easier to sell.  

    4)Improve feedback and error handling.  User error vs. broken authentication systems is hard to diagnose.  

    5) Solve the provisioning/enrollment problem.  Handing out,  tracking and revoking OTP two factor is a labor-intestive process.  

    6) Make it easy for developers to front-end existing systems with smart card authentication to enable single sign-on.  

    Finally, remember that the main benefit of two-factor is the physical token, which mitigates action-at-a-distance attacks and account sharing.  Allow the organization implementing the system to make trade-offs like no PIN and authentication from non-secured resources.

  23. Ian Watkins says:

    Working in the SME space, it needs to be cheap, work OOTB and be integrated with SBS. It needs to be available in quantities that small businesses will need and it cannot have a massive infrastructure requirement. Additional units need to be easy to obtain (and not in units of 25) and on-going licence costs can’t be set ludicrously high.

    It’s hard work making money in the SME space. The purchaser is usually spending his or her money 🙂

  24. Paul Young :) says:

    Assuming there are no code vulnerabilites – the password is the only opening, and the largest weakpoint. 2 factor is obvious. I have run RSA and like it – although it can be rough. The reason primarily the guys above are having problems is the INTERFACES are not nativelyt supporting additional authentication mechanisms. Sure, one or 2 do, but there is no way to force 2 factor on LDAP or SMB. This means the 3rd party vendor then has to jury rig the implementation. Even if it is supported, it is only on less than 20% of interfaces – making the rest need to be firewalled off – a perimeter solution only. Until the vendors (starting with MS) put the equivalent of EAP on EVERY interface – it’s a pipe dream. I doubt MS will ever do that – it opens up the thought that you may use another directory – and the empire is built on authentication.

  25. Mylo says:

    Inter-vendor integration and compliance. Integration is a big barrier to successfully implementing two-factor auth in the enterprise space… in the present climate the likes of Microsoft, RSA, Citrix, Cisco etc often use proprietary, decoupled technology, making  two-factor auth both for internal and external customers (using a combination of vendors) extremely difficult at best.

  26. Winston Liu says:

    Face Recognition Detection Devices

    use infrared to help identify people like

    look-alike twins by measuring features not

    discernable to the naked eye, example:

    distance between pupils, distance from

    the forehead to the chin, etc.

  27. bill says:

    Passwords may have been the best solution 50 years ago when we didn’t have networks and key loggers. I think now we have to look at alternatives such as two factor authentication and one time passwords.

    We use RSA SecurID for VPN access. I would like to go further and use it for authentication on all our systems.

    My main requirement is that it should integrate with our core systems: Windows, SQL Server, Oracle eBusiness Suite, Lotus Domino/Notes, Linux, ISA Server.

    The biggest barrier to its use is cost. These devices are way too expensive. I imagine the tokens are cheap to make. Why does it cost so much to use them? We can’t justify the cost of deploying it to every user in our company. I have a friend with a small business who is about to install SBS. They have almost 20 people and need remote access. Such devices would be great for them, but the cost is far too high.

    The other potential obstacle to wide spread use is that I could end up with any number of them. I already have accounts with two banks, a share trader and an online auction site. If each of these provided two-factor authentication then I’ll end with too many tokens to carry around. So, I think long term we need interoperable standards so that I can have one device that works with everyone.

    I have a problem with USB based devices. USB ports aren’t always available – some laptops only have one port which might have a mouse plugged in. Other times they can be hard to get at – the back of a PC under a desk. Imagine trying to scramble around to the back of a PC at an Internet cafe!

  28. B says:

    I’m working on externalising an application for a large company (I guess up to 50,000 potential users). The application itself may not store sensitive data, but we have to mitigate risks if the system is accessible from the internet.

    Two factor authentication is favoured within the IT groups, but gets push back from the business side for the following reasons:

    * Exorbitant costs for the tokens and supporting software, and resultant vendor lock-in. These are only available from select vendors and require vendor integration software. Windows needs to natively support this hardware, make it a commodity – remove the vendor costs.

    * Since these solutions are an infrastructure add-on, there is little skill in-house to implement this. Finding people who know what they are talking about is difficult and costly. Again, native support for this stuff would mean that finding skilled people would be easier (eg. I could learn/experiment on my own).

    * Provisioning tokens is a nightmare. Businesses need to be responsive, and quite rightly go over the heads of IT. IT should be implemented as transparently as possible. If you give partners access to an extranet, you increase this even more as you have to support a user per token system, or do you share a token with all users at a vendor site? It becomes very simple for a business user to request a token for a user and then share it with anyone if you can’t provision a lot of tokens very easily.

    * There are few, trusted examples of successful two factor authentication out there which people can point to (apart from vendor examples).

  29. Joe Elway says:

    If I was to recommend 2 factor authentication then here’s what I’d want:

    A mangement interface that is easy to use.  Cert Management is a dog if there are thousands of certs.  Try giving that to the typical sys admin and telling them to use the filter mechanism.

    The architecture should be easy to deploy and manage.  We got way too much complexity on our networks as is.  Complexity makes for human error and more help desk calls and down time.

    The token should be easy to create, deploy to users, cancel and replace.  Ideally, User and Computer cert management should be completely configurable through GPO and managed through AD U&C via delegated rights… see Exchange.

  30. Tim Alsop says:

    If I was to compare two-factor devices like smart cards with tokens, then my first observation is that tokens do not require insertion into a reader attached to the computer (like a smart card does). I would therefore prefer tokens for this reason alone. Let me explain why … The smart card can be easily left inserted in the reader, and then the advantages of two-factor authentication are mostly lost because the owner can easily leave the card in the reader, and then just enter their PIN instead of their password when prompted. I have seen many companies who use smart cards, and you can walk around their offices, or look at the laptops of employees and the cards stay inserted in to the smart card reader all the time ! if this is the case the smart card might just as well be part of the PC, and then it has no two-factor authentication advantages, and only serves as a secure certificate storage device – maybe companies are using smart cards as a certificate storage device, and they consider this to be more important than strong two-factor authentication ?

    So, what is wrong with tokens ? A token (e.g. RSA SecurID) is fine, but needs to be integrated into operating system authentication and applications cleanly, and consistently – to make it easy for customers to deploy and manage, as well easy for the users to use when needing to authenticate to the o/s or an application.

    The subject of Single SignOn (or Secure SSO) is worth mentioning, because a user will not want to keep taking their token out of their pocket and reading the pashphrase if they have to keep authenticating, whereas a password is easier for them to use when it is something easy to type many times. If SSO is deployed, then the need for multiple authentications is reduced, and the pain is less. Obviously, security needs to be considered because making life easier for users can make the authentication less secure.

    In an ideal world I beleive that proximity based two-factor or perhaps biometric devices will be preferred. For a proximity device, the device could be kept your pocket, on a wrist band, or attached some other way to your person so you are always with it… Then, when you are physically near a computer, and being asked to authenticate the fact your physical token can be seen near the computer within a specific range (first factor) and you enter a correct passphrase (second factor) you should be authentiated. This type of solution can also be setup so that when you move away from the computer your screen saver is triggered so nobody can access your desktop shortcuts or any applications where you are already logged on whilst you are in a meeting, or getting a coffee. With the increasing use of bluetooth I think this type of product should be more commonly used in large and small enterprises. I hope you can see that this approach has some usability advantages from users point of view because they just sit next to their computer and login using just a password/passphrase. The account name could even be obtained from the token device via bluetooth if configured this way.

    I hope this helps ?

  31. Marc Brawner says:

    Funny you ask – I’m presently weighing the pros/cons of the various technologies in this area for my company, and have spent the last several months demoing the various forms commonly available — Securid/Smartcard/USB/Hybrid etc.

    I’ve shown these devices to a number of users and executives, and to date unanimously they like the smartcard form factor. Why? When you explain that this can be integrated into their existing ID Badge/Proximity card (that many companies use today) that they are already used to carrying, there’s nothing new to keep up with.  Plus — a big plus — if the cards are also used to get in the building, then users will get used to taking them along when they get up to go to lunch or the bathroom, so they are less likely to be left in the reader (Although I’d rather have users leave them in their PC/reader all the time than rely on passwords alone!).  

    Even explaining the add’l costs of readers, they prefer the cards.  Mention that vendors like Dell already include readers built-in to their laptops and keyboards and the vision starts to make sense. Further, inserting card and typing a short pin is easier for most typists than having to read/retype a username+pin+code on a device, etc. So in practice we’ve arguably simplified their sign-on experience–even over a single factor username and strong password alone.

    The hybrid tokens at first glance seem nice, but you don’t get the ID card/building integration, and they don’t work well for road warriors– e.g. on a plane — sticking out from your laptop, likely to get smashed and break the usb port.

    I’m excited that Microsoft appears to be pushing the smartcard technology — the forthcoming CLM software will certainly make deployment of this technology much easier than it is today for most companies. And this software should come free with the enterprise versions of Windows. Make it widely accessible.

    So, what’s left to make this a reality for the average business?  I think the public terminal/kiosk issue will resolve itself if we can get better standards and built-in support. Progress seems to be coming in this area.

    1) Plug and Play – not a big deal for corporate managed computers, but if the business says a user can use their home computer, they should be able to take a card and usb reader home, plug it in and use their smartcard immediately without having to install drivers/middleware for these things.  Reduces support costs.  

    2)Much improved web app integration. OWA is indeed a big issue for us here. I want users to not have a domain password — and for us OWA support is the big stumbling block to achieving this. In IIS, why can’t I click "smartcard authentication" just like I do "integrated windows" and have IIS automatically map user certs to those stored in my AD forest? Right now it requires a complex series of steps that are beyond the patience of most admins. Reduce administrative burden.

    3) PIN Management – native windows gina that supports password changes should support pin changes, etc. for standard cards just like it does password changes.

    There are some companies that offer devices whereby you insert your smartcard into a standalone device and it generates a OTP. Better availability of this technology could provide a bridge for webapp/mobile support.

    Thanks for asking!

  32. Andrew van der Stock says:

    What I would like is two different modes:

    a) authentication.

    b) transaction signing.

    SMS two-factor works for both models quite well and is reasonably cheap (about $0.10 per auth).

    I do not want a device which is connected to a computer as this leads to "please insert token now" attacks, like MacOS X does when an app (which app? for what reason?) wants root. This also incurs a support cost which is non-trivial if things go wrong.

    Lastly, I want it integrated with AD. Not another directory anywhere. No synchronization at all. If it requires another directory or a specialist driver loaded on each and every PC, it’s very very very unlikely to gain any traction.


  33. Michael Breither says:

    We are serving a lot of enterprise customers in Germany and almost all of them have the need of improve authentication security. Smartcards would be the best choice but lack of hardware support (like of OWA kisok PCs) and organizational issues. Most of our customers have or evauluate OTP solutions, not only from RSA but also from Aladdin, where a hybrid solution (smartcard and OTP) is provided.

    What we definitely need is a broader and deeper support for OTP solutions in order to get rid of week password. That should include OWA logon, support for Windows Mobile / ActivSync and Outlook RPC-over-https.

  34. Ken Weingard says:

    Although there are many 2-factor options to consider for field staff on laptops thru our SSL/VPN, if we ever plan to implement 2-factor authentication for all users at office locations, I would need an easy way to do this for thin-client PCs that do not have an OS built in. (i.e. we use the Wyse blazer 1200LE device; these boot up in 3 seconds to the Terminal Server login screen).  Not sure what we could use for these?

  35. Renato Pessanha says:

    I have an interesting experience with two-factor authentication that most banks in Brazil are using for Internet access. It’s based on a printed card with a sequence of 40 numbers and each number is associated to a 4 digits code (numbers) randomly chosen. Something like 01-6453, 02-3671… The card has a serial number to easily revoke or activate.

    So, to grant access to home bank or specific operations on it, you have to supply your password and one of the code that will be randomly asked. It’s meant to combine both something you know (your password) and something you have (the printed card).

    It’s cheap and simple, some sort of primitive secureID. Aware users will transit from this model to more enhanced one easily, because they’ll be used to care about their printed card more than they’d need to do if it were smartcard.

  36. Hilton Travis says:

    RWW support.  The issue right now is that if you employ 2FA in an SBS environment, remote Exchange access and – more importantly – Remote Web Workplace do not support this.

    Also, support on thin clients would be handy.  I know that there are some 2FA methods that work on thin clients, but this is a major consideration for us and some of our clients.

  37. Hilton Travis says:

    Out of interest, if anyone hasn’t had a look at the http://www.cryptocard.com/ offerings, I suggest they have a look.  They offer SMB-sized packages at SMB-sized prices and scale easily to enterprise levels.

    They have a multitude of 2FA formats that they support, including a "software 2FA" for thin clients.

    Well worth further investigation, methinks.

  38. Ben Coman says:

    1. It needs to be reliable:

     1.1. It needs to not-fail because of inaccessible USB port / smartcard reader.

     1.2. It needs to not-fail because you are out of mobile phone range

    2. It needs to be easy to use, or there will be resistance from executives

    3. It needs to be cheap, or there will be resistance from accounting

    4. It needs to not-be small additional size to what already goes in my pocket.

    5. It should be an open standard, to encourag multi vendor interoperation, so that I don’t need 3 or 4 devices for different places.

    Smartcards are difficult to use in places you visit once.  USB ports and readers are not always available eg boxen locked in desk.

    SecureID is probably the most reliable – all you need is a keyboard. However the cost can be high, and for several sites you need several tokens.

    Mobile Phone SMS OTP is easy to use, cheap to set up, but has onging costs and not all locations have reliable mobile phone coverage (ie overseas)

    Keeping on the idea of using an existing mobile phone – which almost everyone has, and which certainly helps keep down the number of tokens    – the thing that would satisfy all the above requirements would be a OTP application running on a mobile phone.

    I’ve recently discovered such an application at http://hauskeys.safehaus.org/.  I got as far as  testing out the client in a J2ME emulator, as I’ve described here ( http://hauskeys.safehaus.org/Java+Wireless+Toolkit)

    and any system integrating it would be the coolest thing – such as Portwise.  It is opensource, under the Apache License 2.0, which eases its integration into proprietry products.

  39. Alton Naur says:

    non-contact RF PK + biometric.  I’ve seen too many people, including security staff who should know better, carrying around notebook PCs with smartcards or USB keys permanently left installed.  Some people even cut the end off the smartcard so that it doesn’t stick out of the reader.

    It needs to be PKI based so that there are no aggregated keystores or password stores that represent humongous risks if they are compromised.

    It needs to be RF-based so that people never need to take it out of their pocket for it to work.  If they have to insert something somewhere, they’ll forget to remove it or even intentionally leave it when they walk away if they intend to come back soon.  Considering a mobile phone as an "RF device" is a stretch, but it might work.

    It needs to have a biometric component since too many people can’t even remember their own names.  The biometric needs to be at least FIPS 140-2 certified to 1 false accept per 1,000,000, and normalized against a worldwide population sample, so that it is reliable when used by multinational companies for their entire employee bases, not just the US subgroups.

  40. Rex Young says:

    VeriSign’s line of next-generation tokens allows users to carry digital certificates and utilize OTP wherever they go and has encrypted storage. One-time password. VeriSign’s (OTP) is a number generated by pressing the button on the token. It is used to authenticate the tokens owner to

    the network or application. When generated, the OTP is shown briefly on the tokens display screen. The token generates the OTP in a way that cannot be duplicated by any other token device, and can only be used once.

  41. Carlo Kuip says:

    As for 2factor ID we use an access token from vasco for internet banking(http://www.vasco.com/products/product.html?product=59). This provides a powerfull and pretty convenient way to do banking, We have multiple smartcards registered against the device so me and my partner can share the device but act as diffrent persons for the bank accounts/transactions.

    What would be "cool" is to be able to peer this device, similar to the blue-tooth device peering, with a chosen web application. Then I would be able to reuse the infrastructure provided to establish my identity with diffrent parties. However I don’t think this is impossible because my bank (who provided the token) will most likely oppose to provide Identity management infrastructure to other parties without proper compensation.



Comments are closed.

Skip to main content