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.