Archive for January, 2011

Secret for a long happy life

Monday, January 24th, 2011

A bald, wizened little man was rocking in a chair on his porch, smiling happily. A passerby, charmed by his smile, came up to him and said, “I couldn’t help noticing how happy you look. What’s your secret for a long happy life?”

“I smoke three packs of cigarettes a day,” he said with a toothless grin. “I drink a case of whiskey a week, eat fast food, and never exercise.”

“No way! How old are you?”

via Mikey’s Funnies…daily Christian humor email list

Do Not Destroy. Urgent Documents Enclosed.

Sunday, January 23rd, 2011

 Do Not Destroy




Yes, this is petty,  but it grabbed my ire today and shook it.

By no stretch of anyone’s imagination is a sale flyer from Dish Networks URGENT.  It strains our language to call this “DOCUMENTS”


Dear Postmaster.  Please do not destroy this letter, as I assume you do to those not otherwise marked.

Security Questions Strike Again

Wednesday, January 19th, 2011

I can’t seem to wrap up this security jag.  Stuff keeps happening.

This article highlights again why secret questions are a bad idea.

In a cautionary tale for users of social-networking sites, a California man has admitted using personal information he gleaned from Facebook to hack into women’s e-mail accounts, then send nude pictures of them to everyone in their address book.

Prosecutors said Bronk would scan women’s Facebook accounts looking for those who posted their e-mail addresses. He would then study their Facebook postings to learn the answers to common security questions like their favorite color or father’s middle name.He contacted the women’s e-mail providers and used the information to gain control of their accounts. He also often gained control of their Facebook accounts by hijacking their passwords…

There are at least three lessons here (if you find this alarming)

  • Don’t share passwords across accounts (Bronk stole email passwords and used them to hijack Facebook accounts)
  • Don’t give real answers to the security questions. (Bronk used the security questions to get email account passwords)

and finally,

  •  Don’t store compromising pictures of yourself on a web mail server. (duh)

On Nuclear Reactors and Banks

Sunday, January 16th, 2011

Putting Nuclear Reactors and Banks into the same sentence seems odd to most people, but Tim Hartford points out in What we can learn from a nuclear reactor that there are some important similarities.  Both are complex and tightly coupled systems.  There are similarities in their failure modes and safeguard systems — and there are similarities in the way the safeguards can fail us and cause further harm.

It might seem obvious that the way to make a complex system safer is to install some safety measures. Engineers have long known that life is not so simple. In 1638, Galileo described an early example of unintended consequences in engineering. Masons would store stone columns horizontally, lifted off the soil by two piles of stone. The columns often cracked in the middle under their own weight. The “solution” – a third pile of stone in the centre – didn’t help. The two end supports would often settle a little, and the column, balanced like a see-saw on the central pile, would then snap as the ends sagged.

Galileo had found a simple example of a profound point: a new safety measure or reinforcement often introduces unexpected ways for things to go wrong. This was true at Three Mile Island. It was also true during the horrific accident on the Piper Alpha oil and gas platform in 1988, which was aggravated by a safety device designed to prevent vast seawater pumps from starting automatically and killing the rig’s divers. The death toll was 167.

In 1966, at the Fermi nuclear reactor near Detroit, a partial meltdown put the lives of 65,000 people at risk. Several weeks after the plant was shut down, the reactor vessel had cooled enough to identify the culprit: a zirconium filter the size of a crushed beer can, which had been dislodged by a surge of coolant in the reactor core and then blocked the circulation of the coolant. The filter had been installed at the last moment for safety reasons, at the express request of the Nuclear Regulatory Commission.

The problem in all of these cases is that the safety system introduced what an engineer would call a new “failure mode” – in other words, a new way for things to go wrong. And that was precisely the problem in the financial crisis.

“… a new safety measure or reinforcement often introduces unexpected ways for things to go wrong”

We the people do not understand this principle.  We the people demand that something be done.  But often that something just makes the system more complex while introducing new modes of failure.


Another Gawker bug: handling non-ASCII characters in passwords

Monday, January 10th, 2011

Last week I dumped a bunch of information about the sorry state of passwords and the internet, mostly from Light Blue Touchpaper.  As usual, I soon ran across more information that should be included.  It turns out that Gawker had another problem.  Why should we think they are alone?

Read on if you’re interested.

Light Blue Touchpaper » Blog Archive » Another Gawker bug: handling non-ASCII characters in passwords
A few weeks ago I detailed how Gawker lost a million of their users’ passwords. Soon after this I found an interesting vulnerability in Gawker’s password deployment involving the handling of non-ASCII characters. Specifically, they didn’t handle them at all until two weeks ago, instead they were mapping all non-ASCII characters to the ASCII ‘?’ prior to hashing them. This not only greatly limited the theoretical space of passwords, but meant that passwords consisting of any n non-ASCII characters were equivalent to ‘?’^n. Native Georgian or Korean speakers with passwords like ‘రహస్య సంకేత పదం’ or ‘비밀번호’ were vulnerable to an attacker simply guessing a string of question marks. An attacker may in fact know in advance that some users are from non-Latin countries (for example by looking at their email addresses) potentially making this more easily exploitable.

We users-of-ascii-english have it easy — and hard in a way.   I have had to deal with related issues in recent years, primarily because C/C++ does not account for non-ascii characters for sorting unless you take special steps.  That causes ordering and uniqueness issues as soon as you run into data with accented characters.

VMware Cloud Jumper

Saturday, January 8th, 2011

This is an interesting marketing technique.

“Join the growing elite of IT leaders known as ‘Cloud Jumpers’ who have taken the leap and begun their journey to Cloud Computing. ”

It’s a short but respectable game from my very own VMware.  Give it a try.


Tying up loose ends

Thursday, January 6th, 2011

Make sure you have some time before you start Loops of Zen

Just rotate the shapes until there are no loose ends.  A little graph theory goes a long way.

It starts like this:


and continues thus (if you’re good or stubborn):


Looks like it saves your progress so you can continue where you left off.

Go on.  Try it.

Year End Link Clearance – Password Edition

Sunday, January 2nd, 2011

I’m not good at letting go.  If I were doing this right,  I’d just list the links and be done with it.  But no, I have to blather about each one, because I found each of these interesting and worth saving saving to comment on for some reason.

Light Blue Touchpaper is a fairly technical blog focusing on security (“Security Research, Computer Laboratory, University of Cambridge”).  A certain subset of my readers will find the archives interesting.  Their recent series on passwords forms the backbone of this post.

Bottom line: many websites store passwords.  Most are doing it wrong.

…but we believe ours was the first large study into how Internet sites actually implement them. We studied 150 sites, including the most visited overall sites plus a random sample of mid-level sites. We signed up for free accounts with each site, and using a mixture of scripting and patience, captured all visible aspects of password deployment, from enrolment and login to reset and attacks.

They link to this paper exploring the economic reasons why users may be wise to ignore security advice.  (it probably says something about you if you find it as interesting as I did.)

Exploring the factors which lead to better security confirms the basic tenets of security economics: sites with more at stake tend to do better. However, doing better isn’t enough. Given users’ well-documented tendency to re-use passwords, the varying levels of security may represent a serious market failure which is undermining the security of password-based authentication.

Even the big boys often get it wrong.  The greatest sinner I’ve seen is (or perhaps was) Charles Schwab.  Due to an unhappy serendipity, I discovered that my password was not only inexcusably short, but also case insensitive.  If my calculations are correct, this reduces the size of the password space by a factor of 67,108,864.  I also wonder about Fidelity.  When I call them, they want me to key in my “pin” on the phone.  This is supposed to be the same as the “password” I use online.  If that really works, then my complex online password is mapped to a much simpler one on the phone.  If not, then they expect me to use a numeric password online.  Both cases are security flaws.

It’s long been said in the security community that password re-use is dangerous because it enables attackers to compromise an account at a low-security site and gain access to a higher-security one. This is increasingly true as most websites today use email addresses as identifiers (87% in our study), meaning an email/password combination can unlock many online accounts. The RockYou hacker indicated that 10% of the email/password combinations registered at RockYou were also PayPal accounts (external compromise isn’t the only threat here: a malicious insider could certainly try to profit from a database at sites like this).

News websites may have very little to lose through poor password security, but they can undermine the efforts made by other sites.

“Gawker” was recently hacked, and their user/password database was used to hack into millions of accounts on other sites such as twitter.  Light Blue Touchpaper and CodingHorror both have good analyses.

For security purposes, it would be better to use some kind of central identity protocol (an Internet Driver’s License).

Currently, the trendiest proposed solution is to use federated identity protocols to greatly reduce the number of websites which must collect passwords (as we’ve argued would be a very positive step). Much focus has been given to OpenID, yet it is still struggling to gain widespread adoption.

Unfortunately, security is not the primary goal for many sites. (my emphasis)

Why do small websites, particularly news websites, still collect their own passwords instead of relying on a federated identity provider?Considering newspaper websites as the prime example of password deployments with questionable utility, we found that they were significantly more likely than other websites to collect marketing data at the time of password collection. They also nearly universally, with only a single exception, insist on verifying the validity of a user’s email address as a pre-requisite for an account (this was equally true at sites which also require CAPTCHAs, so we don’t think false account prevention is the primary reason). At this point, users may be trained to accept the idea of inputting personal data along with a password. A password input field may serve as a ceremonial cue that entering personal data into a form is safe (verifying this with behavioural experiments is an important future research question).

Thus, collecting passwords provides cover for collecting personal data, which provides tangible benefits to a site operator. The costs of password collection, however, aren’t primarily borne by the server. As discussed Wednesday, the costs of insecurity are largely borne by higher-security websites. The usability costs, in contrast are borne by users themselves.

OpenID may be being held back by market forces. For users, removing the requirement of registering personal information with the site is an advantage, but for many websites, removing the ability to collect personal data eliminates a major justification for deploying passwords at all.

Sometimes, the programmers are not at fault.  Management or Marketing is.  They insist that information be collected for all users, and don’t seem to care that 80% of their users are named “Barney Rubble.” (That comes from a blog entry I cannot find – fill me in if you know who wrote it first.) This requirement comes at a cost.  If you require registration to participate on your site, users will leave.  If you require personal information, users will leave or lie.

I have an example.  I like to listen to MP3 books in my 2008 RAV4.  I have found that the CD player cuts off the last couple seconds of each track.  Some audio books have track breaks every minute for my convenience – and these are unusable in the car.  I spent way too long searching online for a solution, and found exactly one match at

The OEM MP3 player on my 2008 Toyota RAV4 cuts off the last few seconds of each MP3 file.I have started burning MP3 files onto CDs to play on the CD/MP3 player in my 2008 RAV4 Limited (JBL sound system).

The last few seconds of every MP3 file are cut off abruptly, although when I use the CD on my computer the files are fine, so the problem is not with the CD.

I cannot find anything about this issue in the Owner’s Manual or on the internet, and nobody at the Toyota dealership knows anything about this. Does anyone know why this is happening and how I can correct it?

It’s an exact match, so I thought I’d add a “me too” comment with some additional information.  Edmunds requires me to create a registration.  I don’t want an account on, so I just left.  Not worth the trouble, no thanks edmunds.

If you happen to have a solution, or a way to add 2 seconds of padding to an MP3/WMA file, please comment.

Head vs. Gut

Saturday, January 1st, 2011

A ball and bat together cost $1.10.  The bat costs $1.00 more than the ball.

How much does the ball cost?