Monthly Archives: October 2015

Can’t touch this: you should get a YubiKey NEO.

Try to imagine an answer to somebody having full access to all of your devices and still being able to have a chance at wrangling back control of your online accounts. This device is it.

Here’s why I have two Yubikey NEO devices:

  • Availability. All TOTP tokens are initialized on both devices, and any U2F sites get both keys enrolled. I keep one safely stored and the other with me. If I lose one, I can still get into all my accounts to rotate credentials. This is far better than Google Authenticator on my cell phone which is much more likely to be broken or lost, and much less annoying than trying to replicate a similarly backup by printing tokens or trying to store them somewhere online that is both secure and accessible without my two factor device. I can plug my Yubikey into my computer or use NFC on my phone.
  • Security.
    • TOTP: If my token isn’t in a computer, you can’t be me. If you didn’t capture my TOTP secret when it was initially created (or steal it from the provider’s server), you can’t copy it from my devices.
    • PGP: My latest PGP key was device-generated. Nobody has a copy and you can’t steal it. There’s a device counter that keeps track of how many signature operations have been performed, so if I’m actually that diligent I can detect any unauthorized access to it for signing.
    • FIDO U2F: I don’t believe that there’s any better system for 2-factor authentication than this. It goes a very long way to preventing spoofing as well as avoiding shared secrets. It also requires me to touch the device so get an authentication token solely through software.
    • SSH access: A spin-off of PGP support, my ssh identity can be run through a PGP agent so nobody can ssh as me without having access to my device.
    • Yubikey OTP: If you can’t implement U2F, this may be the next best thing.
    • The firmware is fixed, so no Bad USB attacks are likely.

If your access credentials are worthy of a 2nd factor, this is the way to store it. If you can possibly use U2F, do so: not only for your own sake of security, but also for the rest of us by helping to speed adoption. The more people buying U2F devices, the more likely the world is to write code supporting it.

Seriously, this $50 device really is all that and a bag of chips. Other than physically storing my passwords, it supports every method I use to authenticate myself online and it does it more securely than any other method than I’m aware of. If you know of a better device, I’d love to hear about it. If you have an excuse to not buy one, I think it’s probably a poor excuse.

On storing passwords: Don’t go all Ashley Madison; use write-only access.

Let’s start with the basics: you’re supposed to hash your passwords. Basic cryptographic algorithms are a long-gone recommendation there: you should be using PBKDF2, bcrypt, or scrypt. That’s the standard that we call good, but there’s more that you should do beyond how they’re written to disk.

Now that you’ve stored them securely, make sure you don’t go Ashley Madison: don’t use passwords as a basis for anything! In fact, you should never read a password hash for any purpose other than to compare it to a hash. It should be absolutely impossible for your webservers to read the password hash. Webservers should only have access to meta information about the password hash: things like the salt and the number of rounds. The actual comparison to check if the password is valid for a user should be a function call that returns true or false. You can implement this as a stored procedure in your database engine or provide a dedicated authentication service. It’s fine if your webserver can insert or update a password, but it should not have the permission to select it.

Which brings about the next part: if you can’t read a password, you certainly shouldn’t have cause to display it, and thus there are so many things wrong here:

Finally for good measure, I give this admonition for anybody creating session tokens for a browser: create these with random values and store these in their own table so they can be cleared out server-side. It should be possible for you as an administrator to terminate some or all logged in sessions without altering anything else. Each session should have its own random cookie. Facebook, for example, provides this functionality very cleanly:

Facebook allows you to end individual login sessions