Johnny Football sure looks familiar...

Who exactly is Desmond blocking here?  Because he's holding the ball in the wrong hand to strike a Hesiman pose...

Certainly not Alabama cornerback Deion Belue.

Johnny Manziel for the Heisman!

:-Dustin

Fascinating, Unique, Memorable Authentication Strings

I was asked a very interesting question by a reporter earlier this week.  To paraphrase, I was asked for "better ways" a website might secure information, rather than a password.

Here's an article I've written in the past on the topic, as to how I manage my own passwords.  I still use a long, randomly generated password for each and every account (200+ and counting), to this day, but honestly, great passwords are unfortunately impossible to remember.

It's absolutely ABOMINABLE and should be ILLEGAL when sites try to identify you or recover your password by using some marginally public information.

• Which of the following phone numbers have you been associated with in the past?
• Which of these addresses have you used in the past?
• What's the name of the street you grew up on?
• What's your mother's maiden name?
• What's your high school mascot?

All of those are trivial to discover about a person.  Try it on someone you sort of know -- a friend or colleague.  I bet you could socially engineer your way through 4 or 5 of those in a matter of minutes.

Fortunately, there's a much better approach.  Unfortunately, very few people sites actually use it.

The best such sites actually enable you to choose both your security question/hint/challenge, and the answer/response.

Now, selecting a great question/hint/challenge is a bit of an art, but here's an excellent strategy...

Given a short sentence fragment consisting of pronouns, each and every human mind can make some fascinating, unique, and most importantly, memorable, connections.  The more pronouns, the better.  Pronouns are basically variables, with distinct but difficult-to-guessable values.  I'm sure you've played a Mad Lib game before as a kid, right?
Here's a simple example, to introduce the concept:

• Challenge: He looked at her
• Response: BogartBergman

The question is a reference to the line in Casablanca, "Here's lookin' at you kid".  In that quote, Rick (Humphrey Bogart) toasts Lisa (Ingrid Bergman).  That question will jog my memory and I'll remember the rest.  Others probably won't make that connection.  Pronouns are like programming variables.  I happen to have their values in memory, but others won't.  Out of context, it makes no sense whatsoever.  Just say it outloud, "He looked at her."

The more pronouns you use the better.  Here's another example:

• Challenge: He traversed it for his mother
• Response: CaesarRubiconAurelia

If classic movies and classic Rome aren't in your wheelhouse, use something more personal.  Maybe your Dad took your Mom on a nice vacation...

• Challenge: He took her here for this
• Response: JimDianeBaliAnniversary

Almost anything sufficiently ambiguous would work...

• Challenge: Best that ever was
• Response: BrettFavre4

Pose that same question to a few thousand people and you'll get anything from MuhammadAli to TyrannosaurusRex to SharkWeek1987 or billions of other responses.  But ask the same person that question, and they'll come up with a memorable response.  In this case, it's almost like a hash or HMAC.

The reason that this works is that these challenge/responses are subjective, rather than objective and discoverable facts, like your Mom's middle name.

Hopefully you're starting to get the idea :-)

Use longer challenges, with more pronouns, for higher quality, more entropy in your responses!  Perhaps you can post your own suggestions in the comments below...

I'm actually working on an automatic challenge creator, that you'll soon be able to use to generate your own challenges, and derive your own response.

:-Dustin

Secure Your Keys, Tokens, Certs and Passwords

Enabling Multifactor Authentication in the Cloud

Storing Keys & Passwords with Gazzang zTrustee

Seed /dev/urandom through Metadata (EC2, OpenStack, Eucalyptus)

If you attended my talk about Entropy at the OpenStack Summit in San Diego earlier this month, or you read my post and slides here on my blog, you noticed that I had a few suggestions as to how we might improve entropy in Linux cloud instances and virtual machines.

There's one very easy approach that you can handle entirely on your end, when launching an instance, if you use Ubuntu's cloud-init utility, which consumes the user-data field from the metadata service.

You simply need to use ec2-run-instances or euca-run-instances with the --user-data-file option.

Cloud-init supports a directive called write_files.  Here, you can specify a path, ownerships, permissions, encoding, and content of a given file, which cloud-init will write a boot time.  Leveraging, this, you can simply "create" (actually, just append to) the psuedo random device that the Linux kernel provides at /dev/urandom, with is owned by root:root and permissioned rw-rw-rw-.  The stanza should look like this:

write_files:
-   encoding: b64
    content: $SEED
    owner: root:root
    path: /dev/urandom
    perms: '0666'

Now, you'll need to generate this using a script on your end, and populate the $SEED variable.  To do that, simply use this on your host system where you launch your cloud instance:

SEED="$(head -c 512 /dev/urandom | base64 -w 0)"

This command will read 512 bytes from your locale system's /dev/urandom and base64 encode it without wrapping lines.  You could, alternatively, read from your local system's /dev/random if you have enough time and entropy.

Using the recipe above, you can ensure that your instance has at least some bit (actually, 4096 bits) of randomness that was collected outside of your cloud provider's environment.

I'm representing Gazzang this week at the Ubuntu Developer Summit this week in Copenhagen, Denmark pushing for better security, entropy, and key management inside of Ubuntu's cloud images.

Cheers,
:-Dustin

Encrypt Everything Everywhere (in OpenStack)

Here are the slides from the first of my two presentations on behalf of Gazzang today at the OpenStack Summit in San Diego, CA.

In this presentation, we started out examining the landscape of security within cloud computing, what's changed, and why encryption is essential to the integrity of the industry.  We talked about the types of sensitive data that need protection, and looked at some astounding statistics about data breaches in the past 3 years that could have been easily thwarted with comprehensive encryption.

We then discussed the several layers where encryption is essential:

1. Network layer
2. Filesystem layer
3. Block storage layer

Within the network layer, SSH seems to be well understood and practiced, though we did talk a little about some tools that can help with SSH public key management, namely ssh-copy-id, ssh-import-id, and DNS records for SSHFP.  We also talked about TLS and SSL, the fact that many applications and services support SSL, but that it's rarely configured or enabled (even in OpenStack!).  PKI and key management tend to be the hard part here...

At the block storage layer, we discussed dmcrypt, and how it can be used to efficient protect entire block devices.  We discussed several places within OpenStack where dmcrypt could and should be used.  We also discussed some of the shortcomings or limitations of dmcrypt (single key for the entire volume, hard to incrementally backup, all-or-nothing encryption).

I then introduced overlayroot to the OpenStack crowd, as convenient way of all local changes and data within an OpenStack guest.

At the filesystem layer, we discussed per-file encryption with eCryptfs, as well as Gazzang's commercially supported distribution of eCryptfs called zNcrypt.  We compared and contrasted eCryptfs with dmcrypt, and discussed the most appropriate places to use each within OpenStack.

Finally we touched on the piece of technology required to bring all of this together -- key management. To actually secure any encrypted data, you need to safely and securely store the keys necessary to access the data somewhere other than on the same systems having the encrypted data.  We talked a little about OpenStack Keystone, and how it does and doesn't solve this problem.  We also introduced Gazzang zTrustee, which is our commercially supported key management solution that Gazzang offers as a turnkey solution in this space.

Enjoy!

:-Dustin