| MFA and Authentication has a much larger scope than what you've brought up here. I should start by I think passwords have atrophied and should be replaced, and MFA is the best option we have to replace passwords at this time. However, MFA has flaws many people are unaware of. I apologize for starting with a contradiction to something you state, but MFA does not neutralize most hacker threats. It only addresses authentication, it's unable to help against software compromises or user compromises -- Phishing attacks would still be effective, as the user will input a valid temporary token. What is MFA effective at preventing? Brute force password attacks, and users choosing bad passwords. An attacker who compromises an internal system or is successful in egressing a login database will gain the session tokens for logged in users and be abel to use that to access compromised accounts (subverting the entire logged in process.) But, you covered this, so I will digress to mentioning MFA's authentication concerns: The "forgot password" or "lost my token" systems are always a weak link. Frankly, it's improbable (due to overhead costs) that any bulk service provider (twitter, gmail, etc...) enact a strict verification process beyond automated email/phone verification (and this has been compromised before, lookup the attack against cloudflare's google services.) Second to the "lost password/token" attacks, there is the simple attack against the session ID/token. Remember, once you're logged in, your computer will store a token that it shares with the service to verify you are still authentication. While the token will expire, if the token is active then system will accept the session ID or token to verify you are logged in. The egress of data from the twitter login database included these session IDs. Of course, this requires a compromise of the system and not a MFA login compromise. Finally, on your discussion of using an MFA token for every login, every time. This is actually not true in all cases. A reasonable approach most implementations use is to require MFA for logins from unknown computers/IPs, once a system is verified via MFA a user would likely have a grace period when they would have to enter only their password until that grace period expires and then they would have to verify via MFA again, this could be 1 week, 1 month or 1 year+ Of course these statements I've made are really up to the environment's configuration, ideally in a very strict environment it's expected you verify via MFA each and every time, session IDs are updated automatically with every action and users are aware of security risks. But we don't live in this security/paranoia utopia (and perhaps that's all for the better.) Hope I've helped spark some discussions on MFA here. Bam, i'm out! |
Interesting to think about. And you're right, phishing, breaches of the MFA database, and session jacking (via breaching the session database) are all big problems still.
But it's significantly more difficult to compromise certain accounts with another channel of authentication. Whether it's the initial attack vector (trying to crack some random employee's password) or secondary attack vectors (once access is gained, trying to go up a security level or compromise servers upstream, etc.), if each of those authentications require (after initial setup) a secondary device, it's just so much harder to crack.
Anyway, I think there's got to be a way to design a security system that partitions secure information. MFA secure cookies (or whatever we want to call long-term session ids associated with authenticated secondary channels), I would hope could slow down access to individual accounts.
Ideally, secure cookies get more sophisticated in the future and truly lend a 'distributed' quality to the architecture (i.e., are just one-time RSA private keys, maybe?). Thus making it very difficult to login without actual access to the device that the user setup MFA with.