This little post is going to talk about how authenticationgoes beyond just usernames and passwords.

Authentication is something we all do, in fact you probablyare authenticated by some system somewhere just with the information in yourbrowser right now. By definition, authentication is the steps taken to verifythat someone or something is in fact who they claim they are to be. This istraditionally done with passwords, and in more secure environments authenticationtokens, certificates, one-time passwords or biometrics can even be utilized toverify you are who you claim to be.

Multi-Factor Authentication is leading the way as the nextcommonly accepted authentication mechanism. There has been a flood of MFAservice providers are popping up recently, utilizing via your phone, SMS,email, and I'm pretty sure carrier pigeons may be next. Most of these serviceswill only provide extra security at the login screen for your website orsystem. This means, the attackers just adjust their attack vectors.

Attack vectors MFA helps prevent:

1. Brute force attacks
2. Phishing (to a degree)

Attack vectors that MFA does not help prevent:

1. Session replay attacks
2. API token theft
3. 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 attackerdoesn't need your password.

Here are a few real world examples that take advantage ofthese types of attacks:

1. The popular program firesheep and other similar session cookie hijacking programs.
2. Google's application specific password blunder
3. Cloudflare's incident

Luckily, some of these issues have fixes. Namely, HTTPS willprevent anyone from sniffing your session token or possibly script's API keyfrom the wire, but you will have to always remember to verify you are on thesecure version of the site (look for the https:// or verified lock in yourbrowser)

Google also quickly acted to patch the application specificpassword flaw once it was reported. However, what other APIs exist with thesehard coded passwords in them, which may allow unrestricted access? We may hearmore 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 extrasupport related to addressing customers who have lost their multi factorauthentication token? Or is it better to temporarily disable MFA for theiraccount, allowing them access based only on the lost password email orvoicemail confirmation?

What if the company is a small intelligence contractorproviding 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 andonly has a handful of customers, when should MFA be considered for theircustomers?

What if this is just your company or personal blog? I'll get a little more into that in my nextpost.