I’m really happy to report that today I join the board of directors of the OpenID Foundation, representing Ping Identity. This is a big decision for us! It reflects not only our strategic conclusion that OpenID is a critical part of the ecosystem that will evolve in this new decade, but also our tactical roadmap, driven by our customers and their use cases.
From a personal perspective, I am excited to be able to more closely work with all the smart folks that I’ve been rubbing shoulders with for years and years at IIW, and to literally have time allocated in my week to focus both on OpenID technology and community tasks. I believe 2010 will see renewal and acceleration in both consumer identity and enterprise identity: having a small part in that growth will be fascinating.
Check out the Ping Identity Press Release here.
Patrick just posted to the Ping CTO blog some of our combined thoughts about what a terrible idea it is to synchronize Enterprise passwords to the cloud: Grounding Enterprise Passwords.
The ctotalk blog post is much more detailed so make sure to read it, but let me sum up in somewhat stronger terms: Giving away the shared secret that (for better or worse) is often the key to your internal windows domain and to anything linked into that domain is a really stupid idea. It is the IT equivalent of putting a “Kick Me” sign on your organization’s back. It means that no matter how stringent your own security regime is, you are only as secure as the weakest of the partners you synchronize to. Most partners are loyal and upstanding, employ good people and protect your passwords better than you do, but even then, if/when you get hacked, who are you going to point fingers at?
I believe Enterprises should be educating their employees NEVER to set or use an Enterprise password outside of the Enterprise. I also believe that a cloud service is nuts to actually accept passwords synchronized from their customers. Of course it goes without saying that the better choice is to eliminate external passwords altogether, but if you can’t do that, at least try to keep users from typing the same set of credentials into every web form that comes their way, while protecting your partners from even the implication that they might sell your password list.
I am so tardy in writing this, tsk tsk…
I am now officially a Senior Technical Architect at Ping Identity. All of you who know the Ping folks know that this will be an exhilarating ride. I work for Patrick Harding in the Office of the CTO, and I can honestly say that this is one crazy learning curve!
For those of you who aren’t familiar with Ping Identity, they do Internet Identity Security – SSO and token transformation using SAML, WS-Trust, WS-Federation, and whatever else is necessary to get the job done. They also do federated provisioning, which of course is one of my passions. It’s a fun time to join; the current interest (dare I say mania?) around cloud computing is starting to resolve into common-sense questions around potential risk to the Enterprise caused by mis-management of cloud resources – and at least in my mind, I see these questions changing the adoption patterns for technologies like SAML from a early adopters and massive organizations to everyone’s organizations. I’m also very excited to see what the addition of consumer identity protocols like OpenID and oAuth will do to adoption patterns.
From the employment front, it has been fascinating to have insight into the inner workings of a product company – I have always been on the customer side before this, and the change in perception is fascinating. I think it must change some of what I write here – but change is good, I think. The biggest challenge will be finding the time to write — keeping up with these Ping folks is hard work, they are aggressive and agile, and they are focused, holy cow are they focused. Er, we are focused. I am we! Woohoo!!!
Ok. Gotta run. Life at Ping is a sprint, and I’m loving the adrenaline high :)
Axel says he’ll fetch you a beer at IIW if you can decrypt the token he has made publicly available on his blog: crypto doubters in the crowd, this is your big chance! As someone who was recently burned while copying and pasting encrypted tokens off of a web page and trying to decrypt, I would be careful of the white space though, I bet if you ask really nice he’d even send you a file version.
Are you a Canadian member of the identity or access management community? In case you don’t know already, there are a number of new venues evolving to service this community, and I’m really excited to be a part of them!
- The CanadIAM Blog – this blog is dedicated to the Canadian take on Identity and Access Management, thanks to the organizing efforts of Mike Waddingham over at Code Technology. It’s just getting off the ground, but I think it will attract a very strong community — make sure you add it to your blog reader!
- The ICE Conference — this will be the very first Canadian tech conference that I’ve spoken at, I can’t wait to actually meet folks from my own backyard and compare notes and experiences! The conference is in Edmonton on November 2-4, 2009 – the only sad thing is that it happens to conflict with the Internet Identity Workshop; as a result I’ll have to split my time between the two rather than getting the full benefit of either, which is such a shame!
It is great to see these kinds of resources evolving, and I think it speaks to the maturity and growth of I&AM practices in Canadian organizations. I believe that the best way to be successful in many of these ventures is to share – and what better way than to do so than with a group of people who have strong common interests.
Photo credit: http://www.flickr.com/photos/michael40001/1828017204/
I’m tired of yelling and complaining about data breaches. As a result, I think I’m going to change my tune.
Take, for example, Rocky Mountain Bank of Wyoming USA. An employee of the bank emailed sensitive details about 1375 customers to the wrong Gmail user, and now the bank is suing Google to discover who this anonymous user is, in an attempt to try and figure out just who they managed to gift their data to, and whether their gift kept on giving. In the meantime, the Gmail account of a completely innocent bystander has been deactivated by court order.
As I see it, Rocky Mountain Bank is in their own little hell right now – they are being widely ridiculed, they have initiated an expensive legal action that can only partially assuage their fear of exploitation by a third party, they have at least 1375 really pissed off customers, and they have incurred some amount of liability and/or responsibility to those customers should their data be criminally exploited in the future.
You can think of these guys as one more incompetent organization and call them names. Or you can think of it as one more organization whose eyes have been opened to the cost and danger of playing fast and loose with customer privacy. Perhaps we simply have to hit a tipping point where enough people are close enough to enough victims that our societal internal risk meter changes. If you look at it that way, every breach can also be viewed as an education… and I’m a big fan of education.
So congratulations Rocky Mountain Bank on having your eyes opened as a corporation, serving as an example for others, and personally educating 1375 otherwise clueless end users. It is appreciated.
I want to talk about the Sears Holding Company, and I have nothing nice to say.
They encouraged their own Sears and Kmart CUSTOMERS to download a piece of software that seriously compromised privacy, transmitting banking details, unrelated shopping card details, and online prescription orders back to the mothership.
To me, this is worse than an accidental breach. This isn’t about ignorance or stupidity, but about willful intent to do harm. A whole group of people inside this organization decided it was a good idea to write a piece of software that “monitored consumers’ online secure sessions – including sessions on third parties’ Web sites – and collected consumers’ personal information transmitted in those sessions, such as the contents of shopping carts, online bank statements, drug prescription records, video rental records, library borrowing histories, and the sender, recipient, subject, and size for Web-based e-mails” (from the FTC notice). How could this project be designed, written, approved, and then evangelized without anyone raising the ethical issues? How about the lack of respect shown to the very group of people whose privacy the Sears Holding group should have felt beholden to protect? Worse, why *could* it be done? Oh yes, right. We all use operating systems every day that have an egregious lack of granularity in access control.
There is little to do except spit in Sears’ general direction – so I do. Ptooey.
Patrick Petit discusses Information Card support in OpenSSO – note that for those of you wondering about Information Card projects using Java, the OpenSSO project is a prime example.
I wrote not long ago about the HSBC Canada banking site, and its odd and frightening ways of dealing with access control. Their fanciful notions of authentication proved to me that passwords were being stored in a retrievable format rather than in a format where the password can be verified as matching but not retrieved and examined.
This exact same issue has come up on the OSIS list with respect to privatepersonalidentifiers – some have argued that it is perfectly safe to store raw ppid and modulus information at the RP, and I cannot tell you how STRONGLY I disagree with that idea.
Luckily, Gunnar has pointed me to the perfect example: apparently the HSBC France banking site has been hacked, and guess what? They are storing their customer’s passwords in clear text too (surprise surprise). And a handy little SQL injection attack gives the hacker everything he needs to log in as anyone he can think to query for.
Had the HSBC stored their passwords in some kind of encrypted format, the same attack would have netted the hacker a fraction of the value, because there would still be a significant and likely cost-ineffective amount of time and work necessary to turn the data into a set of credentials that could be used for actual authentication. This is why encryption of passwords is an industry best practice, and why you will and should be laughed out of this community if you can’t get such a simple mitigation right.
If an RP stores the ppid and modulus of a self-issued information card in clear text, and that RP becomes the victim of a SQL injection attack, a hacker has everything they need to get in the front door too. The data must be stored in a way that mitigates this danger, period. I consider this to be identity 101 for information cards, and anyone who writes an RP should consider this to be a best practice.
Just in case you all still thought that on the internet, no one knows you’re a dog: Heaven forbid you’re a plain ol’ Canadian dog who wants to experience streaming content now and then… and no, things like Hotspot Shield don’t work, sites like Hulu have been assiduous in their efforts to ensure that I cannot be a customer.
The truth is: yes I am disappointed, and no I don’t understand. I am sure this all about somebody somewhere insisting that I not be served until they get their pound of flesh. I’m willing to PAY for my little part of whatever kickback has to happen – but apparently that isn’t enough. It would seem that profitability can only be found in a scheme that rewards large demographics and denies everyone else. What a shame.