May 25

Bye bye, eBay

Yesterday I started the process of deleting my eBay account.  “Why, isn’t that a knee-jerk reaction?” some are probably asking.  I’d thought I’d put my thoughts in a blog…

The IT industry isn’t making a lot of strides in the way of security lately.  All the existing recommended practices aren’t new, they’re been around a few years.  I’m not talking about using the most secure encryption algorithm or use TLS where appropriate—most of those things come “out of the box” and you have to try really hard to circumvent them in your own deployments.  No, I’m talking about basic secure design.

This is 2014, there is no good reason (barring basic design flaws in specific implementations of SSL/TLS) for a particular web site to announce to the public that they should change their passwords because of a security breach.  Why?  Because there’s no reason for that site to even store passwords—there should be no passwords to be breached at all, full stop!

Identity theft isn’t something new either.  With a site devoted to e-commerce, it’s got a *huge* target it on its back for personal information that unseemly people can use for identity theft.  It appears *nothing* but out-of-the-box security was used to protect user information above and beyond passwords.  i.e. it was protected *by accident*–by SSL/TLS and firewall.

How did it happen? Employee login credentials.  I assume that means that only a password is required to get into one of the world’s largest ecommerce sites to get at encrypted and unencrypted personal information of 145 million users and that only one or a handful of employees has access to 145 million in-production data.

Sites being hacked is in the news, constantly!  I’m not asking eBay to try to tell the future or to try to fix problems that don’t exist!  It’s just a matter of reading the news, and making an educated guess that one of the largest web sites in the world will have hacking attempts.  I’m sure they’re have been many, many attempts in the past, just that this attempt succeeded at getting vital information.  I’m also not asking eBay to stay up-to-the-minute changing their design to suit every new security design practice (like two-factor).  I’m only expected *basic* security practices  They *failed*, miserably.

I don’t use eBay enough to warrant risking my personal information on a site, so large, and with such a huge revenue to *not* perform basic security design and/or review.

I would say that similar things should happen as with Target.  The CEO is ultimately responsible and has failed eBay’s customers and stockholders.

Plus, it was 5 (FIVE) days and not one single email from eBay telling me of the problem.  I have to read it, over and over, in the news.  eBay is sure quick to send me an email when it changes its user policy (i.e. reduces what it’s liable for or increases my responsibility), is privacy police (i.e. reduces privacy), and selling agreements.  So, I know damn well they know my email and know how to send me an email.  *Plus* they were pretty damn quick to send me an email both about me first resetting my password but as well as the account closure request.

The folks at eBay dropped the ball, in so many different ways—no one could argue otherwise.  I’m getting my personal information off of eBay to mitigate future risk and moving on to other services.  If that means I can’t buy an eBay as well—too bad.

Apr 18

Heartbleed: Caveat Emptor

The news sounds relatively good about Heartbleed: the problem is known, a patch as been made to OpenSSL and that’s being applied in many places.

So, emails are rolling out from affected sites saying “change your password”.  But, you should be leery, and here’s why:

Was the site patched!?

I have seen too many emails that don’t point out that they’ve actually patched the problem on their site!  The downshot of that is that changing a password is going to be done over TLS (https) and require username/password information over that “encrypted” pipe.  If they haven’t patched their site, you’re guaranteeing you’re putting your account on that site at risk!  You may not have entered a password on that site since the heartbleed bug was created (or before it was known and exploitable) and may not have been at risk before now.  Changing your password on an unpatched site guarantees you’ll be at risk!

Have your admins been compromised!?

Admins of a site go through the same https security as the rest of us—who’s to say they haven’t been compromised?  Given the previous section, if they have been compromised (and a patch hasn’t been installed yet) then it would seem (from a bad-guy’s point of view) that sending out an email to change passwords is an excellent idea to get *more* passwords!

Caveat Emptor

Beware! You can’t *really* trust some email you get.  Make sure that you use one or more trusted ways of detecting heartbleed (or lack thereof) before you change your password!

All the security pundits saying rush out and change your password isn’t really helping either.

Apr 17

SSL is not the basis of mission critical security

I was a amused by a naïve post about “heartbleed” the other day and I’d thought I’d get my thoughts out via a blog post.  The post in question:


SSL was created by Netscape in the 1990’s and has had problems basically from the start.  It had “security flaws” up to version 3.0.  Each subsequent version of SSL (or “TLS” after version 3.0 of SSL) strengthened security and thus prior versions we viewed as “weaker” in security.  In fact, TLS was defined to *never* down-negotiate to SSL v2.0 due to v2.0 not having a “sufficiently high level of security” back in 2011.

I’ll refer to SSL as “TLS” from here on in, as that’s effectively the contemporary implementation.

While TLS is transport-layer security (which means it can secure most application-level protocols) it is designed to be and primarily used when browsing the web.  It was designed to always authenticated servers (web sites) and optionally authenticate clients.  What this means is there’s a certain degree of anonymity involved in TLS communications.  In the majority of usages, TLS does not authenticate the client.  Think, for example, when you log into your bank via the browser.  Your browser “authenticates” that you’re talking to your bank (or really just authenticates that you’re talking to the URL you’ve asked to communicate with) by use of a certificate issues by a third-party “authority”.  The user delegates to these third party authorities (and really delegates to the browser manufacturer to “accept” these third party authorities to issue certificates).  So, for a particular web site to be “authenticated” the browser must know about the certificate authority, accept its certificate (a root certificate) and that that certificate not be revoked or expired, in addition to the server’s certificate not being revoked or expired.

Mission-critical security

Let’s be clear, securing a browser connection to a web site is not “mission-critical”.  If that’s how your mission critical system is architected, you’ve got other problems.

If you *are* talking mission-critical security, do you really think you’d delegate *that* much to random third parties?  Sure, you could use TLS in such a way as to enforce authentication of both the server and the client, *and* mandate that only certain certificates are acceptable or certain authorities are acceptable.  You can even self-sign the certificates and circumvent the whole authority process (and you better be *really* sure you’re adding value to those self-signed certificates–which means having *at least* the same level of security of your private certs as do the Authorities).  There’s other things you can control too. But why?  Why would you circumvent a particular protocol to that degree and still use it for “mission critical” security?

Short answer is: you wouldn’t.  You shouldn’t and you wouldn’t.  I’m not saying don’t use whatever security library you want (this isn’t a question that TLS is not secure just because it was implemented in the open like OpenSSL) I’m saying you should pick the most secure protocol for your circumstances.  If you have a policy to authenticate both the client and the server, a protocol that allows unauthenticated clients isn’t the best protocol.  A protocol that relinquishes some level of control (or policy) to third parties to authenticate the nodes on your distributed system isn’t the best idea for mission-critical security either.  Leaving a protocol up to a standards body to update with the latest and greatest encryption currently-accepted practices isn’t the best idea for mission-critical security either.

TLS is used *all across the internet*.  Rolling-your-own authentication protocols and authorization and encryption is simply stupid, but TLS is a huge attack surface.

TLS is also *transport layer* security.  Which means it only “secures” data from point A to point B (and only authenticates Point A and Point B–or sometimes Point A).  In mission critical systems having data only going from point A to point B is not scalable.  Mission-critical systems need to scale.  Which likely means TLS is securing data only up to point A, and only beyond point B (or at least those are the only places you really have control).  This often means mission critical systems should be applying security policy at the application level–not the transport level.

Below the application level, application needs and requires cannot be know.  If an application has security policy over and above any given transport layer security, you can’t expect that to be known at the transport layer (you’d stop having lower-level layers and thus stop having layers altogether if that were the case).  Mission-critical systems generally have fairly distinct security requirements.  Data security often involves many levels of authentication and authorization.  The only authorization TLS performs is that of authentication–one or both sides need to be authenticated to authorize *all access* to the data.

There’s nothing wrong with application-level security *and then* communicating that over TLS–but you’re not likely to leave all of your mission-critical data security up to *just* TLS.

TL;DR: SSL is not intended for mission-critical systems and shouldn’t be considered for mission critical systems.  Ergo hyperbole about heartbleed being the least of our problems and that we need to “fundamentally rethink how the security of mission-critical software” is just that: hyperbole.