Geez why is it that every time we hear of a service that offers 2fa gets hacked, it turns out the 2nd factor (or heaven forbid, we ever get a 3rd factor) isn’t used as a second layer of encryption on important data??? It seems to me, with all the options available for 2fa (yubikeys have so many alone), surely there should be a way to use that 2nd factor to encrypt over what the password encrypts (or the other way around, either way). But nope, it’s just a simple “check at the front entrance” and if the back entrance gets a threat actor in there, the 2nd factor is already bypassed for every. single. account. Doesn’t that seem like the dumbest way to implement a 2nd factor??? Is there no hope in our future for this to be fixed???
2 parts to this.
- We are always reliant on the businesses hosting said service to use proper security and encryption methods with proper implementation. Which in your post doesn’t seem to happen a lot more than you think.
- If possible, setup your own self hosted service and keep the data where you know it is in a good place. Then you can use your own security best practices and encryption(VPN, encrypted storage, etc).
I think you misunderstand what 2FA (whether TOTP like Google Authenticator, or HOTP and similar hardware tokens like Yubikey) is/does and how it works on the server side.
When you register a 2FA, you are doing a one-time synchronization of a starting seed or token that only the server and you are supposed to have. From this seed or token the actual one-time passwords are generated, either based on time, or a hash function with a counter, or other methods. The server needs to keep the base seed/token somewhere that it can access on the fly when you are trying to log in - meaning it can’t be stored as a hash like a password is. A good provider will store this in a separate database with encryption-at-rest based on a public/private key that only the authentication server can access, because if the tokens are stolen then the 2FA is meaningless. At very large scale the authentication process will be separated across separate servers (processes/containers), meaning password and each other factor are separate. If the token was to be reused as part of the password hash (similar to a salt), depending on the architecture it may decrease the runtime protection of the token (more places it can be stolen from), and it would also mean that any time a user needed to replace their 2FA they would need to change their password too. It also complicates things because different users may have different second factors enabled, so now you have to create a reliably repeatable function for which factors to add to the password hash and in what order. Additionally, it means that the password hashing can only happen server side, while some people feel it is better for the password hashing to happen client-side instead of transferring the actual password (this is not a best practice because of multiple attack vectors it enables, I’m just bringing up reasons that some people have).
I knew the basis of what you just said (not the separation details though)… but I guess, better stated, my question is:
WHY DOESN’T A STANDARDS INSTITUTION DEVELOP A 2FA METHOD FOR THE PUBLIC THAT WOULD ENABLE A 2ND LAYER OF ENCRYPTION OVER THE DATA???
Having said that, I realize most major cloud providers used by the public leave the cloud data readable by the cloud owners, and the government. and this is a very intentional move. and we’ve all heard about the hash scanning, the false accusations and arrests that came along with that, etc etc etc. I’m sure the government very much does NOT want the general public to encrypt data in a way that makes it unreadable to the government. I mean, we’re even seeing U.S. bills being written that emulate / copy the type of laws the UK recently enacted.
And that might be the answer.
2FA/MFA (Two or Multi Factor Authentication) is purely adding more factors to verify a user’s identity - what you know (password), what you have (TOTP/HOTP), what you are (biometric). Unless the 2FA method included an entire extra public/private key (which is possible with Yubikey but I don’t know how standardized it is) it doesn’t really improvr security of the data at rest (password hash) because if an attacker can get the password database there’s a decent chance they can get the token database and server private keys as well. More complexity properly implemented does make it harder for an attacker, but more complexity improperly implemented is just a false sense of security. Properly using data from another factor to encrypt password hash storage requires sophistication and care that no generic company can be expected to have or give.
You’re also worrying about something that shouldn’t matter anyway. A good hash function is computationally impractical to reverse engineer, and if a company is salting their hashes and doesn’t accept the hash itself as authentication on any user accessible frontend then stealing the hashes is meaningless. And if a company isn’t salting and is susceptible to pass-the-hash bypasses, then they don’t have the sophistication and care to do the additional work you’re asking for.
Edit: I just realized that you are talking about encryption of other data, not the password hash. I think you’re already making an assumption, that a user’s password is used as encryption in the first place. With the exception of password vaults that is never done, instead the password and 2FA is just a key to allow access to whatever encryption is to be used (if any).
I just wish that more providers would allow hardware keys, my work is switching to 2fa for everything, every time. This is going to be a pain point for all of our students, every classroom they go to will require another 2fa step. If we allowed (or maybe preferred) a hardware key be present for that extra auth step, then time could be saved. Backup if it doesn’t see the key could be to use one of the other methods (email pin, text pin, etc.).
speaking of hardware keys, does anyone make a wireless type of device such that they key needs to be within about 3 feet of the “reader”? I’m thinking like a prox ID card that gets read every few seconds/minutes to make sure the user is still present.
A long range version to within 15-20 feet would be really nice for faculty so they can walk around parts of the classroom, but if they walk down the hall the computer locks until they come back and log in again.
US government can access Office 365 data on any of their locations because of the cloud act…. I have 2 customers that repatriated their data back to on prem after finding out about this, and I don’t blame them.
Many of these cloud providers leave security up to the customer. Look at Microsoft for example and how poorly secured Entra/365 is out of the box. For f’s sake users can sign up for trials and add enterprise app registrations by default!
According to this, they will not just randomly ready your emails:
It is not “normal” for the government to just read your mail. Will it be abused? Almost certainly.
Or does m365 have a different open door policy?
Of course it will be abused. Like most laws are.
I like the “Trust Me” (Bro) comment in the article, wish he had actually said the full meme.