Archive for category Computer Security

Wow, I’m behind. It was a busy year, and not a lot going on that I could really talk about publicly.

The recent meltdown and spectre bugs have brought back some memories from Orange Book days. I’ve also been spending a lot of time thinking about “IT transformation” and non-technical stuff. I’ve also been to the UK and Japan, twice, each, which may become the “new normal”.

I got my start in computer security from the personal privacy side of the equation. Revelations over the past year have made me realize that I have become complacent, and it is time to upgrade some aspects of my personal digital privacy.

My first “paper” on security was an essay that warned that “someday, the government and large corporations will be able to search and manipulate hundred of millions of bytes of information, giving them improper leverage over individuals, who won’t have the same access to computing power or storage”. I got a B. My high school English teacher said the writing was very good, but she couldn’t accept the premise 😦 That was in the late 1970’s.

I’ve had, but rarely used PGP/GPG keys for email since the early 1990’s. I have friends who probably encrypt about 10-25% of their email, and sign almost 100%. Others encrypt and sign more, or less. Some are more consistent about this, some less. I felt that this wasn’t necessary for me, as I was a small enough needle in a large enough haystack, that “computational privacy” probably wasn’t needed in my particular case.

I’ve run my own email servers on my own hardware, off and on, for years. I’ve done the same for personal web servers, photo galleries, and other personal storage. Over the past few years, I’ve made much more use of hosted services, like Gmail, and WordPress.com (for this blog) instead of building, maintaining and securing them myself on my own hardware under my own physical control. I’m going to have to re-think some of those decisions, I guess.

The Snowden revelations, coupled with high-profile cases of seizures of data and equipment from hosting providers, and the inability of those service providers to stand against the abuse of certain government powers has led me to believe that it’s time to step things up a bit.

I want to upgrade my personal privacy stance over the next few months. I’m going to have to re-learn lots of the details of encryption, look at products that didn’t exist a few years ago, look into newer encryption algorithms and key search technologies. I expect I’ll need to make changes in the way I use email and the web and in general communicate. There are a lot of good resources out there; I’ll share what I find.

I don’t plan to wear a tinfoil hat, become a crypto-anarchist, bury guns and ammunition in the desert, or buy gold. This isn’t going to be a knee-jerk reaction, just some slow steady Kaizen to improve my digital privacy.

There, I said it. The so-called “IPv6 transition strategies” are making it harder, more complicated and less secure to deploy IPv6 than just “doing the right thing”.

Carrier Grade NAT (CGN) and Teredo (among others) are the last gasps of an IPv4 world, and have no place in the modern Internet. While they may have short-term advantages to network operators, they will cause problems for their end users until they are finally phased out. Dual stack would be a better transition process, especially for customers.

CGN is, as much as anything else, a way for carriers with a large network or large installed base of end users to make the fewest (and hopefully least expensive) changes in their networks. They are betting that by introducing a small number of large-scale NAT devices on the border between their networks and the Internet that they can avoid making sweeping internal network changes, or upgrading CPE (Customer Premise Equipment).

CGN is inherently selfish on the part of the network operators that deploy it. They are saying “I want to spend less money, so I’m going to force everyone else to make changes or suffer in order to continue to talk to my customers.”

Almost all of the advantages of the second approach [transition to CGN and avoid investing in IPv6 deployment] are immediate and accrue to the benefit of the provider, while almost all of the immediate drawbacks impact the subscriber.

The next part of my rant has to do with Teredo, a “last resort transition technology”.

Like CGN, Teredo promises to allow end-user equipment to connect to the public IPv6 Internet over IPv4. It does this by “invisibly” tunneling your IPv6 traffic over the public Internet, to a “Teredo gateway”. A Teredo gateway performs a 4to6 network translation and passes your traffic onto the desired IPv6 destination. Teredo is implemented transparently in some Microsoft operating systems and can by default provide an IPv4 tunnel to the outside world for your IPv6 traffic. It can, also provide an “invisible” tunnel from the outside world back into the heart of your network. And of course, all your network traffic could be intercepted at the Teredo gateway.

You can now add LinkedIn, eHarmony and last.fm to the long list of major sites that have had poor password security in their user database designs. The saddest part is that in the case of LinkedIn, at least, this was apparently completely avoidable. (I haven’t found enough details to comment on the others, yet.)

Protecting stored user passwords is not rocket science. This problem was pretty much solved in the 80s and 90s: Use a salted one-way hash function of sufficient strength to resist a dictionaryattack.

That’s it. Really. UNIX has been using a salted hash since about 1985, initially with a hash based on DES. Since that time, as computing speeds have increased, new (salted) hash functions based on MD5, Blowfish, and SHA-2 have all been introduced.

In other words, stored password security has been a solved problem for at least 25 years. The concept is the same, only the algorithms have needed to be updated as Moore’s Law has dictated.

This is just one reason that programmers (and sysadmins) should study history, if only the history of computer security. Oh, if you’re not a cryptologist, for security-critical functions, please use well-vetted libraryfunctions.