In Identity X-File 0x01, Pam writes about a story in the UK where a 6 year old was able to bring in and install a hardware key logger on an MP's computer in the House of Commons (it was part of a BBC experiment).
I assume a physical keyboard logger like this could still be used to steal an IdP username & password, even with all the secure desktop stuff that the CardSpace client has built in…
Essentially what a key logger does is use a Man-In-The-Middle attack to capture all input to programs and applications (including login screens) on a computer. The captured data is then analyzed to pull out useful information such as login credentials, credit card numbers, and other such valuable information.
If the primary concern is login credentials, the "easy" answer is to move to some form of strong authentication that requires hardware assistance (such as a smart card or biometric reader). These usually have communications protections in them to protect against MITM attacks. This isn't so easy to implement across a number of vendors (especially if you try to do it without identity federation networks such as those discussed by the Liberty Alliance's ID-FF and OASIS's SAML 2.0) and, even if you were to do so, the non-credential data entered by the user would still be subject to loss (such as the content of all typed emails, documents, etc.).
I did stumble across one amusing way around loggers (but, IMHO, opens all kinds of other problems) which uses a screen based keyboard to enter your data by clicking on buttons -- theoretically this is less likely to be picked up by loggers. The problems with this model include:
- While you click on the keys, your credentials are displayed plain-text on the screen so anyone looking over your shoulder would get them.
- You are trusting that the party that manages that page is not going to add anything to that page to log your entries (and without looking at the code, there's no easy way to do so).
- The site is unencrypted, so anyone looking at your network traffic can get the data
- The way that you then copy the data to the appropriate application is via the Operating System's copy/paste routines, something that is frequently available to any application and so subject to attack.
I wouldn't recommend using such a solution. Just too many weaknesses for me.
The ultimate answer for key loggers is a Trusted Path (sometimes called "Secure Path"). The trusted path ensures that the user is talking to the application that they think they are talking to (i.e. that there's no MITM listening in). Microsoft talked about doing this in their Next Generation Secure Computing Base (NGSCB) (code-named Palladium), which, at one point was to be part of Vista. However, only a limited set of the NGSCB functionality made it into Vista - the BitLocker drive encryption component.
This problem isn't small and isn't easy to solve, especially when you consider the need for being able to replace keyboards (because they broke, because you want to try a more ergonomic version, etc.). If you make replacement easy, you make MITM easy. If you protect against MITM, you end up making it hard for your users to easily work with their systems (increasing IT maintenance cost).
Tags : key logger / Microsoft / Palladium / Vista / Trusted Path / Secure Path / MITM / NGSCB / SAML / Liberty / Liberty Alliance / ID-FF
8 comments:
CardSpace doesn't use username and passwords, rather the user selects a card image which is used to retrieve claims-based security tokens. There's little to no typing going on in the identity selector. Do you see CardSpace being compromised by a physical keylogger?
Stuart Celarier
CardSpace, like any other identity system, has to do something to validate that the user is who they claim to be. Either a) just accepting the OS identity verification or b) prompting for credentials that are forwarded to the identity source behind the card.
In either case, the authentication of the user is susceptible to key loggers if they are using keyboard entry of data such as a username and password.
It certainly is an excellent question, but CardSpace itself never prompts for credentials. Just to be clear, CardSpace implements a public key infrastructure (PKI) to secure communication with an asymmetric public-private key pair. It does not exchange so-called "shared secrets" like username-password.
An identity provider *can* choose to require that an information card that refers to its STS have the card protected with an additional factor (e.g., smart card, biometric data, or typing in a PIN or time-based token). To accomplish this, as part of installing such an information card, the user has to register a cryptographic service provider (CSP) from the identity provider, which CardSpace will invoke from within the indentity selector to unlock use of the card.
If the CSP prompts the user to type credentials like a PIN -- case (b) as you say -- the credentials are used locally on the machine to unlock access to the information card. Those credentials are not forwarded to the identity provider.
Yes, a physical keylogger would be able to record the keystrokes when a passphrase is typed into the CSP, whereas a software based keylogger would not. However, for these logged keystrokes to be used to falsely authenticate the user, the evil doer would have to know which information card was selected by the user (which is typically done with a mouse selection), and correlate the card with keystrokes. Further, the evil doer would have to have access to the user's computer to use the information card: there is no programmatic API for the CardSpace identity selector, so the user has to use the keyboard and mouse to use it.
I wouldn't say that this isn't a risk, but it requires a whole lot more going on than simply attaching a physical keylogger. And it is not as simple as capturing a username and password.
So, I have 10 InfoCards installed in my CardSpace Identity Selector. What's protecting those cards (assuming that they are not CSP enabled) from use by any Joe, Dick or Harry that sits down at my computer?
Is it the windows login that protects them? Then all the key logger needs to do is log the keys and notice what comes shortly after the ctrl-alt-del.
If it isn't the windows login, then there must be something else available. I just can't imagine that anybody sitting down at my computer gets to use any cards that happen to be sitting around in there.
I also find it hard to believe that all those banks that have forever insisted on that stupid browser auto-complete disable attribute being available -- so that they can refuse to allow a user to store their credentials on a computer -- will accept a primarily stored credential model.
Note that I am very much in favor of a stored credential model and use scripts to disable the stupid bank's autocomplete settings when possible, but I just don't see them sitting back and accepting such a change easily.
Correct, if an information card's use is not protected via a CSP, then anyone with access to your computer and user account can use the card. This can be manifested as a friend-of-the-family attack, and that's a serious threat. I imagine that most financial institutions will protect use of their information cards (or use of the accounts that they authorize) with at least one additional authentication factor.
CardSpace does not determine what additional factors may be used, instead it provides a framework that allows additional factors, current and future, to be used through a provider model.
In the demo that we (Corillian) participated in with Microsoft, Arcot, and Wachovia at the RSA 2007 conference in February, Arcot's managed card solution used a PIN to unlock access to the card. But that could have also been any other authentication method.
Certainly, thinking about the threat posed by a physical keylogger makes me want to favor authentication factors that are not based on typing in static text. That's a really interesting point.
Hey, Conor, when I submit a comment to your blog, I always get prompted a second time to enter the captcha text. The second time it always works. Thought you'd like to know.
Oh, fer Pete's sake! Does it really make much difference, security-wise, whether CardSpace can stop a keystroke logger from stealing your credentials or not? Even if it can, I still want to prevent Ms. Naughty from stealing my stuff that I'm going to be typing in later.
That's the main point Conor is making.
As for the concept of a TM, I sure would like to see the day when all the computing equipment sitting on my desk is a TM. I.e. it doesn't need a special, separate module that I consider trustworthy. So here's the cheap shot: I'm at least closer to that day since I'm typing this with a Macintosh.
Stuart, that (the mutli-captcha thing) is just for you... Just want to make sure you really, really want to comment :-).
Post a Comment