Pi and Writing your own SAML Engine

Writing your own SAML Engine, like Pi, is not rational.  Unlike Pi, it can seem rational.  I promise you, writing your own SAML engine is not a rational act.  I have coached and counseled dozens of third-party developers, to the point of even getting in their face, and they don't quite believe me.  Hopefully you'll take this to heart, and avoid some pain.

I've been implementing SAML since 2002.  In fact, I've been doing commercial SAML as long as anyone has.  I was tech lead on the team that was the first to deploy SAML in the real world for real transactions.  We implemented the very first SAML interface to a 3rd party August of 2002, and then did the first 3-way handshake (chained assertion) a few minutes later.  Our commercial system, doing financial transactions via SAML federation, went live 6-Jan-2003.  Since those early day of SAML 1.0, I've implemented dozens of SAML 1.0, 1.1 and 2.0 systems, in roles that have included identity architect, certification engineer, build/run team, solution architect and consultant.  Undoubtedly, there are folks with more SAML experience than I have, but I've got quite a bit, and several implementations that have created scars.

Now that you know my bona-fides, let me tell you why creating your own SAML engine is not a rational act... even though it may appear to be a great idea.

Coding a SAML engine is one of the great examples of a bear trap laid before developers called Just a Matter of Programming (JAMP).  It seems pretty simply, doesn't it?  This is just some WS-Security Web Services with a canonical XML construct, easy-peasy.   Add a dash of auth and a quick crypto lib call, and done!  Yeah, no.   I have not quite seen professional developers break down and cry, but I have seen highly-lauded developers with impressive resumes founder on the rocks of SAML, even though they had all the right skills on paper.  Developers with 10 years experience doing hundreds of custom Web Services implementations have failed to deliver.  In fact, I can confidently say that I have NEVER seen a home-grown SAML implementation delivered in less than 3 months overdue for Browser Artifact SAML, and Browser Post Profile SAML is even worse, because getting mutually authenticating digital certificates seems to be a barrier that crack programmers slam against unexpectedly.  The scary thing is that we're not talking about script kiddies, but highly qualified developers that I've seen fail repeatedly -- kinda like watching a NASCAR driver fail to parallel park when given 100 tries.  It's not an expected outcome.

Perhaps you've had differing experience.  If so, you've been lucky.  I have yet to discuss homegrown SAML engine development with an experienced federation colleague and have anyone take the position that writing your own SAML engine is a good idea.

I'll admit that it's been 14 years since I was a hard-core client-server developer.  I cannot speak authoritatively and explicitly to the exact reason why this is hard, but point out that a SAML engine is the intersection of interactive web-services, session management, access management, cryptography and web access management engines.  Add in load-balancers, firewalls, VLANs, application firewalls and packet rewrites along the way, and it's a devil's brew.  I've also noticed that the incredible complexity that has been added within .Net and Java means that developers increasingly do not have a strong systems perspective.  Most developers seem to focus entirely within software, so may not readily understand network communications and protocols.  Whatever the actual cause, I can tell you that it's a big barrier.

Homegrown SAML engines also have enormous quality problems.  Since the Sunny Day positive- test scenario takes weeks to develop and get working, you can bet there is a lot of buggy code that will be discovered as unexpected conditions result in un-trapped exceptions.  In one notable case I saw a decade ago, whenever a load balancing error resulted in a timeout, an un-trapped exception in the code caused the last session to be provided to the new user -- session hijacking was the result.

Without a commercial SAML engine, who will provide documentation, support, training, maintenance, patching, upgrades and troubleshooting?  With a commercial SAML engine, changing the SAML exchange is a simple configuration change, while home-grown SAML means custom code changes.  Hopefully, the hot-shot developer who decided to write a custom engine is still available, and can figure out their code... but, frequently, they've already moved on.

Now that ADFS 2.0 provides for full SAML 2.0 interoperability, there is no longer any excuse.  It's been bad practice for a decade, it's time to kill this practice once and for all.  If your developers want to play with SAML, let them do so at home.  Meanwhile, buy a commercial SAML engine.  You'll be glad you did.

The next time someone suggests coding their own SAML engine, tell them it's as rational as writing your own Microsoft Excel, since you don't want to pay $150 for a spreadsheet.  Sure, Excel is just some C++ code, so anyone could write a replacement Excel, but it's not a rational act!

On Password Complexity - and why it doesn't matter

The lowly password is one of the oldest technologies in recorded history that is still in use, right up there with beer, bread and bows.  So, why have we failed to eject passwords, even though we know better.  I mean, really, we all certainly know that passwords are prone to losing the very attribute that otherwise makes them useful, that of being a shared secret.  Once it becomes a discoverable or broadly-shared secret, game over.

So, how do we protect passwords?  Largely, we presume that controls added to the passwords themselves (length, complexity, age, history, randomness) will actually do some good.  For a short investment period, they do.  However, once you've added age, history and non-dictionary, the rest is a crap shoot.  The real problem that we have is that users are not like key generating machines - the passwords they select are decidedly NON-random, closely clustered on predictable fault-lines, and look more like housing tracks following BART stations than a random distribution.  With the advent of GPUs and collaborative hash-cracking rainbow table generation, even salted hash is rapidly eroding in usefulness.  We're reaching a real tipping point here, people, where it doesn't matter what you do to the password, it's reaching the pint where you can't add more complexity and still have a human remember it.  We're going to have to go to crazy salt next, where we salt our password hashes with 60-80 byte random strings.

Problem 2 with passwords is that we know they are trivial to crack if we can gain access to the hashes.  Passwords can be cracked in minutes, not days, and creating highly complex passwords doesn't really effectively change that problem space, particularly with GPUs and rainbow tables.  Here's a tough question you should be asking yourself:  Since we know that to be the case, why do you ask users to create and remember crazy complex passwords?

Here I insert a pseudo-joke told to me by Kevin Flanagan, awesome crypto guy at RSA.  He noted the irony that organizations achieve FFIEC multi-factor compliance and FedEx tokens to their customers, and then the user account is a Hotmail, GMail or Yahoo!mail account.  The irony is nearly snort-out-loud funny, except that it's one of pain.  When you have a super-strong password, yet the only thing required to change it is to login to a web-mail account, who are we kidding here?  If you're armoring passwords and not armoring your password reset process, you have ventured into the realm of self-delusion and waste.  You must armor both, if that is your path.  I think an alternative path is much better, personally.  Multi-factor, adaptive authentication, fraud detection over the life of the transaction, span of control & toxic combination/segregation of duties and authorization certification are far more effective than forcing KX@CWLIJv909rdRwp032 as a password.

No, we can't really rely on passwords much longer at all, their usefulness is fading like that of the buggy whip -- great technology that provided acceleration in transportation for 3000+ years that has been eclipsed.  Passwords are ready to fall into antiquated history as anything more than 1 factor amongst 3-4.  Once you're past 2 into multi-factor, why keep password at all?

Security Social Engineering Hack

My buddy Hugh Thompson (star of HBO's Hacking Democracy) just posted a pretty cool write-up of a social engineering hack. Admittedly, this isn't rocket surgery, but he did tie together several logical leaps, intuition, and knowledge of open sources to achieve the compromise. The devestating nature of this isn't that it's some twisted bit of fiendishly difficult code that creates a compromise (though Hugh does have 1337 ninja gung fu). Nope, the frightening aspect of this was how simply Hugh stripped his friend naked (digitally, of course) through this attack.

I know lots of professionals that either publish gmail/Yahoo/Hotmail accounts, or redirect through their public websites (jon.public@jonpublic.com) that still goes to a webmail account. I'm also reminded of the cluelessness of a prior employer, who didn't want me to tell people where I was employed when I was speaking in public, which is pretty dumb, since a 10-second Google search readily found my resume, and it's on Monster.com. However, in their naive perspective on our wired world, my true identity was undiscoverable. Pfffft. Anyone with a dot.clue knows that Google is the Sauron of the Internet, the all-seeing eye, particularly when coupled with archive.org and the WayBackMachine. 1 2 3 4

Why pick the lock on the front door when the back porch just has a screen door?

Perhaps we should all take a page from GunBroker.com that requires your account to be initiated through an ISP account, and remember that at least your ISP knows where you sit. Er, or, at least where your open WiFi network is parked. ;-)

Painfully obvious lesson time here:

• Seemingly innocuous data about your life posted to a blog or social site can readily be used against you. Blogging anonymously is a good idea if you simply must mention specifics.
• Using web-based e-mail carries certain risks that are glossed over by the majority of Internet users in the presence of a compelling usability model.
• Password reset risks and the use of webmail remains ill-addressed by the banking industry, and flies in the face of the FFIEC guidance for multi-factor authentication.
• Password reset components should always be treated equivalent to passwords themselves.
• Even more generally, access to a resource and access to the access to the resource are equivalent, though often not protected equally.

The readily analogy here is keeping your safe deposit box key on your keyring. You know, the same keyring you put in your shoes on the beach?