Adventures of an Eternal Optimist

What would you do if your prospective employer asked for passwords to all of your social networking sites?

According to ReadWriteWeb, if you apply to work for the city of Bozeman MT,  you are asked for a list of the domains, usernames and passwords for “any and all current personal or business websites, web pages, or memberships on any Internet-based chat rooms, social clubs or forums, to include but not limited to: Facebook, Google, Yahoo, Youtube.com, MySpace, etc”.

First of all, these people clearly have no depth of understanding of what they are asking for — the fact that they provided only THREE spaces for someone to enter their entire web presence is obviously a travesty of a mockery of a sham.  Most people I know would have to include an excel spreadsheet as an addendum :)

Beyond that, ask yourself what exactly it is that Bozeman’s moral evaluation team could possibly wish to examine in these accounts.  Most of what you put into a social networking site is there for other people to consume.   What have you got in your accounts that you couldn’t share using less intrusive methods?

Asking for Yahoo and Google passwords gives access to a massive amount of information, the richest source being your email.  Think of the juicy things they can mine for: affairs, viagra purchases, subscriptions to pr0n sites…   Facebook accounts could be mined for private messages.  Chat rooms… seems likely that racy-sounding chat room accounts won’t make it onto the application – so how do you evaluate a benign-sounding chat room account?  Log in and see if somebody wants to talk dirty?

And what if you are having an affair? What if you’re in the closet?  What if you are part of an unusual religion?  What if you are pregnant or have an STD?    You should still be qualified for most jobs at the city of Bozeman – but do you really think that knowledge of these facts won’t influence your chances?

If a company asked you those kind of questions in the interview, you could sue. Why on earth should they be able to ask for access to go find the answers themselves?

Photo credit: http://www.flickr.com/photos/nolifebeforecoffee/124659356

Here is a philosophical question for you:

Many SaaS vendors currently only offer SSL support to clients who pay a premium.  Users who don’t pay, can’t have the “extra” benefit of using SSL.   What happens to the small companies and/or single users who wish to be secure, but do not need unlimited users or 2GB of file storage, or 10 project templates?  Who in their right mind would pay $20 extra a month just to get SSL?   And what possible justification is there for denying transport-level security to smaller customers?

Today we have this perception that only the largest corporations need to pursue security:  the ones with CIOs and Enterprise Architects,  the ones trading publicly or in a vertical where audits are mandatory.  If you ask me, I think we could go a very long way if we stopped thinking like this and began to enable any person or organization, of any size to care about, understand, and pursue secure internet operation.

I know it isn’t as lofty a goal as Bob has put forth;  but this issue, to me,  represents a small part of the underlying systemic problem that Bob is trying to shed light on.

We’ve been having a great discussion on the OSIS-general mailing list, and I wanted to save a bookmark to the thread so that I could come back later.

The thread discusses what exactly an RP should use to uniquely identify a card from a managed card provider.  The current methodology that I’ve been using with the PamelaProject RP’s was to take the isuer certificate signerkeymodulus provided in the SAML 1.1 token and the PPID and hash it together to get  a card hash that is pretty tough to replicate without the original inputs.

The problem started when I encountered a managed card that did not explicitly provide a signerkeymodulus in the token.  It turns out that I could still extract the value, but the point was made that by using the signerkeymodulus of a managed card, I guaranteed that on issuer certificate rotation, the card identifier would become invalid, and the user would have to reassociate their card.  Obviously, this is not an optimal solution.

The solution that was recommended was to generate an identifier for the issuer using the same algorithm IdPs use in section 7.6.1 of the IMI specification,  so I will give that a try right away.  I would say that this is the closest thing to a best practice out there for Relying Parties, and I would recommend that any other RP writers out there that they review whatever policy they are using;  if they are depending on signerkeymodulus, there is at least one IdP out there who does not supply the signerkeymodulus as a separate element in the token, so you’ll be having interoperability issues.  If you are storing the PPID directly, I’d also like to strongly discourage you from doing so, I would consider it just as much of a no-no as if you were storing clear-text passwords.

The thread is worth reading, if you get excited about such things ;)  You can also subscribe to the osis-general list here.