About Me!
This blog is about my musings and thoughts. I hope you find it useful, at most, and entertaining, at least.
Other Pages
Presence Elsewhere
Why you shouldn't trust people with your data, and how to prevent it
Date: 2014-02-15
Tags: srp crypto security authentication payment bitcoin chipnpin otp
Database breaches are becoming a common occurrence anymore.
Sometimes, in the case of health care data, there is little alternative to but to have your doctor have access to your records. However, many times, including passwords and payment information, there are better ways; we just need to use them. The first part of this post is aimed at users and the second at developers.
Users
Authentication
Since, for the time being, sending your password to the server seems to be the only option in many cases is to use a password manager to create unique passwords for each site. The password manager uses your master password to encrypt all the other passwords and username combos you create. Applications like KeePass have Windows, iOS, Android, Mac, and other OSs support and can synchronize your (encrypted) password database you can use Google Drive, Dropbox, or move the file around by hand. (N.B. your password database is only as good as the master password protecting it. See the bottom of this section for suggestions on strong passwords).
Another option is to turn on Two-Factor-Authentication. What that means is that you need two things, one you know (password) and one you have (your phone), to log into a service. The second factor (the one you have) could be a One-Time-Password app (Google Authenticator is available on iOS and Android) or an SMS message, depending on how the service handles it.
However, both of these require you have your phone or password database with you. If that’s not an option for you, then the traditional rules for good passwords are a good recourse:
Credit: XKCD
- NEVER, EVER, EVER give your password to anyone. This includes writing it down and putting it somewhere other than a safe (i.e. DO NOT put it on a post-it note on your monitor or under your keyboard).
- A password should be hard to guess, but easy to remember. Hard to guess means it shouldn’t be your name, username, email address, spouses name, any single dictionary word (or leetspeak translation of).
- Different passwords for each site is recommended (because if one site leaks your password, all the other sites are vulnerable too)
With longer passwords, like Correct Horse Battery Staple you may run into sites that don’t allow very long passwords. My suggestion then is to do your best and send the site a nasty email.
Here is some advice from CERN and CMU. While I disagree with CMUs advice to shorten the password by taking the first letter of a sentence, the rest of the site is useful, and that advice is very useful for sites that don’t allow long passwords.
Based upon your trust of the service providing authentication and the permissions required by the service you’re logging into, OpenID or OAuth (e.g. “Log in with Google”, “Log in with Twitter”, or “Log in with Yahoo” provided by sites). For instance, I just used github to sign into a forum because the forum only required read-only access to my email address on github, something I felt comfortable providing.
If a site offers Persona a protocol designed by Mozilla (the creators of Firefox and Thunderbird), that is also a good option because it doesn’t require trust of the site you’re using to not abuse the service.
Credit Cards
There have been a couple large credit card breaches lately, namely from Target breach last December. One way to protect yourself against these types of security failures, is, when shopping online, to create virtual credit card numbers (VCCN). A VCCN is a credit card number associated with your account but:
- Only exists as a number (you don’t get a card, hence being virtual)
- Can be canceled/deleted easily
- Have limits set (e.g. only valid until sometime or only $X can be charged to it)
- No relationship to your real credit card number
These properties make them very useful for one-time payments (set the VCCN to expire in a week) or when a retailer saves your credit card number (Amazon, Target, &c) (valid for a few years or until deleted and not associated with your real credit card number). Citi supports this (log into your credit card account and search for “Virtual” on the page. It’s in the left-hand column towards the bottom). I can’t find it for Chase, American Express, or PayPal. Bank of America has ShopSafe which is a VCCN.
There are other companies that do this in a pre-paid manner (e.g. EntroPay) but I haven’t used their services and cannot vouch for them.
A technology common in Europe is Chip-and-Pin which requires a PIN, creating a 2-factor system for payment cards. This is more useful for preventing in-person attacks against a card (i.e. cloning where a person makes a copy of the data on the magnetic strip and puts it on another card).
Developers
Passwords
If possible, use systems that don’t require passwords at all (SRP, TLS-SRP, or Client Certs. This prevents you from even having to worry about storing passwords correctly because you never have the passwords to begin with.
If you can’t change how authentication is being don, please us a key derivation function like PBKDF2, bcrypt, or best yet Scrypt with large memory and time complexity parameters. Also, NEVER EVER EVER store a plain-text or encrypted (which means decryptable) password.
If possible, using services such as openid and oauth (google, yahoo, twitter, github, &c) also means you don’t have to deal with passwords.
Mozilla Persona is also a great option, as your users don’t have to trust you not to abuse the access you’re giving them (because they’re not really giving you access.
Credit Cards
Never store credit cards numbers. If you must identify if you’ve seen a card before, store hashes.
Most, payment providers provide a service that store client credit card information and provide you an opaque id. Auth.net’s Customer information Manager and Cybersource’s Payment Tokenization Service are two examples; just ask your gateway or processor about it! If you’re not storing information, you don’t have to worry about securing it!