Hardware Based OpenID Service Available

An anonymous reader writes "TrustBearer Labs has announced a new service that lets you use various hardware based security tokens like smartcards and biometric devices with OpenID. A hardware based connection to OpenID allows higher levels of security and makes it easier for the end-user to control their credentials. OpenID is a decentralized cross-site authentication system that has been gaining momentum for quite a while now with major supporters like AOL, Google and Microsoft already announced."

Comments

Ick.

[Anonymous Coward]

Why do I still get queezy when Open* and Microsoft appear together?

Anything like verasigns pip?

[dns_server]

I believe this already exists with verasigns pip https://pip.verisignlabs.com/ . In this you have a hardware key that rotates it's numbers every 30 seconds.

Re:Anything like verasigns pip?

[cybereal]

I have this verisign pip setup and have a key. It is essentially human delivered asymmetrical authentication. It's great security; plus, it works with the $5 keyfob from PayPal!

Re:Anything like verasigns pip?

[harningt]

Not quite (although it 'could' in theory support it..).. OTP != Strong Cryptographic Authentication IIRR One of RSA's OTP Tokens has been proven to be breakable.

Re:Anything like verasigns pip?

[Jeffrey Baker]

That's really not the same at all. With a SmartCard your keys and certs are in your physical control. The key or cert never leaves the card, and crypto operations also are done on the card. With VeriSign, VeriSign enslaves your identity. They own it, and you have to use the RSA token readout to get VeriSign to unlock your identity temporarily. These are fundamentally different operating principles.

Re:Anything like verasigns pip?

[jerel]

If you want to buy this "FOB", which is functionally identical to RSA's SecureID token, you can purchase it from PayPal, that calls it "Security Key" for an introductory flat $5, no shipping, or from VeriSign, that calls it "VIP Security Token" for $30 plus $6 shipping.

Re:Anything like verasigns pip?

[ohtani]

It used to be completely free for folks with business accounts like I have. They apparently stopped that promotion but I managed to get mine for free when they were still doing it.

Re:Anything like verasigns pip?

[Cerebus]

Private key crypto operations are done on-card. Public key crypto operations are usually done off-card, since the cert is a public instrument and doesn't need to be protected by hardware.

Re:Anything like verasigns pip?

[jbastress]

Right. And in this case, the certificate never even leaves the provider...so no worries about relying parties getting personal information aside from the nickname that you provide when signing up.

Re:Anything like verasigns pip?

[jbastress]

I'm not sure if you're referring to the TrustBearer Security Token for sale on the site (which is /not/ the only supported device...for example, all US-govt PIV and CAC cards will work), or the PayPal device...but as this seems to be a common misconception, I'd like to clear this up.

The TrustBearer Security Key is a cryptographic device (with drivers on Windows update) that goes in a USB port. It uses asymmetric cryptography to decrypt a nonce sent by the provider to prove that the user owns the public key associated with the account. It is for all practical purposes a smart card and reader combined.

The PayPal/RSA SecureID/Verisign token is a one-time password (OTP) device. It shows a different number every n seconds, which you type in along with your username and password to authenticate. As harningt mentioned in another thread, such devices could in principle be supported by the TrustBearer framework if there was significant demand, but it is currently geared towards asymmetric challenge-response authentication.

Re:Anything like verasigns pip?

[cybereal]

It used to be completely free for folks with business accounts like I have. They apparently stopped that promotion but I managed to get mine for free when they were still doing it. Still $5 was awesome compared to verisign's price of around $30. On top of that, I had almost $5 sitting in my paypal balance and no use for it so in my very human mind ;) it was basically 75 cents.

Now if someone would just start using OpenID. Almost nothing useful consumes OpenID yet! I have one site that I use for work that does, and one "to do" site, toodledo.com, that I used to use for my iPhone todo lists but even that site is rarely visited. That plus about 1000 blog sites seems to be all that consume it.

Google seems to be preparing to provide an openid, which is rather useless to me since I'd much rather use my secure verisign provider. But I digress. OpenID may not be the best implementation of this kind of single-sign-on service but at least it is getting some attention.

I'm more than ready to trade in my 100's of logins around the web for just one.

Re:Anything like verasigns pip?

[Tony Hoyle]

I believe that promotion is now over. Going to the paypal site gives the error 'The Security Key is currently not available. Please try again later.' - and has done for the last week.

Re:Anything like verasigns pip?

[Tony Hoyle]

Btw. the verisign link doesn't work. pip.verisign.com doesn't appear to be a hardware based solution, merely an extra username.

I believe SecurID tokens are getting fairly cheap though.. wonder if it'll work with them.

Re:Anything like verasigns pip?

[jerel]

Actually, I bought one from them just before posting my first message. Perhaps it's not available in your area/jurisdiction?

Re:Anything like verasigns pip?

[jerel]

Oops. Sorry about that. Here's a link that should work for the VeriSign token. On that page, click on "Get a Credential".

The RSA SecurID tokens are completely different, according to VeriSign, and will not work with their PIP system.

Tell me sales man

[techpawn]

It requires no middleware software but rather works through the web browser on Windows, Mac, and Linux platforms

But will it run on... Oh? It will?!

Re:Tell me sales man

[sm62704]

Imagine a beowolf cluster of them (shudder)

In Soviet Russia, biometrics validate YOU

Sorry, I can' think of a Natalie Portman joke. I guess I fail it.

Re:Tell me sales man

[techpawn]

Sorry, I can' think of a Natalie Portman joke. I guess I fail it.

It's okay, just relax with some hot grits and one will come to you...

Re:Tell me sales man

[Anonymous Coward]

But will it run on... Oh? It will?!

But will it blend?

Mac ID?

[poetmatt]

Isn't this like a MAC ID in a rudimentary sense? Aren't those already spoofed? I'm debating whether my tinfoil hat should or shouldn't be on, or whether I should call this one for skepticism.

Re:Mac ID?

[Anonymous Coward]

*mac address

Re:Mac ID?

[harningt]

Erm... MAC ID is non-changing... In a simple example of how this works, it does a cryptographic challenge-response so you keep a private key...

Re:Mac ID?

[poetmatt]

Mac ID can easily be spoofed, thus challenges = fail. Even the wikipedia says that . I know there's software and also hardware Mac-ID imitators....I'll try to dig out the link for the hardware ones later.

http://wirelessdefence.org/Contents/MAC%20Address%20Changer.htm that's one example, or:
http://amac.paqtool.com/mac-address-spoofing.htm

Re:Mac ID?

[maxume]

In the sense that the client sends a blob of ostensibly unique data to the server, yes, this is just like a MAC address.

In the sense that the client receives a blob of data from the server and returns the result of cryptographically signing that blob, no, it is nothing like a MAC address.

Re:Mac ID?

[poetmatt]

I guess what I'm asking is this. I'm not trying to play a "you're right/wrong" as I'd be guessing you know more than the basic knowledge I have of MAC ID's and not trying to compete anyway. But what I means is if this is similar in ideas to a MAC ID and how a MAC ID can itself be faked, wouldn't faking the hardware for this new "open ID verification" create new vulnerabilities?

I say this because of things like hardware virtualization that will be required to be emulate this hardware...wouldn't that open the chance to be imitated and thus cracked?

Re:Mac ID?

[harningt]

This is completely different in that a MAC ID is a single piece of unique data that gets thrown around.

There's no need to do any hardware virtualization for emulation. You just need to use the public RSA algorithms to perform operations.

Cracking RSA is a huge undertaking requiring massive brute force.
The entire trick to this thing is that there is a piece of private data on the device that cannot be pulled off without extensive resources.

Now... if one were to lose your card, even in the remote chance that some evil mastermind got your card and were to crack it. It would take many many days and you could have reported your card missing and revoked the public information attached to it (thus clobbering the evil mastermind's plan).
This also assumes that an evil mastermind desperately wants YOUR data and not somebody who's gone and used a password... that's ALOT simpler to hack.

Re:Mac ID?

[maxume]

MAC addresses are intended to be device specific because it is convenient for something like a router to be able to tell different devices apart, even if they are two copies of the same device(this just about sums up my knowledge of MAC addresses). That some people tried to use this as security is a historical accident. The issue is just as you have it, you have to rely on the hardware telling the truth.

What is being talked about here is this stuff:

http://en.wikipedia.org/wiki/Security_token

where the hardware implementation isn't necessarily physically connected to the computer. I sort of answered you question in the context of hardware that is connected(sort of in the sense that I wasn't thinking about the distinction), in which case, one way to implement authentication is to have the private half of a private/public key pair on the device, and have the server send a secret that has been encrypted with the public key -- only the holder of the private key will be able to read the secret.

Re:Mac ID?

[poetmatt]

Hey, I get what you mean. My concerns are the same as that article about RSA though (http://en.wikipedia.org/wiki/RSA#Practical_considerations) . These were the ones that I had in mind. Aren't those methods not exactly foolproof? If information can be gathered, then what? I see 8 different ways listed in the article you provided with which can provide methods to get around the security token. None of which appear impossible to set up with small levels of preparation (compromised machines, man in the middle, it looks like a pretty good sized amount of options available)... the whole "security is not perfect" idea.

To clarify, I'm not saying X random person is going to be randomly compromised. I imagine the level of human error is a bigger compromise than an encryption method in general. However, who can truly say that they think absolutely any method of data protection is ever not going to be figured out? Honestly now.

Re:Mac ID?

[maxume]

I guess it comes down to whether your question/concern is more like "Is it perfect?" or more like "Is it better than a password?". Of course it isn't perfect, but for lots of purposes, a physical token is quite a lot better than a password. As you say, no one really knows how hard it is to compromise the physical tokens(you sort of can't until you have done it), but there are plenty of people who think it is hard enough.

Emulation?

[KublaiKhan]

I can appreciate the notion of a hardware dongle of some kind to prove you are you, but right away I can see an easy way around it.

Once the key has been reverse-engineered, a software emulation thereof can be constructed, and a bit of clever hacking could substitute the software for the hardware.

Consider MAC address spoofing for what I see as a corollary.

Re:Emulation?

[genican1]

or you could just kill them and steal their dongle.

Re:Emulation?

[un1xl0ser]

If the hardware device is any good, it isn't relying on the obscurity of the algorithm as it's security strength. It should be able to stand up to an attack even with a significant (hundreds of thousands) number of known tokens. If that is the case, then you need the seed (IV) of the token you want to impersonate in order to do any damage. That key should be protected like a regular key, and should be resistant to tampering (i.e potted, designed to fail if it is tampered with).

Now most sites that would be doing this will be using SSL with certificates signed by a 'respected' cert provider. If that is the case, the likelihood of getting enough tokens to launch an attack is greatly reduced.

So put away the tin-foil hat. This isn't a MAC address. :-)

Re:Emulation?

[Jeffrey Baker]

Do you talk out of your ass all the time, or only here on Slashdot? If you don't understand the way a smart card works, I would advise not yapping about the "easy way around it" that you just pulled out of your hindquarters.

Re:Emulation?

[Anonymous Coward]

Hacking the RSA-style security fob is nothing at all like spoofing a MAC address. These fobs are both tamper-proof and the algorithms themselves are based on strong, open cryptographic principles. I'm skeptical if _anyone_ has ever broken a two-factor (fob + password) authentication scheme.

Re:Emulation?

[rthille]

I'm still waiting for a smart-card with a tamper prevention system like James Bond's Lotus Esprit.

Re:Emulation?

[harningt]

What sort of tamper-proof? With smart-cards, if you disect it, its kaput. If you enter your pin bad x times, its dead.

Re:Emulation?

[KublaiKhan]

There are ways to determine the structure of something without actively 'tampering' with it. Consider the means that art historians use to determine what was painted on the canvas before the work on top was painted, for example.

Widely available? No, not really. But no security is impossible to crack; I'd like to know exactly how difficult it is to do so before I'd consider forking over for one.

Re:Emulation?

[KublaiKhan]

What part of the smart card system precludes emulation?

Re:Emulation?

[harningt]

Nothing at all. What smart cards bring to the picture is the ability to send data to a device and get processed data back without the ability to see the key that is used to perform said processing.

Re:Emulation?

[Sancho]

I'm by no means an expert on these hardware dongles, but what they usually do is act as a secure private key store. Software on the computer issues a challenge to the dongle, which then computes the response using the private key and sends that response back to the computer. The key never leaves the dongle, and is thus protected. Software spoofing would work, assuming you could get at the key.

A lot of these dongles are write-only, however. You can write a key to the device, and you can delete the key, but you can't ever read it back. This prevents attacks where a malicious user steals the fob to extract the key, or where malicious software tries to do the same. They're really quite secure.

Re:Emulation?

[harningt]

... A lot of these dongles are write-only, however. You can write a key to the device, and you can delete the key, but you can't ever read it back. This prevents attacks where a malicious user steals the fob to extract the key, or where malicious software tries to do the same. They're really quite secure.
Even better than that, you can make the dongles generate a key so that nothing has ever seen the private key but the dongle from which it holds onto.

Re:Emulation?

[Anonymous Coward]

Reverse-engineering the algorithm has already been done. Software that emulates the process is available for purchase. The cryptographic principles are well-known and have been in use for twenty years. You're welcome to attempt it, though I think it'll be slightly more complex than spoofing a MAC address. ;-)

From a Bugtraq article which describes the "leak" of RSA's SecurID algorithm (similar to any one-time fob):

                  Over the past 14 years, hundreds of the world's most capable
crypto and protocol analysts have had direct access (under NDA) to the
SecurID hash and the ACE source code -- for customer pre-purchase
evaluations, and in various government certification and evaluation
programs (in the US and several other countries.)

                  Each of those evaluations used the Kerchkoff base-line. Analysts
always presume that all adversaries have full access to the SecurID hash
and the ACE protocol -- full access to everything except the 64-bit seed,
the SecurID's "shared secret."

                  Brainard's SecurID hash is an "irreversible one-way
function" which takes as input a true-random 64-bit token-specific "secret
seed," places it head-to-toe with a 24-bit representation of Current Time,
and processes the concatenated input to generate a continuous series of 6-8
digit SecurID token-codes.

                  In the SecurID's trademark rhythm, each PRN token-code is
displayed in an LCD on the face of the token for 60 seconds, whereupon it
rolls over to display another.

Re:Emulation?

[harningt]

Erm... you must be talking about this OTP token.
RSA is completely public and single keys have been under attack for years and years.... The largest key they've cracked so far is RSA-640.

RSA 1024 is a 'minimum' of sorts now and 2048 is to be commonplace soon.

Elliptic Curve is also on its way....

Rule of thumb w/ this security stuff... the growth-ratio of stronger crypto vs cracked crypto is speeding up... so by the time your thing is cracked, a new system is available.

Re:Emulation?

[rthille]

I guess I'm too old for slashdot :-)

In the movie (don't remember which one, I saw it when I was a kid), Bond's car is parked outside a bad guy's property while he rescues the damsel in distress. As they go back to his car, one of the bad guy's henchmen try to break in. The car explodes in a giant fireball, obviously killing the henchman.

Re:Emulation?

[Jeffrey Baker]

Sure you can emulate the smart card, but not the data on it, which is the important part. I have a PC just like yours but I don't have all the _data_ that's on your PC, so it's not the same.

Re:Emulation?

[jbastress]

While I agree that this doesn't even remotely resemble MAC address authentication, there are a few things that seem to be misunderstood...

First, the TrustBearer OpenID site doesn't currently support one-time password (OTP) devices like the one you're referring to...at the moment it supports public key authentication, the kind that web servers use for SSL.

As far as OTP being broken, it would be possible for a phishing site to ask you to enter your credentials, then submit it to the real site before the validity window expires and successfully impersonate you. As the window is usually on the order of a few minutes, this doesn't really provide any better phishing protection than regular username/passwords. It does, however, enforce a policy that would prevent anyone from being able to guess your password.

Another difference between OTP and public key authentication is that for OTP to work, the server has to know something secret about your particular device for it to be able to know what your current password is, which means that you would be locked into a single provider (usually the manufacturer)...but with public key authentication, there is no such constraint.

Re:Emulation?

[Tony Hoyle]

So of james bond parks in the street, some scrote decides to smash his window his car blows up taking out nearby cars and buildings and possible a few people with it.

I'd love to try to get that past the insurance company!

Re:Emulation?

[rthille]

Yeah, something like that. In the movie, the bad guy smashed the driver's side window with the butt of his rifle. It's difficult to speculate, but it seemed that in the bond case, the security system was more about keeping the spy tech from falling into the "wrong hands" than just killing someone who was trying to jack his car (since obviously a blown up car is of no more use than a stolen one :-)

Verisign Has Similar Offering Via Paypal

[Dr. Transparent]

Paypal has been offering tokens for a while now (for $5). And they work with Verisign's Personal Identity Provider service.

So for $5 you can get a little "football" of a token that will work as an OpenID login for any site that supports open ID.

Re:Verisign Has Similar Offering Via Paypal

[harningt]

The problem with this is that its no fun to have to enter _3_ pieces of data. For security to work in this world, it either has to be no more work for a user, or make it easier. Example usage: * @ site A, enter openid.trustbearer.com as the ID (no need for username since it can be discovered w/ OpenID 2.0) * Redirected to OpenID login page * Enter X digit PIN * Logged in No entering username + password + long ugly number

Re:Verisign Has Similar Offering Via Paypal

[cheater512]

Business accounts get one for free. :)

Its a very sensible move on Paypal's part.

Re:Verisign Has Similar Offering Via Paypal

[c_g_hills]

Unfortunately they are still only available to users in Canada and the U.S.A.. I asked recently and they have no plans to offer it to users in Europe. However, I would much prefer using a one-time code over sms. In theory, I register my cellphone number with my providers (banks, etc) so that I only have one hardware device to look after. If it ever it gets lost, I only have one call to make to report it stolen, instead of having to call up each provider.

Re:Verisign Has Similar Offering Via Paypal

[Tony Hoyle]

When I contacted them they said it was because the offer had expired some time ago.

At least I know the real reason now. Lying toads.

You can get SecurID tokens for about £50ish from some places but I think they need special (expensive!) Windows based software to work.

Extra software needed - Not so good.

[Anonymous Coward]

It requires special software which also seems to be proprietary.

Re:Extra software needed - Not so good.

[Anonymous Coward]

False. Paypal's token requires no software at all. You just log on as normal with your username/pw, and tack the six digit number from the token to the end of your password.

Re:Extra software needed - Not so good.

[Wesley Felter]

AFAIK, TrustBearer does not use Paypal's token; it uses a smartcard that requires drivers.

Re:Extra software needed - Not so good.

[harningt]

It uses a tiny browser plugin (~1MB) that supports an array of devices. More devices can be added on the backend w/o messing with the plugin. You install a plugin for flashy stuff, why not one to support security devices? Example of how this plugin is different from what others is out there: * Get Middleware stack that's about 10-50MB big (likely windows-only) * Hook up PKCS11 module to your browser (or) hook up CSP for *shudder* IE * ... be stuck with that gargantuan stack for one device... Plugin: * Get browser extension ~1MB (cross-platform/cross-browser) * Go to sites that use it and "It Just Works"

Re:Extra software needed - Not so good.

[jbastress]

It's true -- extra software is needed...but the same is true of any peripheral connected to your computer.

Any cryptographic device will need to be attached to the computer, and software will need some way to talk to it. Since the VeriSign/PayPal token is a one-time password token, the back-end "shares a secret" with the token, no direct communication between that device and the computer is necessary, except through you via keyboard input.

However, with a smart card or other security device, the private keys cannot leave the device, and don't exist on a server anywhere. To prove that you "own" the certificate that you present, you encipher some data with that private key, which the OpenID provided then deciphers with your public key. If it's the same data that it sent you, then you own the key and you are authenticated.

Regarding installing "extra software", most card readers have drivers in Windows update, and are standards-compliant so they work out of the box on Mac/Linux. So installing the "extra software" involves clicking "Next" a few times, then "Finish" the first time you plug your reader in...sort of like what you would expect the first time you plug any regular USB storage drive into your computer.

Re:Extra software needed - Not so good.

[RupW]

To prove that you "own" the certificate that you present, you encipher some data with that private key, which the OpenID provided then deciphers with your public key. If it's the same data that it sent you, then you own the key and you are authenticated. Thanks for the information. How does the browser interface with the security card, though - how do you pass the enciphered data from the card to the OpenID website? Won't that need a browser plug-in in addition to the card drivers?

Re:Extra software needed - Not so good.

[jbastress]

That's the 1-meg signed browser plugin that harningt was talking about...installing that is about as painful as installing Flash, and it works with IE, Firefox (Windows, Mac & Linux), and Safari.

Re:Extra software needed - Not so good.

[RupW]

Ah, I missed that, sorry - thanks.

Privacy Problem

[jswinth]

Doesn't this create a new privacy problem much like search data? How likely are companies providing the authentication services to create logs of which sites you login to? It is one thing to know what I search on but it is even more invasive to know which sites I actively login to.

Re:Privacy Problem

[paulthomas]

This is an interesting problem, as I suspect that not everyone will be operating independent OpenID servers. But, as the spec is open, people who know and care (you and I) can avoid this problem.

Re:Privacy Problem

[CSMatt]

Well, your ISP already knows this information, unless of course you regularly use Tor to browse the Web. How is this any different?

Re:Privacy Problem

[jswinth]

It is not cost effective for my ISP to log every DNS lookup or every IP I communicate with. The only way for the government to get at the information is a direct tap. This also only gives you information on my browsing habits from home. If instead you could gets records from my OpenID provider, you could see what membership websites I regularly visit whether it was from home, work, or Starbucks. Working in reverse, lets say that there are VERY BAD websites that operate outside the USA but use OpenID. If your OpenID is at US provider then the government could simply ask the provider to list anyone who logged in to those VERY BAD websites. The problem is that VERY BAD ends up being broadly defined. My point is that in creating centralized authentication you also create the potential for centralized tracking.

Re:Privacy Problem

[jbastress]

This may be an issue with many OpenID sites, but this one in particular dodges your worries.

Since the certificate you pass to the provider is never released to the relying party (and which regardless doesn't need to have anything tying your identity to it), you are even more anonymous than with traditional username/password authentication -- the only one who knows who you are is you...the provider just knows you by your public key, and the relying party only knows that the provider consistently says that you are http://openid.trustbearer.com/yourfakename.

Re:Privacy Problem

[jswinth]

Wait... I'm confused. I thought one of the selling points of OpenID was that websites could verify things like your age and/or zipcode without you having to give personal information. Wouldn't my provider need to know who I am in order provide such information? Or is OpenID going to be one of those completely untrusted information things where 50-year-old men have ID's that say they are 14-year-old girls?

Re:Privacy Problem

[jbastress]

Age would be one of the pieces of optional metadata that can be provided to the relying party if it is ever collected...if, for example, a web site wanted to authenticate someone's age but the provider did not provide that about a user, it would reject the authentication on those grounds. The TrustBearer site only asks for your nickname and email address, so that's all it could conceivably release to the relying party, and I don't think the email address is even released...and so far, it seems like that's sufficient for every site that I've tried.

Regarding 50-year-old men posing as 14-year-old girls, an OpenID provider could assert that it does indeed verify the age of its users. If it became known that a provider was lying about this, that provider would be quickly blacklisted (or un-whitelisted) from sites that cared about age. This is sort of analogous to the logic behind why you can't use a school ID to buy booze. The school says that you are you, and that's cool for many situations, but it isn't considered to be as authoritative as a credential issued by the BMV.

Re:Privacy Problem

[harningt]

OpenID doesn't have any type of personal information. It's SReg and Attribute Exchange extensions help you autofill registration forms that may need more data than a simple identity, but no provider is expected to validate this information... thus no Relying Party should trust it more than a user filling in data.

OpenID has one purpose, provide a secured unique identity while optionally passing on user-provided information.

VeriSign already does this.

[unrealmp3]

I have a Verisign Personal Identity Provider (PIP) which is free as an OpenID identifier, but unfortunalely OpenID isn't much available today. However, I would be willing to get a Security Token from VeriSign if I rely on my OpenID to access most of my Internet account.

And Microsoft is in it because...

[bananaendian]

1. Find out there's a new emerging standard
2. Get involved using overwhelming marketshare
3. Introduce proprietary fucked-up implementation
4. Profit

same old story...

Re:And Microsoft is in it because...

[harningt]

They're in this to make their CardSpace more appealing.... but Microsoft has nothing to do with this system.

Re:And Microsoft is in it because...

[triso]

1. Find out there's a new emerging standard
2. Get involved using overwhelming marketshare
3. Introduce proprietary fucked-up implementation
4. Profit ... Sometimes, 2) and 3) are reversed. For example: the MS JVM, HTML in IE and the MS version of Kerberos.

Decoupled authentication

[Bogtha]

The is something I was trying to explain the last time OpenID came up on Slashdot. Because authentication isn't done by the websites and web applications themselves, it means users can shop around for an authentication system that suits them, and none of the websites or web applications that you log into need worry about it. If/when OpenID starts to become mainstream, I'd expect to see a lot of interesting work done on authentication. A hardware scheme like this isn't feasible if you have to persuade each individual website and web application provider to implement it.

So, when can we log into Slashdot with our OpenIDs? Has there been any word on the subject at all from Taco et al?

Re:Decoupled authentication

[xenocide2]

Which sounds great, until you realize that for-pay web apps would shudder to adopt a scheme that allows transparent anonymous logins.

Re:Decoupled authentication

[ballwall]

I don't think it works like that.

It would be more like, I go to my profile page 'ballwall' and there's a field for my openID username[s]. After I populate that I can log in with that or my regular slashdot id. I'd imagine that once you've successfully logged in via openID that you would be able to disable normal password auth altogether.

I'd really love to see this get widespread use. I really really want to use two factor authentication everywhere. I very much dislike having to manage a ton of passwords.

In fact, I might like it enough that I'd actually wade through slashcode to try and implement it if it would have a remote chance of being used.

Re:Decoupled authentication

[xenocide2]

Right. So you set ballwall to authenticate against whatever openID server. And then tell all your friends about your WSJ subscription. OpenID is not intended to be two factor identification. It's intended to address the explosion in websites (blogs, mostly) that request / require accounts for some reason.

But there was a challenge that was offering a couple thousand to whoever could get openID support into popular tools. Donno if slashcode's included.

Re:Decoupled authentication

[Tony Hoyle]

Pay for web apps would probably only allow verisign paid openids.

Anyone can create a random SSL certificate as well... the can't be used for anything.

Now slashdot allowing those anonymous openids... that would enable drive-by trolling. Login using anonymous temporary openid, say something rude about Linux, log out, wash, rinse, repeat.

Re:Decoupled authentication

[mdwh2]

Login using anonymous temporary openid, say something rude about Linux, log out, wash, rinse, repeat.

Last time I looked, Slashdot already allowed anonymous comments. Yes I would expect the anonymous bonus modifers for those that use them to also apply to default OpenID comments, otherwise that would be a bug. The implementations I've seen such as on LiveJournal do treat OpenID as anonymous as far as things like comment settings are concerned, so I don't know why you persist with this strawman argument.

Re:Decoupled authentication

[Bogtha]

Right, and what's stopping you from sharing accounts now, without OpenID? This isn't a problem that OpenID introduces, it's a problem that's always been there.

REMOTE_USER

[thanasakis]

As long as the openid provider (the party that provides the identity by utilizing an authentication mechanism) can access the the REMOTE_USER env variable or something equivalent, it can perform its duty normally. I think it is really not important whether there is username/password based authentication or PKI authentication using soft tokens or hardware crypto tokens or biometric authentication or one time passwords or whatever else. It is up to the implementor of the service to decide what kind of authentication will be used according to his/her requirements. Using an external authentication mechanism can slightly perplex the situation on how logout is performed (as it is dependent on the auth mechanism) or on how attribute based authorization is being carried out.

But overall it gives great flexibility to the implementor because he/she can layout a scheme were existing authentication/authorization infrastructures (like an institution's LDAP for example) can be used in a cross platform way to offer web based identity.

Similar but different than Verisign and PIP

[Anonymous Coward]

This is similar to PiP and Paypal, except this uses PKI (public key infrastructure) based tokens and devices. It is less prone to phishing attacks than traditional one time passwords models like the Paypal device. From what it looks, this model seems very easy and the pki is hidden from the user. I would only assume the device has quite a few other capabilities like digital signing as well.

Re:Similar but different than Verisign and PIP

[harningt]

Consider this TrustBearer Live / OpenID as Self-Service PKI for the everyman. More of the PK, less of the I.

Distrust 'trust'

[ishmalius]

I worry whenever I see the word 'trust' juxtaposed with OpenID. I worry that organizations will misuse OpenID, and ignore its purpose: only provide an identification for a person, nothing else. It doesn't certify the person's character, background, politics, or financial base. If I say that I am user@server, then OpenID is just a bit of evidence supporting that. That's all.

Re:Distrust 'trust'

[harningt]

I worry whenever I see the word 'trust' juxtaposed with OpenID. I worry that organizations will misuse OpenID, and ignore its purpose: only provide an identification for a person, nothing else. It doesn't certify the person's character, background, politics, or financial base. If I say that I am user@server, then OpenID is just a bit of evidence supporting that. That's all. How would one certify said information? OpenID does offer an 'SReg' and Attribute Exchange to help provide additional information to OpenID consumers... There is no vetting. What you're thinking of is CardSpace where certifications of such information is built into it.

itsatrap

[Anonymous Coward]

I looked at using openid any number of times and every time I ended up thinking "WTF am I missing here"? But you know something makes zero sense from security or authorization perspectives when Microsoft get behind it.

Anyone can run an openID server, that's the good thing about it but also the flaw that defeats it. If you allow users to log onto a blog or forum via openID, spammers get to avoid the captcha. So you're forced to grant openID users the same privileges as anonymous posters. Zero gains here, at best OpenID can prevent a user from filling in a couple of text boxes when registering with a site.

Microsoft are attempting to grab a slice of the authentication business (recall passport and hailstorm), they know full well a decentralized system like openID is useless. Almost instantly we'll see sites only supporting recognized ID providers. ie: OpenID can only ever work as advertised if it's closed; fuck that!

Re:itsatrap

[thanasakis]

OpenID can only prove that you own a certain url, nothing more, nothing less. Here's how it works:

• I go to a site (we'll call it the consumer) that uses OpenID
• I type my openid, let's say http://slashdot.org/~user345
• The consumer fetches http://slashdot.org/~user345 and looks for specific pattern in the file (never mind the details). That pattern provides a server url (we'll call it the provider)
• The consumer redirects my browser to the provider with some specific GET arguments.
• I authenticate myself to the provider
• provider redirects me to the consumer, but with some extra GET arguments with me
• consumer sees my arguments
• consumer contacts the provider for some verification
• If the verification is successful, consumer now knows that indeed I own http://slashdot.org/~user345
• Now I can identify myself to the consumer as http://slashdot.org/~user345

Re:itsatrap

[Anonymous Coward]

Yes thank you, I've written partial implementations of both server and consumer components. What I still don't understand is this small detail we'll refer to as "the entire point". At best OpenID moves the login process to a potentially untrusted 3rd party.

Compromising or covertly operating a public openid server is gold for spammers. A scheme designed to facilitate identity theft wouldn't look so different to OpenID, it's useless on every level.

Re:itsatrap

[mdwh2]

If you allow users to log onto a blog or forum via openID, spammers get to avoid the captcha.

No, you can still make OpenID users type in a captcha if you wish.

So you're forced to grant openID users the same privileges as anonymous posters.

The difference is that the person I'm replying to knows I own that OpenID account, rather than me just being a random anonymous person.

Zero gains here, at best OpenID can prevent a user from filling in a couple of text boxes when registering with a site.

Well that is the point, and it's more like fill in multiple text boxes, provide my email address, wait for email to arrive (or possibly wait ages for account to be approved), click on link, then finally be allowed to leave a comment, which by now I've probably forgotten.

Do that on every single site, just to leave a comment? In practice, I give up and don't bother.

If you don't value your time, then yes, there are zero gains.

And I note you couldn't be bothered to register with Slashdot, so obviously you don't think it's just a "couple of text boxes"...

Re:itsatrap

[Tony Hoyle]

The difference is that the person I'm replying to knows I own that OpenID account, rather than me just being a random anonymous person.

No, it knows nothing. OpenID has no trust, so they could have just visited http://www.jkg.in/openid/ and generated one for that purpose.

OpenID says zero about who you really are. You are an anonymous user - which is why it would be crazy for a site which previously required registration to allow OpenID users to post simply based on the existence of that token. You're going to have to registry/verify your email/etc. *as well* so you've gained nothing.

Re:itsatrap

[mdwh2]

I know that, that doesn't change the point, I just wasn't explicitly clear. I wouldn't expect a site that previously refused anonymous comments to allow OpenID - but that doesn't mean OpenID is useless, or that all OpenID comments are equivalent to an anonymous one. Yes, OpenID means that the person replying has been authenticated by that URL. Yes, OpenID should by default be given the same privileges as "anonymous" comments, because you could have an OpenID server that is open to anyone.

This is no different to email. You could set up an email server that allows anyone to access it. But that doesn't mean that _all_ email accounts are run by this way. If I receive an email from myfriend@myfriend'semailthatIknow, I can know it's from him, or someone he's given permission to use. Yes, there is still the possibility that he's let someone else use his account, but this is a long way from saying that email accounts are useless and it's equivalent to people emailing you anonymously!

Similarly, if I know my friend owns that URL, then I do know that it will either be my friend, or someone he has allowed access too. Just because there exists some anonymiser OpenID server is no more relevant than an anonymous email server, because I'll know that the OpenID is from http://www.jkg.in/openid - you can't use it to spoof someone else's URL.

Also it is possible to give extra privileges to specific OpenID accounts, which you can't do with anonymous accounts. For example, I use OpenID to allow people on other blogs to read my "friends only" posts. Does the existence of http://www.jkg.in/openid mean that anyone can read those posts? Of course not.

Security risks?

[CSMatt]

Call me old fashioned, but I like the idea of not having to use central authentication to log into websites. What if my OpenID information is compromised? If each site has its own authentication, I can use separate usernames and passwords to safeguard my accounts. If one is compromised, then only the account at that site is at risk. But if my OpenID information is compromised, then others can log into any site that uses my OpenID information.

Re:Security risks?

[sloth jr]

Agreed. However, I think in practice, most users use only one or two passwords to login to the vast majority of websites. OpenID thus seems to simply codify this "truism", if I'm on-base. While a centralized password might make mass ownage of websites possible, it should also be simple to shutdown that account across a wide swath of websites more or less instantly.

sloth jr

Re:Security risks?

[CSMatt]

True, but that relies on the original account holder to know that they have been compromised to begin with. Given the amount of identity fraud victims that don't even know that they are victims until it's too late (although I would imagine that number has gone down in recent years with recent awareness of identity fraud), it's not too hard to imagine that there are several account holders online who don't even know that someone has guessed their password, especially if the account holder has abandoned the site (one-time purchases and such).

Re:Security risks?

[intangible]

You could have multiple OpenID accounts.  It would be just like having multiple email accounts for authentication.

Re:Security risks?

[Aladrin]

And nobody is stopping you from doing that. Get multiple OpenIDs. Get them from different providers, if you like. You can still do it your way while the lazy ones (me included) use single sign-on and makes our lives a little simpler.

Re:Security risks?

[mdwh2]

Do you have several different email accounts, out of fear that if one email account is compromised, they can send out emails to everyone you know?

Do you think Jabber is a bad idea, because then if that's compromised, they can pretend to be you when chatting to anyone, but AIM, Yahoo and MSN are safer because they are separate?

I think you misunderstand what OpenID is. it's not a "central authentication". It's just a way that means you can use your login to identity to other sites. Just like my gmail email account can not only email people at gmail, but also at every other email server. Yes, theoretically having loads of separate email accounts - one for gmail ppl, one for Yahoo ppl, etc, is more safer, but I don't know anyone who does that.

OpenID for non web clients?

[IGnatius T Foobar]

I would like to use OpenID as a "single sign on" solution for a wide range of services. The problem I see right now is that it's only viable for web based services. Does the OpenID technology have a way (or is planning one) to authenticate when the client is something other than a web browser? I'm thinking things like IMAP/SMTP mail, console mode login (ssh/telnet), etc. etc.

Re:OpenID for non web clients?

[chappel]

I'm looking for the same thing - but I'd like to leverage the hardware component, too. Is there a reasonably convenient way to use the RSA keys or something else on one of the 'trustbearer' devices? Having single-sign on to a handful of websites would be handy, but I'm more interested in tighter security for non-web stuff. If it is supported by OpenID I'd say that's a bonus.

Re:OpenID for non web clients?

[jbastress]

We may have a solution (free, of course) that will do exactly what you're asking for. Write info@trustbearer.com with "TrustBearer Token" in the subject and mention this post, and we'll hook you up.

Found Video Demos

[harningt]

http://www.vimeo.com/688747 http://www.youtube.com/watch?v=krysgUj9_hU

Single Sign-On

[Anonymous Coward]

Am I the only one who doesn't consider Single Sign-On as a feature, but rather a big security problem?

Re:Single Sign-On

[mofag]

Don't worry, it doesn't work in any case. Last time OpenID was on slashdot I went straight to the openid website and got myself an OpenID from one of its recommended partners. I then went to another OpenID website partner and tried my open ID and guess what - thats right it had never heard of me. Now I know I can be very stupid at times but I read the OpenID homepage and I did what I was told and I thought I understood that you register once and you get to play in lots of different places without registering again and but I still appear to have to sign up for every individual OpenID website so can anyone please explain to me what the point of OpenID is?

I really want to know. Now before I get modded offtopic, let me just say that I don't see the point in a hardware version of something for which I can't fathom a use in software or hardware and so obviously, that being the case, there wasn't much point in me reading TFA :)

Re:Single Sign-On

[mdwh2]

Sounds like something wrong with that site. I use my LiveJournal OpenID to leave comments on other blogs, without having to sign up for a new account at every single blog host.

Re:Single Sign-On

[Tony Hoyle]

It relies on providers cooperating with each other - clearly the sites the other poster tried had not agreed to share users. You're going to need multiple openid's anyway.. some of which will be chargable (this much is admitted on the openid site.. you can bet verisign are itching to charge a fortune for 'secure' openids and charge double for 'super secure assured' openids).

Saying the users from one blog work on another blog isn't saying much. When I can log into slashdot and my bank with the same ID then there's a single signon system (not that that's necessarily a good idea, but it's just an example).

Re:Single Sign-On

[mdwh2]

Saying the users from one blog work on another blog isn't saying much. When I can log into slashdot and my bank with the same ID then there's a single signon system

Well Slashdot is just another blog (in the sense of "forum that I might want to leave comments on). Yes it would be good that more blog hosts and websites support it, but that's a problem with lack of support, not a problem with OpenID itself. Hopefully support will grow in time. Slashdot isn't the be all and end all of websites.

My bank has its own set of login methods that are much more secure than simply typing in a password, so I wouldn't expect it to support OpenID. I'm not sure why you think being able to identify yourself on a range of different sites is useless, just because there exists one site that still has its own system.

Higher levels? I'm dubious....

[Itninja]

allows higher levels of security

Security authentication is based on three possible factors: something you know (like a password), something you have (like a smartcard), or something you are (like biometrics). Now, if these things will be used in addition to passwords, that would indeed take the authentication factors from single to double. But, as is usually the case, they just replace passwords with smartcards or dongles. So there would be no increase in security at all.

Re:Higher levels? I'm dubious....

[jbastress]

To unlock the private key on the device that you have, you need to know the PIN...so that's two-factor.

For the biometric devices, there are two options: either the biometric replaces the PIN, or you need to swipe and type.

Biometric

[jroysdon]

When I read this story, I decide to get my Thinkpad fingerprint working.

So ThinkFinger stores 3 copies of what my finger looks like on my local PC. That makes sense for auth on a local machine. How does this work on an enterprise scale? Is the fingerprint details sent to a remote central storage system which then confirms a match?

If that assumption is correct, how would OpenID-enabled websites work with that? Would your account somehow point to your OpenID "provider" which would have your fingerprint to confirm authentication against? Would the fingerprint go just from the PC you are at to the OpenID provider, which will say, "Yes, it's good" or go via the website first?

With such a single sign-on system, if it did go to the website first, wouldn't there be a danger of some "bad" (or compromised) website storing my fingerprint? I know I don't have my head around how this all works just yet - any good explanation of the technical details? The overview doesn't help much there.

Re:Biometric

[jbastress]

TrustBearer supports two fingerprint readers: one supports both Match on Card (MoC), Match on Reader, and Match on Server. The other is a standalone device that matches your fingerprint on the device itself.

The Match on Server solution is what you are describing, but this raises privacy, policy and integration concerns. In the other two situations, the fingerprint "image" is stored in write-only memory on the device. When you swipe your finger, the image goes straight to the device which then tries to match it against the stored copy. If it succeeds, it sets an internal flag that will allow you to use the private key (which may also require a prior PIN verification if three-factor authentication is desired). The private key is linked to a public key in a certificate that is sent to the server...so your biometrics stay private.

Re:Biometric

[jroysdon]

But then the downside to MoC or MoR is that it only works at that one location (or you have to push it out to all the PCs you want it on). If I have multiple PCs or even public terminals I want to authenticate from, it's no good, right?

Also, by storing the fingerprint on the PC, the PC's physical security is a big deal - the same that is true of a private/secret key for SSH or GPG. But at least with GPG I can revoke a public key (and have stored revokes ready to go already) and/or time expirations. With my fingerprint stored locally, once it is stolen, it's stolen (has anyone made Mission:Impossible fingers that you can "print" a finger image on?). Whole new level of "identify fraud" there, eh? I guess the same is true if it is remote on a central server, but at least that server should be highly secure just as the CA root private stores are to be.

So I guess for local security to your PC you could use biometrics, but really for remote security you want some sort of SecureID type deal (which you can revoke if lost, and isn't vulnerable to a man-in-the-middle attack). Just thinking out loud here.

Re:Biometric

[jbastress]

Actually, MoC (which is preferred over Match on Reader, and equivalent FAPP to match on device) stores the fingerprint on the card itself -- in write-only memory, so it can't ever be read...it can only be used by the card/device itself for matching a live swipe.

It's cool that you mention public keys, because that's really what this is all about. When you match your print on the card/device, it allows your private key to be used for a decryption/signature operation, which is what really used to authenticate you -- just like PKI with SSH. Hardware security devices also get around the problem of exposed private keys, because like the biometric template, smart cards always store the private key in write-only memory -- or sometimes, in memory that can't be read or written to from the outside -- they just support an on-card key generation procedure that returns the public key, but keeps the private key locked away, so it has never left the card. And even if the key somehow did get compromised, revocation is just as easy as revoking a "soft" key on your hard drive...just generate a new keyand enroll for a new certificate to match it.

Or did I just totally misread that?

TPM

[emj]

Yeah, that's how the TPMs work that you can (could?) find in a lot of biz laptops. Great for certifying connections being made from a specific laptop, or for the paranoid being made while that laptop is running.

Re:TPM

[emj]

Actually keys aren't stored on the TPM, they are stored encrypted on your hardrive and you load the keys into the chip which then decrypts the keys with the help of a private key stored on the chip. But the decrypted keys never leave the chip.

only $40

[Anomalyst]

Why is it they always neglect to mention how much they want to suck out of your pocket for their "latest achievement". Also beware, using the site requires you to trust their marketing droids to code java securely in order to get any details. I see nothing on the page that requires anything more complicated than standard HTML with hyper-links.

Re:only $40

[jbastress]

Actually, those with existing devices (for example, the 6 million people in the US with PIV or CAC cards) can use those at no cost. The tokens for sale on the site are for those who don't already have one.

Also, where's the Java that you're referring to?