Fear the Cowboy

Miha replied to my post on PPIDs, with some interesting questions.

However, everybody says "no passwords" -- I beg to differ. This is exactly the same situation as it is with client certificates.

You are quite correct sir. Using personal information cards are very very very similar to using client certificates.  So, what's the difference? Infrastructure, and simplicity.  CardSpace essentially brings cheap, easy PKI to the people. Using client-certificates certainly fits the bill, but unfortunately, the tools, management and concepts aren't built for my Mom, (but built for me).  That is, I get it, but my mom has no idea what the heck I'm talking about.

Why would you need a password, if a user logs in with the client certificate?

 

You wouldn't. I assume, that Miha isn't from North America. I've found the use of client certs far more prevalent outside of the US and Canada.  Somehow, the concept isn't very popular around here... I guess we'll have to get Senator Stevens to buy us some more pipes so that we can fit bigger pipes to the internets.  Again, client certs work fine, but aren't fine to work with.

Certificate was issued with someone you can trust (and verify), the certificate is valid, the data is signed with the user's private key (and you have the public key).

No argument there.

Now, all the sites I visit, that require client certificate, require the password too.

Are you indicating that you use a password and a certificate, or a password-protected certificate (aka, a pin-protected certificate)?

With a pin-protected certificate, we're getting to the crux of the matter. With a certificate that requires a PIN (and what is a PIN, other than a password) you are accessing protected content.  The difference is, the pin your gatekeeper to your private key, not the secret shared with the website.  You never, ever, need to tell someone your PIN/Password for a certificate. Not the RP, not the IP, not-nobody-not-nohow.

Otherwise, someone, that gets hold of my computer (notebook) could log into my bank account without knowing anything.

Bingo. You betcha. Unless your private key material is protected by a PIN, you're wide open for that.  Security is about "Something you have" and "Something you know".  So, if someone steals your laptop and your certificate is PIN protected, you have the knowledge that they aren't likely going to get around that (provided a good enough PIN). 

Sure, it is more secure, if certificate is guarded with a password (high security in IE, master password in firefox), but infocard(s) isn't (aren't) guarded with a password.

So, what if I told you that CardSpace DOES protect each and every one of your cards with not just one, but two passwords. AND gives you the option for a third!

The CardStore that you have is twice encrypted, once with the machine key, and once with the user key.  Encrypting with the machine key, ensures that if the cardstore is taken off-box, it's rendered useless, as the key for decryption is stored on that box. Either the attacker needs to get administrator access to the machine and compromise the machine’s DPAPI key, or he needs to be able to run code on the machine to call the decryption function. It's not making it impossible, but it's putting a protection countermeasure in his way to slow down the attack. ¹

The second layer of encryption is with the user's key. Because the card store is encrypted with the user’s credentials, when the user is not logged in to the machine, her key is not present on the machine at all.

So, wait a second.... The information cards are password protected. If you have lost your laptop, and someone steals it, unless they login with your password, they can't access the cards.  Even if they use the various physical-box methods (or any method really...) to reset your password , the keys won't match and they will render the card store useless permanently.

And finally, if you don't have the security around your logged in laptop, or you simply want to stop those kids from using your information cards from your always-logged in home PC, you have the option to individually PIN protect each and every card separately.

What's wrong with passwords anyway?

I know, I'm just throwin' good judgement into the wind on this, but let me make a couple of points.

Passwords that are used as shared secrets are the absolute biggest hole in security today. As my pappy use'd to say "Lettin' the cat outta the bag is a whole lot easier than puttin' it back".  If I give a site a password, and they require me to divulge the password back to them before granting me access, It's my butt between the bull and the fence if the connection between me and them ain't secure.  And for every other person I tell that same secret to, I lose security on another order of magnitude.  Given that folks tend to use the same  5 or less passwords at all the sites they visit, the world is a heckofa lot less secure that it should be.

Cryptography gives us the tools to correct the wrongs we've done with passwords. CardSpace brings cryptography to everyone.

<feeling musical, queue's up some Kiss, mangles the words>

...

God gave cryptography to you, gave cryptography to you
Gave cryptography to everyone (oh yeah)
God gave cryptography to you, gave cryptography to you
Put it in the soul of everyone

...

So, what have we learned?

1. Passwords, when used as a shared secret, are the epitome of insecurity.

2. All information cards stored in CardSpace are in effect, password protected with your login credentials and the machine key of your PC..

3. If that isn't enough, PIN protect them again.

For a quick bit of useful information about DPAPI, the machine key, and the user key, check out the text by the very excellent Keith Brown.

Labels: CardSpace, fearthecowboy, Login, PKI, PPID, Security Tokens

I promised Vittorio that I'd write a post on PPIDs (Priavte Personal Identitifers), especially since he's gotten around to his. :D

With CardSpace, the PPID is a claim that the built-in STS will generate. It's the only claim that a personal card can have that the user doesn't get to control.

How it is made

When a user goes to present a personal card to a relying party, and generate a security token, CardSpace takes the SSL certificate of the relying party, and, with the Master Key, uses data from the certificate to create two things: a public/private key-pair and the PPID.  The data that it uses from the certificate depends on what type of certificate it is.

For an Extended Validation (EV) SSL certificate, Cardspace uses the O, L, S, C fields from the Subject field of certificate. These represent the Oraganization, Location, State and Country of the subject (the RP).  Given that the CA has done some extended validation to verify the details of the subject, the subject gains the security that no other EV SSL certificate will have the same fields (unless issued to the same organization).  This also grants the benefits that a organization can have a certificate re-issued with a new public/private key pair, and not affect the identities stored based on it.

For a regular SSL certificate, CardSpace uses the subject fields from all the certificate in the chain, all the way to the root certificate.public key of the certificate. This of course makes the PPIDs and key-pairs generated from that dependent on the issuance chain in the certificate. This may be a problem, if the certificate needs to be re-issued with a different chain later.

This is different than I had said in the past (where I said it was all calculated off the public-key of the RP's certificate), I was apparently behind-the-times with this. Thanks Caleb. Dern newfangled-cryptography!

The net effect of this, is that the PPID and the public/private keypair are completely different for each and every relying party, even when the same personal card is used.  This allows people to use the same personal card everywhere, and not worry about someone replaying their credentials.

So, I can rely on the PPID then?

What? Are you crazy!?

Anyone <glares at Caleb> could craft a token by hand that could contain the PPID. You can't rely on that. ... Alone.

In order to validate the identity of the person presenting the PPID, you have to also verify that they possess the private key which matches to the public key they presented to you with the PPID. The public key is delivered in the form of the Issuer's public key in the SAML assertion.  The token is signed by the Issuer's private key, providing  proof of possession of the private key. This signature can be cryptographically verified by the relying party.

So, you can rely on the PPID, if you verify the signature of the SAML assertion. And, you should store the public key, so that someone else can't craft a token with someone elses PPID, and sign it. So, you have to check both the PPID and the public key, after verification.

Or, you can get lazy as heck.

The TokenProcessor code I wrote verifies the token, and since unverified tokens will throw an exception, this makes this pretty easy.  As an additional step, the class provides a UniqueID field, which is the cryptographic hash of the issuer's public key and a claim that is unique to that issuer (defaulting to the PPID).

So, I can rely on the UniqueID then?

As long as the signature is valid (and the Token object won't get through the constructor otherwise), the UniqueID is what it says it is. Unique to that user. For the relationship that you have with that user. That user will have a different UniqueID than everyone else.

How about Managed Cards?

This works just as fine for Managed Cards as well. You can get the UniqueID for the user based off of the issuer's public key and any field that the Issuer claims is unique in their database.  An issuer may claim that any ID they issue tokens for will have a unique email address, so that the token they give to the relying party (via the user!) is their assertion that the user is who they (the IP) says they are.

Hang on here, something seems oddly familiar.

Uh-oh. My pappy used to remind me of two things about gettin' into trouble. First, "Never slap a man who's chewing tobacco." .. that's good advice you can't afford to forget. The second is a little more on-topic, "If you find yourself in a hole, stop diggin' ."

If you have two things which constitute credentials, only one of which is provin' that the user has something that you don't know, isn't  "PPID" and "Issuer's public key"  just like "Username" and "Password" ? ... Why of course it is!. Except that the password isn't sent. The proof of the possession of the password is sent by virtue of the token being signed by the private key.  And the when public key is sent along with the signed token, the relying party is verifying the password.

Finally, you get to the point.

So, if'n yer lazy, you can add a column to your user database, call is UniqueID, and just verify the token, and get the UniqueID field, and look it up to log em in.

Or, if'n yer stubborn, you can put the PPID into the UserID field of your database, and the issuer public key into the password. I just hope that the password field in your database takes 2048 byte passwords. (heh-heh)... You may want to store the hash of the Issuer's public key. Then you don't have to touch the database, you don't have to change anything, except for a tiny few lines of code to extract the "username" and "password" from the token.

And, now a word from the paranoid bull in the corner.

I've seen a few bits of Relying Party code pop up on the Internet, and I haven't looked at many of them in detail. I will however grant you this word of advice.

IF YOU ARE WRITING CODE TO DECRYPT A SECURITY TOKEN AND ACCESS THE CLAIMS IN IT, YOU MUST VERIFY THE SIGNATURE ON THE TOKEN. DO NOT SKIP THIS STEP

I can not stress this enough.  I've seen some people posting code on the net in different languages, but not performing the signature validation. That's akin to asking for a username, but not checking the password and logging them in.

Y'all relax and enjoy.

Labels: CardSpace, fearthecowboy, Login, PPID, Security Tokens

Imagine a world, all you had was MS-DOS 3.3.

Imagine someone crafted a better version of the command.com shell for DOS, and rather than calling it DOS 4 or something, ('cause that'd be goofy) they called it 4Dos.

This little command processor unleashed something DOS had never seen before. Alaiases, history, and a massively extended command set.  I used this little bundle of joy for years.

Then, the new world came by, and IBM shipped OS/2 2.0. (Yep, I was one of those guys.)  Even though OS/2's command processor was waaaay better than DOS's , JP Software stepped up and produced 4OS/2. (Good name guys!).  It was even better! Couldn't live without it.

1996 came, and Microsoft released Windows NT 4.0--The first Microsoft OS in more years than I could remember, where my first instinct wasn't to use the disk for scrapin' the cow chips off my boots.  JP Software stepped up again, and delivered the goods, in the forms of 4NT. Bingo.

So here it is, 2007, and I'm still using 4NT, every single day. It's literally the second tool I install on a fresh OS these days. (Foldershare being the first!).  If you are a command-line lovin' cowhand, then grab the bull by the horns, and go check it out.

Labels: fearthecowboy, Useful Tools

In my previous life, I was self-employed in Canada, for about 15 or so years.  Now, the Great White North does have Universal Heathcare, but there are limits to what it covers.

Doctors, hostpitals, tests, treatments, * ?... Yes. Medicine (prescription drugs), dental, vision, midwifery? ... No.

That and a few small things is why I was paying for supplemental health care in Canada. Not too much, but I just wanted to make sure that I had the coverage that I needed.

Health care in Canada is funny. Given that it's paid for, you still get the amazingly lousy results. Even to see my GP, I'd have to wait a week to three weeks. Any Specialist? Weeks to months. Book Ahead.

When I came to the US, I was a tad fearful of the healthcare coverage... after all, I'd been born and bred under the flag of universal healthcare (thank's Tommy!) .  Lucklily, Microsoft has their own brand of Universal healthcare, and I gotta say, it rocks.  We pretty much don't have to worry about anything healthcare related whatsoever.  Moreover, we have access to the one thing that Canada still doesn't have: Healthcare service of the Gods.   I had visited my doctor over the course of a few years in Canada to deal with recurring lethargy. (Hard to beleive, if you've ever been near me :D ) I went through test after test, tried this that and the other thing, all with mediocre results.

My first month here, I found a doctor who said it sounded like I had sleep problems, and got me to go get a sleep-study done. I called up the sleep clinic, and found out that I could get in that night--That was weird, I had never gotten such fast access to healthcare services in my life.  So I went in, did the sleep-study, and found out that I have sleep apnea. So, they fitted me with a CPAP breather for night-time, and whoosh! Suddenly I was feeling like a million bucks.

Now, in order to keep us aware of these costs, Premera sends us a statement for every single treatment we get done. This accomplishes two things: First, it lets us check for fraudulent billing, and be able to report it. It's my company's money, I don't want to see it stolen!. Secondly, they keep us aprised of the costs of our healthcare. I was suprised to find out the cost of the sleep study and the CPAP hardware, but for me, it's worth it.

For Microsoft, it's worth 100x that. I'm MUCH more productive than I've ever been, and they are seeing the benefit of spending the money.  You could say that it's good corporate citizenship to take good care of your employees, but I think it's more than that. It makes good business sense. If your people don't perform at their best, what can you do to get them there. Labor is the highest cost of business, and we've got a lot of it.

I shudder to think of working in the US without that fantastic coverage, and what it must be like for the hundreds of millions of people who's company isn't footing the bill. I'm not an much of an activist, and I can't recall being much of a tree-huggin' lefty, but I think that large companies where CEOs and execs get hundreds of millions of dollars in compensation, should provide that universal healthcare to all their employees. It makes good business sense.

Labels: fearthecowboy, health care, Microsoft

Today, I present a tiny little app that I built to help out pasting URLs in various contexts.

TinyUrler watches the clipboard for things that look like URLs, sends them off to TinyUrl to get shrunk down, and puts it back in the clipboard.

Pretty simple, no extra features, just a quick and dirty URL fixer.

Labels: fearthecowboy, Useful Tools

It's a quite a tale, but one worth sharing.

I have spent the last 17 years in Calgary. Quite a nice city, nestled at the edge of the foothills of the Rocky Mountains. Calgary is referred to as "Cowtown" as it's know for (among other things) horses, ranches, cattle, and of course the Calgary Stampede.  These days, it's also the heart of the oil and gas sector in Canada, and has a tremendously diverse culture and economy.

This would also be a good time to point out, that it also hosts the world's most excellent hockey team, the Calgary Flames.

Anyway, back to the cowboy... So, many years ago, I picked up this really nice cowboy hat; it's not a cheap imitation like you will find all over, and it's also very Canadian. It's not a Texas style hat, it's not an Austrailian hat, it is simply a Canadian cowboy hat.  I bought it after my older brother died in a car accident, and the whole reason I wear it has to do with him. (ask me about that later).

I used to wear it only when I wasn't working, (as a long, long-time software development consultant, it wasn't really my white-collar-style), but over the years, more and more, I wore it when I went out.  When I moved to the Puget Sound area, it was November.  With the winter's rain, I found that I had essentially two choices -- wear the hat or drag an umbrella everywhere.  Since the hat was my favorite anyway, the choice was easy.  Well, after I went to work with it every day, I found that I loved having it, it suited my personality well, and I got (and still get) compliments on it all the time.

So, months ago, I was waiting to go to lunch with someone, and I was waiting in her office, and doodling on the whiteboard... I had been drawing this little cowboy hat doodle, and under it I wrote "Feed the Cowboy". Unfortunatly with my handwriting, it looked more like "feer the cowboy". We laughed, and  I thought that was an interesting little packet of words, and began doodling it on other whiteboards around the floor.

As I started to put together my own, personal style, it was remarked to me that it would make a nice theme. So, with that and $20 for a domain name, a new blog was born.

Now, of course, I'm an old cowhand... but my legs ain't bowed. And my cheeks ain't tanned. Hmm. Nor am I actually a cowhand. Well, I tell you what. I sure have a nice hat.

G

Labels: fearthecowboy