This little post is going to talk about how authentication goes beyond just usernames and passwords.
Authentication is something we all do, in fact you probably are authenticated by some system somewhere just with the information in your browser right now. By definition, authentication is the steps taken to verify that someone or something is in fact who they claim they are to be. This is traditionally done with passwords, and in more secure environments authentication tokens, certificates, one-time passwords or biometrics can even be utilized to verify you are who you claim to be.
Multi-Factor Authentication is leading the way as the next commonly accepted authentication mechanism. There has been a flood of MFA service providers are popping up recently, utilizing via your phone, SMS, email, and I'm pretty sure carrier pigeons may be next. Most of these services will only provide extra security at the login screen for your website or system. This means, the attackers just adjust their attack vectors.
Attack vectors MFA helps prevent:
- Brute force attacks
- Phishing (to a degree)
Attack vectors that MFA does not help prevent:
- Session replay attacks
- API token theft
- Abusing the lost password or lost MFA process.
Like the analogy of the steel door bolted to a wooden frame, "more secure" authentication methods (Multi-factor auth, One time passwords)still can fall victim to attacks against a weak link: Session ID's and authtokens. If these secrets fall into an attacker's hand, then the attacker doesn't need your password.
Here are a few real world examples that take advantage of these types of attacks:
- The popular program firesheep and other similar session cookie hijacking programs.
- Google's application specific password blunder
- Cloudflare's incident
Luckily, some of these issues have fixes. Namely, HTTPS will prevent anyone from sniffing your session token or possibly script's API key from the wire, but you will have to always remember to verify you are on the secure version of the site (look for the https:// or verified lock in your browser)
Google also quickly acted to patch the application specific password flaw once it was reported. However, what other APIs exist with these hard coded passwords in them, which may allow unrestricted access? We may hear more about other providers who made a similar mistake in the future.
Handling "lost password" or "lost token" is a bit trickier, and I'd like to hear some of your ideas about it.
Should a company who has implemented MFA accept the extra support related to addressing customers who have lost their multi factor authentication token? Or is it better to temporarily disable MFA for their account, allowing them access based only on the lost password email or voicemail confirmation?
What if the company is a small intelligence contractor providing logins for only a few high profile customers?
What if the company was an online community with 100,000+ members, and made MFA optional?
What if the company is a new mobile-cloud-buzz startup and only has a handful of customers, when should MFA be considered for their customers?
What if this is just your company or personal blog? I'll get a little more into that in my next post.
