Unsavory Passwords

I was at the OpenStack Developer Summit in San Antonio last week. One of the sessions I participated in was a proposal for a design for authorization modules. I found the the session both enlightening and troubling, for a number of reasons. Here is just one.

The proposed reference implementation would mandate "HTTP Basic Auth" (which itself made me facepalm), and it would store the credentials in a text file at /etc/openstack/users.ini that looks like this:

  alice:c8fed00eb2e87f1cee8e90ebbe870c190ac3848c
  bob:fc683cd9ed1990ca2ea10b84e5e6fba048c24929
  charlie:c4f9375f9834b4e7f0a528cc65c055702bf5f24a
  dave:3c287b08e11e55d1e90ef4e1f152f144bdcdc393

e.g. it stores the unsalted hash of a password.

<headdesk/ >

I tried to interject just how bad an idea this was, but could tell I was not communicating my concern well enough, and so just pointed out it was a bad idea, heard but did not believe the response that "it's just the reference implementation, sites can implement better if they want to", and I let the discussion continue.

Cue next the announcement a few days ago from Amazon Web Services. There is a new AWS EC2 instance type. It provides a teraFLOPS of GPU computation. Right now, anyone can spin up a cluster of these, and run just under 30 quadrillion FLOP in an hour, for USD16.80. I have been known to spend more for a pot of tea.

The obvious next step immediately happened. Someone used off the shelf software to bruteforce break every text password of length 6 or less in less than an hour. link

I have already started whiteboarding together a space/speed AWS service that uses GPU instances to compute hashes, and then uses S3 to both store and to look up results. Submit a hashed password to the service, and it looks it up in S3 and returns the password, while at the same time independent GPU instances are grinding thru various bruteforce password templates, and populating S3 with the results. I could even easily make it a paid service.

In short, the proposed reference implementation might just as well store credentials like this:

  alice:password
  bob:secret
  charlie:123456
  dave:qwerty

This way will be much more honest and apparent about the safety of that credential file, and it could require, not HTTP Basic Auth, but HTTP Digest Auth, which is also nearly universally implemented in HTTP libraries such as cURL, and so is just as available for both command line level testing, and writing interoperable modules.

What I fear will happen now is that this will get accepted as the reference implementation, implemented, included as the default install, and we all will have just created Yet Another soft underbelly of not-really- security in our public infrastructure.

TaxiMagic, a user report

I saw TaxiMagic presented by Aimee Cardwell at Ignite Seattle last June, and set up an account soon after. But I did not try it until last week.

I normally start my business trips with a cab ride to the airport. All the rest of my travel planning and reservations are via the net, so actually making a voice call to a dispatcher feels out of place. Taxi Magic promises to take the process of using a cab into the early 21C.


Actually setting up my account, and then setting it up on my phone was needlessly complicated. I did it a few months ago, and so I hope they have streamlined the process.

They don't work in every city, or with every cab company.

They do work in Seattle, but instead of working with Yellow Cab (which is everywhere in Seattle, and often loiters in my neighborhood, so often I will have a cab at my door in under 5 minutes), they work with Orange Cab, so it took longer for the cab, once dispatched, to reach me.

Actually setting up my account, and then setting it up on my phone was needlessly complicated. I did it a few months ago, and so I hope they have streamlined the process.

The Android app needs some work. It has a "map mode", that is supposed to show where the taxi is. But it kept zooming out to also display the start and destination points, even when I didn't want it to. Minor annoyance. Also, occationally it would time out on the server side, and ask me to "try again". This something that needs fixing, both needing a better protocol, and better scaling.

After I first requested a cab, it took about 10 minutes to update the status to "taxi dispatched". That was long enough to make me start wondering if it was working at all. They need to get better at immediate user feedback, and also fix that delay in finding and dispatching a cab.

It took maybe half an hour for the cab to get to me. That isn't really their fault. I got used to Seattle Yellow Cab, which loiters in my neighborhood, so I would often get picked up in less than 5 minutes.

Here is where TaxiMagic is awesome, and why I will keep using it. Paying for a cab is a pain. They are the only handwritten credit card receipts I end up with when doing expenses, and the receipts are never complete, and are hard to read, and the process slows down getting out of the cab at the destination.

With TaxiMagic, when I got to the airport, I pressed a button on the app, and the bill was paid. Period. And a nice clear receipt got emailed to me as a PDF. That itself is worth the whole thing for me.

I hope they iron out those wrinkles, get into all the cities, get all the "computer dispatched" cab companies to get with the program.

And as it is now for me, Seattle Yellow Cab doesn't get my business any more, Seattle Orange Cab does, just because of Taxi Magic.

Tech Press, fail

For a while, I monitored the tech press about Gear6's closure, and was darkly amused by it. All of the tech press and reporters that wrote about it were obviously cribbing from each other's texts, and they talked about Gear's "vanishing" and the lack of forthcoming information.

All of Gear6's customers had been told about it, and had had their support contracts transitioned. It seems that none of the tech press ever contacted any of them.

I was a "known face" of the company to the tech press. I had been on PR conference calls, had been interviewed, and had swapped emails. And yet, none of them ever contacted me to ask what had happened.

It was apparently easier to bang out yet another "me too" story about the "lack of forthcoming information" than it was for them to google their own past articles, pick out mine or anyone else's contact information, and write an email asking for information.

Anything that is not properly masticated and then pushed into the proper input hoppers, of a press release or a controlled interview, is called a "lack of forthcoming information". There seems to be a difficulty is seeing what isn't there, and a near complete lack of energized and directed curiosity brought to bear on illuminating discovered ignorance.

If I needed any more proof (which I didn't) that the tech press does very little "journalism" and nothing at all like any sort of "investigative journalism", that was it.

The job of digesting turgid hyperbole press releases and emitting CIO-friendly 4 column inch "articles" might as well go the way of the sovietologist or soothsayer.

Instead, let people and organizations just cleanly and conversationally write about what they are doing, and interested people go read it themselves.

This is not to say there is not a job for a "press". Some press-like things that do need doing are digging up and making known the things that powerful entities are NOT saying (muckraking), organizing the sea of information into learnable chunks (education), discovering and highlighting interesting stuff (curation), and generating informed prognostication (futurism).

And those things are being done, more or less (sometimes too much less). Often by skilled amateurs.

But almost none of it is being done by the most of what is currently the "tech press".

New Job, Community Manager for Eucalyptus Systems

Six months ago, right around the O'Reilly MySQL Conference, my previous employer, Gear6, suffered from "unfortunate cash flow event". That is, they ran out of money faster than their sales grew. Which is too bad, it was a good company with good and useful products, and it was staffed with good people. I appreciate the honest and ethical dealings of the board and the executive staff, who kept the we the staff "in the light" as the situation developed, and did things like paying out the accumulated vacation time and such. No bounced paychecks, unpaid expense reports, or surprise locked doors.

I spent the time working on personal projects, preparing for and going to Burning Man, studying up more on open source community management, digging more into cloud computing, and interviewing at a number of interesting companies.

And now, as of November 1st, I have a new gig. I am the Community Manager for the open source company Eucalyptus Systems.

Eucalyptus is based in Santa Barbara. I will remain based in Seattle, and will be travel down to the offices regularly, and will be travelling for conferences.

My first conference in my new corporate livery will be the second Open Stack Design Conference, which is next week in San Antonio.