It seems like the bigger day to day issue is the possibility of downgrades from STARTTLS or a server that doesn’t support TLS. Encryption in the GPG isn’t necessary or even would be unwanted (for a company to have records of all the emails).
So there are mechanisms to put encrypted things in workplace emails and then have some mechanism for receiver in a different organization to unencrypt. I have seen a mechanism that comes down to magic links, which I found ironic (though yes, intercepting is less of a threat than sending the data unencrypted).
I feel like supporting an option to not send an email unless STARTTLS happens is the way to go. There’s probably a lot of practical problems for, say, online Outlook or Gmail supporting that option when sending an email. But I feel like that’s the easiest solution.
I will say that for Google's Advanced Protection, I was convinced having a recovery phone added was okay.
I just have a hardware key on my key chain and one on a pretty fireproof safe (which I got for other reasons). But I still added a phone recovery just in case.
As I understand it, the recovery process will always wait multiple days while sending many emails to me that it's been initiated.
Having different passwords doesn't prevent phishing where you think you're logging into the service being phished. The hacker would also create a new TOTP on that service once they get in to that service.
I think the DNS key is only for the handshake to provide the certificate for the actual key. Without a certificate from a CA for second part, all the spoofed DNS key would get is what website they were trying to visit.
It is sort of the inverse. To be pedantic, mechanics have mechanic's liens which allows them to hold a car forever until they're paid.
If it's worth enough for Google, Google could definitely bring full force of judgments. The only thing is the LBO debtors have a UCC lien which may be worth more than what Twitter is worth in a bankruptcy.
Twitter does currently have cash and may pay a judgment to prevent an event of default on the big debt. But debtors always have to worry being behind secured debt.
There are various methods of getting and collecting judgments where it will be illegal to not pay, or at least illegal to not cooperate with collections.
The easiest mechanism is definitely just refraining from providing more services. But when debts get to two commas, the legal fees will start to be worth it for collection.
Any OTP can be phished. There is no automatic authentication that the OTP is being given to the correct party.
A public/private key alone would have a similar issue, but the browser for FIDO keys gives the domain it's actually talking to. The domain is authenticated with TLS or the browser on an uncompromised machine won't send that domain over. The device only signs the challenge with the private key generated for that specific domain.
While you're technically correct any authentication system worth it's salt would ideally see the same user trying to authenticate from two different locations, and prompt the second user for another factor of authentication (Email, etc.) And since TOTP expires it's not like they could sit on the token and use it later.
A compromised main UI device could also show the wrong account recipient, even if hardware key is used. The text could be changed on the screen when the user meant to send a small payment to someone else. Yubikey will be pressed like usual. Apple's standard prompt on the phone may not have the recipient shown.
I'm a bit late, but this is referring to ditching RSA only for encrypting a symmetric key. The algorithm is vulnerable to side channel attacks since it expects the plaintext to follow a certain padding. The method only has 6% use today and is generally deprecated for DH.
For DH, RSA is still used purely for signatures. RSA is not used to hide any data.
So there are mechanisms to put encrypted things in workplace emails and then have some mechanism for receiver in a different organization to unencrypt. I have seen a mechanism that comes down to magic links, which I found ironic (though yes, intercepting is less of a threat than sending the data unencrypted).
I feel like supporting an option to not send an email unless STARTTLS happens is the way to go. There’s probably a lot of practical problems for, say, online Outlook or Gmail supporting that option when sending an email. But I feel like that’s the easiest solution.