Beware of "Read-Only Bank Access"

After moving to the United States, I have come across this reassuring statement fairly often:

<Product name> only has read access to your accounts. Nobody can authorize any transactions on your behalf, not even <product name>.

This is a particularly popular thing for services like Mint and Credit Karma to say in an effort to get you to give up the holiest of holies: The login credentials to your online banking accounts. This “guarantee” is also completely false, or at least incredibly deceptive.

There’s no such thing as “read-only access” to your Chase banking or American Express card accounts. Services like Mint and Credit Karma store your real usernames and passwords on their servers, not some kind of read-only token. If their servers get compromised, your linked bank accounts may very well be fully compromised as well.

Here’s the kicker: These services know this full-well. When you sign up for any of them, you’re agreeing that they bear no responsibility in the case of a compromise. (Read the fine print.) Your money is now gone, and they won’t be there to help you. FDIC won’t help you either—that only protects you if your financial institution becomes insolvent, not if your accounts are compromised.

What these companies actually seem to mean when they say that their access is “read-only” is that there is no functionality within their interfaces which allows people to authorize transactions and perform other changes, not that the credentials they’re storing can’t be used to do absolutely anything on your accounts. (The former borders on the irrelevant, of course, and the latter is what most people actually care about.)

Carefully evaluate whether you want to trust these companies based on these “protections” and the way they present them, and remember they won’t be there for you if things go wrong.

(To give a little perspective: Intuit, the company that develops Mint, Quicken, and QuickBooks, lets you encrypt your Quicken data file using a password, but only allows that password to consist of 15 characters or less. This is their supposedly “military-grade security system;” 15 characters isn’t even enough to reach 128-bit security, the lowest acceptable level for strong security.)

If you’re currently using any of these services, and want to reduce your risk, deleting your linked accounts within the service and/or the service account itself, as well as changing the password for each of your linked accounts should do the trick.

Gambling with Secrets: an Introduction to Cryptography

Art of the Problem is a team of people making web video series about great problems. Their first series is an introduction to cryptography and cryptanalysis, and it’s one of the most approachable I’ve seen.

If you’ve ever asked yourself questions like:

  • How can two people communicate securely even if somebody is listening in on the conversation?
  • How can two people have an encrypted conversation without meeting?
  • What does randomness mean? Are things that “look random” secure?
  • What is the most secure cryptographic cipher?
  • How did the Allied Forces break Nazi Germany’s “super-secure” Enigma machine during World War II?

…you’ll enjoy this miniseries.

No special background in mathematics is required, and it touches on many subtle mistakes that huge companies are still making today. It consists of 8 parts/chapters, each lasting about 5-10 minutes.

Part 1: Introduction to Cryptography

Part 2: Prime Factorization

Part 3: Probability Theory & Randomness

Part 4: Private Key Cryptography

Part 5: Encryption Machines

Part 6: Perfect Secrecy & Pseudorandomness

Part 7: Diffie-Hellman Key Exchange

Part 8: RSA Encryption

For more, visit their website.

The Secure Remote Password Protocol Isn't Bad

Blizzard Entertainment has been receiving a lot of flak recently for using the Secure Remote Password protocol for password authentication in their service because SRP doesn’t provide the same level of protection against offline attacks that one-way key derivation and password hash functions like PBKDF2, bcrypt, and scrypt do.

I applaud them. Well done, Blizzard. You’ve done more to protect your users than most other companies that handle user passwords. It is great to see a company employ real safeguards like SRP and two-factor authentication (which you introduced long before it was cool.)

All of the recent criticism of Blizzard’s design decisions kind of misses the point. SRP was designed to prevent eavesdropping attacks (by never transmitting the password over the wire,) not dictionary attacks against the password verifiers (the kind of digests that are stored on the server side.) This is akin to blaming Diffie-Hellman key exchange for the fact that DES is easy to break, since the SRP authors never made any claim that the verifiers were resistant to dictionary attacks.

Blizzard absolutely made the right choice by choosing not to transmit passwords over the wire. The people who are suggesting that they throw out SRP on the client side for a KDF on the server side seem to completely miss that this would only switch out one security vulnerability with another. A better solution would be to employ a one-way key derivation function on the client side, store the salt on the server side (so any client can produce the same digest for the same account, even if it’s on another machine,) and then transmit the verification “digest” (or proof of it) in a non-revealing/non-reusable way (if the traffic is snooped, or the verifiers are compromised,) the latter being precisely what SRP does.

The above would provide more protection against password compromise than the password authentication used by virtually all web applications and almost all desktop clients. It seems strange to me to criticize Blizzard so aggressively for not doing both when nobody else does.

Implementing Two-Factor Authentication Is Easier Than It Seems

User and password verification with two-factor authentication isn’t as easy to use as plain old user and password, but with smartphones it comes very, very close. At the same time, the security benefits from having another secret stored on a different terminal are massive. Users’ accounts aren’t necessarily compromised if their passwords are.

In my mind, two-factor authentication is one of the least tedious things you can add that adds the most security to user accounts.

“But it’s a pain to add to your application, right?”

No! Just take a look at main() in this example that uses only the Python standard library:

#!/usr/bin/env python
import base64
import hashlib
import hmac
import os
import time
import struct

appName = "MyApp"

def newSecret():
    return base64.b32encode(os.urandom(10))

def getQRLink(name, secret):
    return "|0&cht=qr&chl=otpauth://totp/{0}%20-%20{1}%3Fsecret%3D{2}".format(name, appName, secret)

def auth(secret, nstr):
    # raise if nstr contains anything but numbers
    tm = int(time.time() / 30)
    secret = base64.b32decode(secret)
    # try 30 seconds behind and ahead as well
    for ix in [-1, 0, 1]:
        # convert timestamp to raw bytes
        b = struct.pack(">q", tm + ix)
        # generate HMAC-SHA1 from timestamp based on secret key
        hm = hmac.HMAC(secret, b, hashlib.sha1).digest()
        # extract 4 bytes from digest based on LSB
        offset = ord(hm[-1]) & 0x0F
        truncatedHash = hm[offset:offset+4]
        # get the code from it
        code = struct.unpack(">L", truncatedHash)[0]
        code &= 0x7FFFFFFF;
        code %= 1000000;
        if ("%06d" % code) == nstr:
            return True
    return False

def main():
    # Setup
    name = raw_input("Hi! What's your name? ")
    pw = raw_input("What's your password? ")
    secret = newSecret() # store this with the other account information
    link = getQRLink(name, secret)
    print("Please scan this QR code with the Google Authenticator app:\n{0}\n".format(link))
    print("For installation instructions, see")

    # Authentication
    opw = raw_input("Hi {0}! What's your password? ".format(name))
    if opw != pw:
        print("Sorry, that's not the right password.")
        code = raw_input("Please enter your authenticator code: ")
        if auth(secret, code):
            print("Successfully authenticated! Score!")
            print("Sorry, that's a fail.")

if __name__ == "__main__":

Not using Python, and don’t want to port this code? There are many TOTP libraries available that are just as easy to use!

If you don’t implement two-factor authentication in your applications, please consider supporting a federated authentication mechanism like OAuth or OpenID so users can leverage providers that do.

Code based on example by brool.

The History of Password Security

What better way to follow up on my post about storing passwords securely than to take a look at how password hashing has evolved over the years?

I think you’re likely to be surprised by what “new” things were being done all the way back in the 70s!

These slides are courtesy of Openwall’s Alexander Peslyak, perhaps better known as Solar Designer. The original high-resolution versions, and a PDF with all the slides, can be found here.