Because with 99.99% certainty the person that needs to unlock the account is me, and not an attacker.
Even with a dozen backup yubikeys and spare codes written down I’d still be much more likely to lock myself out than be attacked.
If it’s one thing I have learned the hard way it’s that the most dangerous person in the equation is myself. I won’t trust myself with any kind of security.
Anytime you have a human in the loop you have the risk of human failings. I.e., that human forgets to follow critical step X in the protocol. Or that human falls for the attackers emotional sob story and takes pity on the attacker and lets the attacker unlock your account. Or that particular human is amenable to bribery to obtain the outcome the attacker wants.
In fact, many sim swaps have been reported to have occurred because of "human at cell phone store did not follow protocol" or "human at cell phone store was taking bribes".
So having a human in the loop is not an absolute solution to solving the problem.
I'm not sure you get this. Google hasn't seemed to get this in the past. They have added some customer support though.
This is exactly my point. If the risk of an attack is X, the risk of me being that person who fails or forgets a critical step of the protocol (backup yubikey, whatever) is a hundred times higher. So this system of “flawed humans interacting” to me looks like the lesser evil.
I don’t want my things protected by foolproof protocols. I‘m the fool you see.
That's why I'm bullish on things like Shamir's Secret Sharing and other social recovery tools.
Any port-out requests are handled manually - you are contacted by a human to ensure that you made the request. You can ask them to put a verification code on file for you to confirm when this happens if you're concerned about the security of your XMPP account (which itself could use whatever kind of authentication scheme you like).
There is also work being done to update the type field of JMP numbers so they appear as "mobile" instead.
Type field is interesting. Not sure this can pass the radars for too long though.
So I've been working on a backup plan. Current incarnation is to use a simple Go cli tool with Shamir's secret sharing algo to break a password into N/M shards. The user can then do whatever they please with the shards, give some to their family, friends, attorney, make a pirate map, get an rfid chip, anything you want.
They can meet at the funeral to assemble your horcruxes.
I am not sure this is true. Most people regularly get phishing e-mails and apparently fall for it.
SMS and TOTP (due to the window of time the TOTP code is valid) only provide limited protection against active phishing attacks, since phishing site can 'proxy' the the SMS/TOTP code besides the password.
I think I would prefer losing access to an account (since I make backups of critical stuff anyway) than my account getting compromised, which could lead to identity theft/fraud, etc.
If you need a blood sample, then would donating blood be considered compromising security?
Identity is what your DNA is. Password is a secret. Your DNA is not a secret.
I will agree with "you have to be physically present" is good enough password. This is Yubikey, which works fantastic. The problem with DNA is when it is compromised - you can't throw it away/change it without exorbant effort (bone marrow transplant? and then you're simply taking on someone else's identity? is that identity theft?).
[0] https://www.quora.com/Do-we-require-live-cells-when-extracti...
Which I agree, that works great, but quite narrow in the the use cases at that point.
Carriers have already demonstrated their complete across the board failure to have appropriate security procedures. Your DNA isn't hard to find, you leave it literally everywhere you go.
And do you really want mobile carriers creating a DNA database of their every customer? The same companies that already sell your location data to bounty hunters?
That's going to be a big no thank you from me.