DIY Security for the Utterly Paranoid

I talked to several people who were somewhat disturbed about my last blog post.  Surely it can’t be that easy?

The  potential exists – and I think it is worthwhile to ask why.  Most people have been taught to guard their passwords, but have been carefully instructed to feel no responsibility for the other ways in which an attacker could access their account.  Why is it we can educate about password complexity and reuse, but don’t want to explain under what circumstances a “personal identification” answer might be used?   Why is it we will force a user to change their password every three months, but the email address that would be used in case of a password recovery effort is never tested, and security questions are never refreshed or reinforced?   Why is it that we as a culture have recognized the concept of a “fire drill” in the real world, and advise people to understand alternate exit routes in cases where the elevators are out of order, but in the online world, we feel that advising those users who happen to be of the more concerned persuasion to familiarize themselves with and verify the operation of the page behind their “forgot my password” links is a crazy and unthinkable thing to ask?

If you are someone who worries about being hacked, and if you are willing to take a little bit of time and energy to at least understand the risk you might be facing, my advice to you is:  Go forth and recover.

Go ahead.  Recover all of your accounts.  You probably needed to rotate those passwords anyway.  Find those “forgot password” links and click ’em. Chances are, you will be able to reset your password in an automated fashion,  either by answering a pre-specified question, or by getting a link sent to an email account (sometimes, both approaches are combined).    If you are asked a question, is the answer guessable?  Is it searchable?  Is it short? Is it a single dictionary word?   Can you control the guessability of the answer, or is it a hard-coded format such as a postal code or a birthdate?   If you are emailed a link, follow the chain to your email provider and recover your password there too.   Is it more pre-specified questions?  Are they the same questions? Were you required to click on a link sent to yet another email address?  If so, follow the chain again.  Rinse and repeat.  This is the same trail that a hacker would follow – often they find something you’ve forgotten, something out of date, an expired account or a typo that you never would guess could end up in a compromise of your identity.  Password recovery mechanisms were used to compromise Sarah Palin’s email account, and also used to steal corporate data from Twitter.   If you can satisfy yourself that the password recovery loop is closed, that your answers are not guessable, that you haven’t specified incorrect, out-of-date, or non-existent email addresses, and that the services you use don’t use unsafe mechanisms, you will be safer.

Don’t believe me?  Check out the techniques this guy used to compromise the identity of a mere acquaintance.  He gained access to supposedly “secure” accounts whose password recovery mechanisms depended on password recovery mechanism that depended on grossly guessable data.

Should you have to do this?  No.  Not according to almost anyone in this business.  Are you expected to do this?  Of course not.  How many people actually memorize an alternate exit route from every hotel room they ever stay in?  Only the ultra paranoid, I am sure.  Still, if you care, if you are motivated,  and if you want to know what to do, perhaps this can be a starting point.

So funny I forgot to laugh

Have you ever had to enter CHARACTERS from your password to log in?   No?  Me either.  How would you feel if you entered your credit card number into your credit card provider’s website and instead of the usual password you were given this screen:

Yer kidding RIGHT?

This is the second screen of my credit card provider’s authentication workflow.  They are asking me to answer my “Personal Identification Question”, and asking me to type 3 random digits of my password instead of my entire password.  The ramifications of this set of implementation choices just blows my mind.    Three strikes and you’re out, if you ask me:

1. Downright Terrible Personal Identification Questions

Worst Security Questions EVARAnyone who reads my blog can probably figure out my favorite hobby, I even mention it on my about page.  That question was one of five terrible security questions. Three of the questions are standard web access management fare. They aren’t great, but at least the 8-character minimum character limit keeps away answers like “golf”, “ford”, and “rex”.   The other two questions are in my mind criminal however.  No financial institution should give a customer the option to use their mother or father’s name as a method of personal identification.  I can’t believe anyone put those questions into production. The worst part: because of the list given, those two questions are the only ones that can be answered in a straightforward way while also fitting the complexity rules.

2. Removing The Guesswork from Password Hacking

Password Complexity?Then there is the 8-character password. I could have sworn that one of the variables that make a password tough to brute force is the fact that the length is unknown.  If you *know* you’re working with 8 characters, you can seriously narrow down your brute force parameters.  Plus the only punctuation allowed is an underscore.  Ouch.


3. One-way Hashes are *so* 2008

Security TheaterSince my bank is performing character matches on my password, there is no way that they are using a one-way hash algorythm to store my password.   If they were, they would be able to match the whole thing or nothing at all.  Instead, they have chosen to be able to retrieve my password and play with it.  I can only hope that it isn’t stored in clear text, but frankly anyone who asks “What is my mother’s name” as a security question can’t be too worried about security.  Don’t get me wrong,  HSBC is very worried about the appearance of security, in fact I was forced to positively acknowledge a big long page of statements about how firewalls are used, and how they require me to use 128-bit encryption. In spite off all the assurances, it seems to me that I’m at risk in a number of ways now, and all so that the password interface can be turned into a primitive and easily overcome turing test.

So, what am I missing?  Is there some brilliant element to this setup that makes up for the sins that appear to have been committed?  Something that will make me happy my credit is in the hands of this company?  I hope so, because right now I feel like maybe it’s time to do my best ‘rat leaving a sinking ship’ impression.

Catalyst 2009 Ponderings

Catalyst North America 2009 was a fascinating conference – but maybe fascinating to me for different reasons than it might have been fascinating to you.

The logistics summary is short: Burton Group has just plain gotten it right.  Good food, free, reliable internet access even in the room, power for laptops, nice hotel.  They even arranged an airport shuttle discount.  They paid a lot of attention to the cost incurred by their attendees, and it was appreciated.

I’ll tell you the truth.  I’m not going to particularly talk about the content of any given presentation.  After 8 years, a large portion of the content is pretty well ingrained in my head, and while I learn new things every time, each little twist and turn has really become a single data point contributing to an overall set of trends.   I think of the following points as indicators – but you be the judge of the truth of that statement.

1. Presentations fit to take home to Mom

This is literally the first year of all the years I have been attending Catalyst that I have downloaded presentations and recommended them to those that could not attend; that’s how good some of these presentations were.   The speaker notes were critical in being able to pass these presentations on, so thank you to the speakers who took the time to be sure that their presentations were consumable after the fact.

2. Cloud Track

The cloud track presentFrank on the Rocksations I saw this year were fantastic, but I hope that this is the first and last time that  Burton focuses primarily on “Cloud”.  Why?  Because I hope that after this year, everyone will be savvy enough and discerning enough to get past such a broad topic rollup.   A lot of attendees I talked to had been sent to Catalyst with the mission of  “understanding this cloud thing”, and I think that the Burton Group very astutely served the needs of their attendees – but while general education is important,  there were people there who were frustrated because they wanted to talk about actual concrete things that Enterprises might want to do in the cloud.   You can only start with the layered diagram of SaaS, PaaS, IaaS, and SIaaS (Software Infrastructure as a Service, newly defined by the Burton Group) so many times.  Unless you were interested in virtualization, which seemed to be covered very thoroughly, I don’t believe that many of the cloud sessions put a targeted group of people with a common business goal in the same room,  however I also don’t believe that this would have been a realistic goal for this year anyway.

This track is going to be very popular and profitable for Burton Group – it is a great team, producing great content.  I look forward to seeing how it evolves & matures in the next year.

3. Lightning Rounds

(Lightning rounds are a series of extremely short on-stage spots given to vendors who have product announcements to make: 4 minutes & 4 slides, if I recall correctly)Frank at the Hospitality Suites

The lightning rounds started in 2008 and were expanded this year.  I believe they were very well received, in fact I heard people say that they were the best content of the day.  I hope Burton Group thinks long and hard about what that means.   For a very long time, ‘vendor’ has been a dirty word at Catalyst – with the result that attendees can only find out about products through the sanitized views of the analysts or the drunken haze of the hospitality suites.  Granted, the analysts are smart and make great points, but – the danger is that the whole experience becomes homogenized, and no matter how great the quality is,  homogeneity is boring.   Looking at the neat pastel-colored items on the agenda this year, that’s all I could think.  Oh, yet another customer use case.  Oh, a panel.   All fitting into a certain template.

The lightning rounds were refreshingly template-free, but more importantly, they let the attendees make a direct connection with the vendors.  Some vendors did not use their time wisely, some did, but no matter what the attendee could be the direct judge, and in the worst case the suffering was short.  I’d like to see more of that, and I think it benefits everyone, assuming the goal is to create a thriving identity ecosystem.

4.  Where are “The Regulars”

My recollection of the early part of 2000 was that there was a set of non-Burton people who could always be counted on to further the discussion.  Frank and the Booth Babe Burton analysts provided the meal, but ‘the regulars’ provided the spice, both in the blogosphere and on stage.   I haven’t seen very many recurring spots given to regular non-Burton speakers any more, and I think that’s a shame.  I’m not sure if it is because these people have different jobs and focuses, because the space is simply more commodotized and the characters have moved on to more interesting new problems, or because Burton has abandoned the policy – but I think the conference is the poorer for it.   I’d like to see Burton take a chance and try to cultivate a new breed of thought leaders, agitators, and characters in this space, who can grow with the technology and help attendees gain multiple and growing perspectives over time, rather than only hearing from yet another different customer who took on and solved one task one time,  in one context, and who you will never hear from again.

Why are the regulars important?  Because they represent a growing trusted relationship that engages people.  We need those trusted standouts who can transcend vendor allegiances, who can tell the truth not only from a neutral standpoint but also sometimes from a decidedly non-neutral standpoint.  We need people who can bridge gaps and serve as public touchstones for the topics of the day.

I have a list of people I think would excel at this, but it would be much more interesting to see who Burton Attendees would nominate for the job.

By the way,  Frank (shown here) really enjoyed the conference.   Especially the hospitality suites with the icy martini bars… if you were at Catalyst you have probably already met Frank, otherwise you’ll be seeing more of him as I travel around.

Massive Step forward

As of very recently, I have had the pleasure of working on contract for Ping Identity – and I have been dying for today, because I can finally talk about what the combination of PingConnect and Google can accomplish.

Traditionally, the ability to integrate a disparate set of cloud applications for a userbase was predicated on the non-trivial task of first creating a Start of Authority.   As a bare minimum, you had to (a) create an authoritative user repository and (b) enable some kind of service to perform an initial authentication and leverage the resulting session to facilitate federation to various parts of the cloud.  After that, you still had to figure out who could consume what you had worked so hard to be able to establish.

Now, you can make Google your Start of Authority, and instantly get to a laundry list of 60 applications with PingConnect.  All without a Windows domain, a WAM server, or a federation server, and best of all, by utilizing an existing repository that is likely to be maintained regularly.  AND, there is actually useful stuff to get to.   This may not sound like a big deal to the companies who all have Windows domains anyway, but I believe that this could push back the need for a growing small business to get a Windows domain quite significantly.  To me, the start of authority problem was a massive barrier to adoption for federation, and that barrier has been obliterated, not just on the cost front but on the effort front too.  They say it takes a village?  Well now we actually have one worth hanging out in.

Interesting times.

Seriously, Certapay?

Tell me what you think of the following series of events:

  1. I receive an email with a link in it, promising money.
  2. I click on the link and see a screen purporting to be my bank and asking for my username and password.
  3. Not trusting the page to actually be my bank, I go independently to my bank site and authenticate.
  4. Clicking again on the link from my email,   I hope to see that the bank authentication page is gone,  and that I am taken directly to the step where I answer the “security question” and get my money.   Instead, however, I find that even though I have an existing valid bank session set up in my browser,  I am still taken to a login page and forced to re-enter my credentials before the transaction will work.

I know what you’re saying! Don’t do it! It’s a phishing attack!   Sadly, this is actually what happens if you are the recipient of a Certapay INTERAC email money transfer in Canada.   It is a phisher’s wildest dream come true, don’t you think?  Even those familiar with the process will eventually stop looking at URLs and just click through the brightly colored screens to enter their banking credentials.

The whole setup is ripe for abuse.  Why, dear god, is there no way to accept a payment without typing in your banking credentials?  There certainly needs to be an authorization step, but forcing an authentication step to be bundled is both lazy and dangerous.  The worst part is that the banks are complicit in this.

The best irony of all is the email fraud section of their website security page, under the “How to Protect yourself” section says:

  • Do not share or provide your personal information.

Oh, you mean like my usernames and passwords for my entire BANK ACCOUNT????

jeez.

Step 1

Picture 61

Guidance

In researching a few products for a client, I came across an e-book on Managing Linux & UNIX Servers by Dustin Peryear.  I managed to get access to a chapter without registering, and I liked what I saw so much that I had to have the whole book.
The thing that is remarkable about this book to me, is that it is NOT a book about technology, commands, program execution or coding.  It is a book about what to get done and why.   There are so few of these kinds of books – the ones that assume that once you have a comprehensive plan for getting things done,  finding out how is the easy part.  The books that get that the mapping works better from the top down than the bottom up: all the man pages in the world will not help you if you don’t have the context to know which of them you should be reading, and what the end result should be when you apply that knowledge.  It is the guidance that makes the difference.

GuidanceI very badly want a book like this for information card Relying Parties, specifically the PKI functionality of an RP.   I have work to do on my RP:  right now I know I’m missing several critical checks to ensure integrity and non-repudiation for the messages I’m accepting and trusting.   But how do I know that I have covered all the bases?   I have this list of interoperability issues.  I have a set of api calls into security libraries like xmlseclib and openssl that could possibly solve my issues.    What I do not have is guidance.   I feel like I’m assembling an entertainment unit from IKEA, and I have detailed engineering information on every screw and every panel in the entire IKEA inventory:  thousands of weights, heights, screw thread pitches, you name it.  While I technically have access to everything I could possibly need to assemble my entertainment unit,  it is left up to me to figure out which and how many of the inventory items I need, how they fit together, and what order they must be assembled.

I suppose what I’m saying is we need to step above RTFM (Read the Fsking Manual) to KWFMTR (Know Which Fsking Manuals to Read).

(photo credit: http://www.flickr.com/photos/jonk/33283987/)

Give it up for Bozeman

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”.

What are you looking at?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

Security as Upsell

Here is a philosophical question for you:

SSL only for the privileged

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.

Relying Party Card Identifiers

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.

Am I an Accessory?

I am stuck in an interesting dilemma.

I love my web hosting company, I think the people are great, the tools and support are top notch, and the price is right.  I was, in fact, thinking of upgrading my service with them.

But I cannot ignore the fact that on my particular server, they haven’t updated their openssl libraries in 5 YEARS.   Five.  By my count, they are 20 revisions behind the current library version.

This means that there is a list of exploits as long as my arm that can probably be used against the various sites that I sponsor, including the Pamela Project and OSIS. The big problem is that I’m using a shared Apache infrastructure, and while I can recompile PHP and Curl to use up-to-date libraries, Apache does a lot of the heavy lifting when it comes to transport-level security, and as far as I know, I cannot affect the modules that load into that shared webserver environment.

Obviously there are actions that I can take to ensure my own security.  I can change web hosters.  I can upgrade to a server where I have access to my own apache configuration.  The standard answer here is that if I don’t like what I’ve got I should leave.

But – what about the folks on my server who don’t even know they are at risk?  Who are running shopping carts and who just assume that they are on a well-patched, secure server?  By silently walking away from an insecure environment, am I in fact aiding and abetting the web hosting company in their terrible security practices?

I have in the past contacted support about updating SSL libraries when various remote holes were found.  I won’t quote their answer because I don’t have the email to back up my recollection, I didn’t think to save them, but the version number speaks for itself:  0.9.7e.  The current version is 0.9.8k.  I’m not a big customer, and I know that by paying more I could become more secure — but must it follow that by paying less I have to be at risk?   I already pay extra per month for SSL support, and also for the unique IP address that is a pre-requisite.  Do I have to get hacked before I have a case?

So I ask you all — for the small number of us who know better — what’s the right way to proceed?  Do I silently act to ensure that I myself am secure, leaving all those other poor uneducated suckers to continue in ignorance and risk?  Do I make a stink?  I doubt I have the clout to cause this very large company to do anything.  Yet, if I don’t, who will?

Update: I received a response to my separately sent inquiry to the security team just now (told you they are responsive):

We run Debian Linux. Debian does not put new upstream releases, even point releases, into a stable distribution. What happens is that only the security fixes are backported into a package in stable. This minimizes the possibility for the stable release to be de-stabilized by new code introduced upstream.
So while the version of libssl0.9.7-sarge5, it should nevertheless incorporate all the security fixes present in 0.9.8k.

So, the good news is that I’m probably safe, and the team is on top of it.  The bad new is that I simply have to trust it is so, I don’t see a way to easily independently verify.