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.

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.

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.