Note: This is a rant.
Ok, I’m pissed off. Google gets this wrong. Now my banks got this wrong too.
IT NEEDS TO STOP.
In case you didn’t know, 2FA stands for “Two Factor Authentication”. It’s an additional security measure for protecting your online accounts.
A password is a factor of authenatication. It’s called “something you know”.
2FA increases security by, in addition to a password, it asks for extra confirmation from something like a phone SMS, a smartphone app gesture, or something similar. It’s “something you own” like a smartphone or a coordinate card.
So in order to access your account, you need both the password (“something you know”) and the device (“something you own”). Stealing one without the other will not grant you access to the account.
For example if a computer is compromised with a keylogger, a criminal will obtain your password. But it would still need physical access to your phone (or hack your phone).
Overall, this contributes to making the internet a safer place…. except that where it matters most, companies are screwing it up.
How Google gets this wrong
Google allows to reset an account password with nothing else than an Android phone. This is a MASSIVE security flaw. It effectively turns 2FA into “1FA”.
Ironically the post I’m linking to in Reddit suggests to enable 2FA… it is effectively pointless because if someone steals your phone, they can reset the password AND get the security token. Unless you use a different phone or software key as the second factor (and is kept hidden), this is pointless.
Some people suggest to use a lock screen. This indeed, is an effective method. If somebody steals my phone, they won’t be able to unlock it, hence they won’t be able to reset the password.
However, this is not a solution. It’s a workaround. It should be impossible to reset a password so easily by just having the unlocked phone in your posession.
Account recovery works as a tool for breaking two-factor authentication because it “bypasses” 2FA entirely, Fenton explained. “Just after [the Honan story was published], I created a Google account, created 2FA on it, then pretended to lose my data.”
Fenton continued: “Account recovery took some extra time, but three days later I got an email helpfully explaining that 2FA had been disabled on my account.” After that, he was able to log back in to the account without 2FA.
The problem is that we’re in 2017, 2018 is around the corner, and to my knowledge this problem persists. This article is from 2015 btw.
How to fix this flaw:
Ask for something else. Like sending an email with a confirmation link to the registered emergency emails. Ask more questions. Don’t just give access right away FFS.
How my Bank gets this wrong
I won’t name the banks. But virtually all banks in my country are getting it wrong so I don’t need to point fingers.
They’ve recently added 2FA using what they call a “Token”, which a random string generated via an app that can be downloaded for Android and iOS.
Problem is… in order to generate the token, this app first asks for all login credentials (including passwords) and it seems they’re stored in the device (I didn’t analyze if they’re encrypted or not, but that’s pointless anyway), or at least the cookies are. This is my face when I saw it:
So… if the phone is compromised, not only will an attacker get the ability to generate and see the tokens, but they will also have all of my login credentials. Even if the credentials are not stored in the device (good) and only the cookies are, a phone that was compromised when I log in for the first time is still bad. Once again, 2FA becomes “1FA” because all you need is to compromise the phone.
How to fix this flaw:
The login credentials for the phone app must NOT be the same as the online banking web credentials.
It should be possible to generate a second password from the online banking web interface that will only be used with the phone app. The phone app must not be able to change the web password either.
Credentials must never be stored in the device, not even in encrypted form.
Cookies must be resalted and renewed periodically.
Passwords must NEVER be sent straight via the internet. Not even if the connection is encrypted via SSL / RSA. Authentication must be done by hashing the password using a slow hash function such as bcrypt, scrypt or PBKDF2, and using a salt. Passwords must never be exchanged directly, not even if the connection is encrypted. Repeat it after me: Passwords must never be exchanged directly, not even if the connection is encrypted.
Or do not make it mandatory, and use something else instead, like Coordinate Cards (fortunately, they do have this option). Analogic technologies such as a printed card cannot get hacked. And FFS, like passwords, do not send the coordinate cards’ values directly even if the connection is encrypted. Salt and hash them.
2FA is hailed as the holy grail of modern security. But it is very easy to lose oneself in the hype and mess up 2FA. Please don’t.
Proper cyber security isn’t just about having a smartphone app to generate a security token and stamping an SSL certificate on your website. Those two are merely the first steps.
Unfortunately, the Internet is full of mindless code monkeys. Yahoo stored passwords using MD5 (note: that’s bad), and LinkedIn stored passwords using unsalted SHA1 (also bad). Just because SHA1 has stands for Secure Hash Algorithm in its name, doesn’t mean it makes it secure for storing passwords. The “secure” in its name comes from the algorithm being theoretically impossible (at the time, SHA1 is now considered weak) to have an input generate *on purpose* the same output as another unrelated input. But it doesn’t mean it’s secure for storing passwords.
Please, don’t be “that guy”. Specially if you’re in charge of banking infrastructure.