The Price of a Password Breach


Go read this article on the Stormpath blog about the financial cost of a password breach. Briefly, Sony has reported that they spent $172 million on the fallout and recovery from the compromise of 77 million PlayStation Network passwords. The average password breach apparently costs companies about $5.5 million to recover from.

I talk to a lot of early-stage startups about how to securely authenticate users. For 99% of the companies I talk to (ours included), any kind of security breach would likely be fatal. If you're going to allow your users to log in with a password, there's ample advice out there for how to securely authenticate that password - find the most well-maintained authentication library for your platform of choice (we like Devise for Rails apps), and follow its rules slavishly.

But that's not usually the advice I give. If you're just getting started, don't get into the password business. I'm a huge fan of delegating authentication to a trusted third party. When we launched Meldium, for the first few months we only allowed sign ins via Google Apps. While we may have lost a handful of sign ups due to that restriction, we were able to spend more time concentrating on our actual product, and less time thinking about and correctly implementing a secure and usable login experience (it's hard).

The key is to figure out where your users already hang out, and use that system for authentication. See if you can offer login via one of these five providers:

  • Google Apps: Your app will be used by teams, especially in smaller or newer companies.
  • Facebook or Twitter: Almost any consumer app.
  • LinkedIn: Business apps that will be used more by individuals, rather than teams, or users in larger companies.
  • GitHub: I've seen a handful of web apps (Parse is a recent example) start to offer login with a GitHub account. If your target customers are developers, you should strongly consider using GitHub as your auth system.

I also strongly encourage companies to pick only one of these auth providers. You'll be tempted to add more than one in order to support more users, but this is a distraction for an early-stage app and it can lead to a UX nightmare, with your customers wondering, "what did I use to log in last time?". If you really must add more than one authentication provider, consider something like AccountChooser to help users remember their sign-in method.

Your early-stage company's success or failure won't depend on your login system, just as it doesn't depend on your choice of platform, database, templating language, or any of the other behind-the-scenes stuff. Treat authentication like any of these other non-core features and let someone else do it for you.