After it took me a week to recover access to a GSuite account that I knew the password for (long, unique, stored in a password manager), that I could confirm access via the recovery email, and that had my phone number attached - but Google were insisting that I was a hacker, and Support-robots refused to help me or assign a human until I found the secret Konami Code that summoned a human.

That experience was exceedingly frustrating, and has killed the last ounce of trust I have for them to do anything for which I might rely on.

While they have neat technology, if you fall into one of the cracks, it's near impossible to get support.

Apple forces me to instal 2FA, but I just don't want. I cannot use a third party app or tool but must use my phone number. This is pure pain to me, because I want to use things like Apple Cash or AirPlay from the phone to the AppleTV.

Is there a better solution? I dont know. But 2FA, especially when linked to a phone number, is terrible - at least from my usability point of view.

pass: https://www.passwordstore.org/

otp extension: https://github.com/tadfisher/pass-otp

The reason I prefer it is that I don't want to store 2fa credentials on the cloud and I don't want to lose all my codes if I brick my phone. SMS is a poor 2nd factor, so I'd prefer not to rely on it.

There are other issues, no situation is perfect, but I have found hardware keys to be much simpler in the long run.

Own your own passwords (don't use "log in with XXX"), own your own domain for email (even if you don't host it, you have the option to do so later instead of being locked out).

One of the problems being on the legacy Google Apps for Domains free accounts is that you're not technically entitled to support.

So, this might not work for your situation.

In any case, for me I went and logged a ticket through https://support.google.com/a/contact/recovery_form

You will then get an email to the nominated email address in the form telling you the case is opened. Don't get your hopes up just yet.

A while later you'll get an email telling you that you're not entitled to support because you're on the free plan, and to go through the self reset options (which you already did, presumably via https://accounts.google.com/signin/recovery)

If you reply and explain that you've done this, and you're still getting <the error message specific for you> - it may be assigned to a human. If it's not, try again, maybe with a new case. You will need to be patient - expect 24-48 hours between you sending them email and them responding.

For me, they wanted me to prove domain ownership (TXT records), as well as a whole bunch of information about the account and it's users.

Once I submitted the ownership information it took several more days, and then they send you a one-time reset link to reset the password (yes, even though I knew it).

It's been almost two months now. I managed to get through to a human but they misunderstood my problem, referred me to the wrong documentation, and then stopped replying altogether. I am now shopping for lawyers to sue them under the GDPR for something that any other company would have resolved in an hour or less.

Do not trust Google to be your gatekeeper.

[0]: https://news.ycombinator.com/item?id=25091420

My work has the same sort of setup, they expect you to install the "Microsoft Authenticator" app (no TOTP supported) and click approve in that. But how have we increased safety when my Team/Outlook phone app requests that I click "approve" on a different app? I'm basically alt-tab'ing and clicking a different button, not really an improvement. It should be on a separate device, or something out of Microsoft's control so they can't screw it up.

Worse still is SMS 2FA, which appears to just be an analytics technique rather than a security feature. As we know, a phone number is only as secure as a carrier's most-tired employee.

Not in the slightest. I tried to configure TOTP-only and Google effectively tells me to go fuck myself, because they apparently know how to secure my account better than I do.

And the Gmail app refuses to allow IMAP accounts to archive emails, so that's pointless...

Unfortunately that's a number a hacker can call to social engineer the employee and steal your account. Same method as in SIM swapping attacks.

1.) Some unexpected glitch occurs (could be the user's fault or could be the company's), and the user's ability to access the service is temporarily interrupted until a human is able to investigate and resolve the problem.

2.) The user is specifically targeted by a malicious actor performing SIM swap and/or social engineering attack.

I'm not really a gambler, but if I'm forced to guess, I'd say #1.

EDIT: clarify initial assumptions

While I do have a VPS, it only has like 20GB, so I've yet to find an affordable and easy photo sharing solution.

https://photostructure.com/faq/why-photostructure/

But if you're into "cloud" storage, Mega.nz gives you 50GB of free and very reliable storage.

This is definitely true for 99% of people though

"Trust us."

Yet no company wants more personal information from you than this one. They want everything. Even when they have so much, they are going to great lengths to get more.

They are not in the security business, they are in the online ad sales business.

Some bullshit with Windows Hello, I'm sure, since using a hardware key in the browser triggers it.

If you have both Windows Hello enabled and a Yubikey inserted into your computer and you start the registration, Windows 10 will always bring up the Windows Hello dialog, asking you to perform a biometric verification. In my case, this will be a fingerprint reading. Your Yubikey won't be in any way active and the option to use your Yubikey won't be visible even if you click "More choices".

What you actually need to do is to press the "Cancel" button on the Windows Hello dialog. If you press Cancel, only then are you prompted to register a security key. And if the registration was started accidentally, you need to press "Cancel" both on the Windows Hello dialog and on the security key dialog.

It's just downright stupid UX. You basically need to teach the users to "start the registration and then immediately cancel it" if they want to use a Yubikey on a Windows Hello machine. If the website doesn't specify "platform" or "cross-platform" preference during registration and the user is using Chrome on macOS with Touch ID, Chrome will just ask if you want to use Touch ID or use a security key.

If the website specifies a preference for cross-platform authenticators, or there's no Windows Hello set up on the machine, then Windows will actually show the security key registration dialog without any need to click "Cancel".

There's also the issue that WebAuthn resident keys can only be managed through the clunky command-line interface. At least I haven't found a way to manage resident keys in another manner. But the clunky command-line interface is actually among the best management options - other browsers provide no management for resident keys.

I've actually considered writing a blog post griping about how stupid the experience with WebAuthn is. Chrome, Firefox, Safari, Edge, Windows, macOS, iOS. I don't think there's been any combination there where something hasn't annoyed me.

The unfortunate fact is nobody except us geeks uses Yubikeys. 99% of users prefer platform keys. So it's not hard to understand why software defaults to it.

By ensuring that whoever signs into the account has at least two distinct factors: the password and the trusted phone with the authenticator app. One thing you know, one thing you have. Perfect. (Depending on your phone's settings around biometric unlock, it might be even the trifecta: one thing you know, one thing you have, and one thing you are).

Let's imagine we implemented your suggestion of requiring the login to be on a different device than the authenticator app. What threat model does this protect against? An attacker who has your password and the unlocked phone will just sign in from a different device with the password, and then use the authenticator app from the phone. The only people you're protected against are those who do not have any access to another device than the stolen phone.

It’s literally the only reason I’m considering dumping the Gmail app. If you use an app password and the standards based mail client like imap or pop, this isn’t forced on you.

Ive also seen an increase in google flagging my accounts for some reason and I have to go and reclaim/verify them using the recovery accounts.

Apparently not, but it's always worked for me. Two things, though: 1) sites should support multiple methods of 2FA. I don't understand why many only let you have one. If I drop my phone in the toilet, I want to have a FIDO token enrolled as backup. 2) some of these implementations, like Google's, are proprietary. I want something universal and standards-based so we're not dependent on a different app for every service we use.

> But how have we increased safety when my Team/Outlook phone app requests that I click "approve" on a different app? I'm basically alt-tab'ing and clicking a different button, not really an improvement. It should be on a separate device, or something out of Microsoft's control so they can't screw it up.

You're correct, and knowing only what you've told me, I would argue this solution was implemented incorrectly.

It’s a good point though — how munch more secure is two factor if you have an unguessable password locked away in a password manager. Your single point of failure is security of your computer.

And yeah I do get the idea that if my password is actually compromised and hostilely changed, I'm going to be looking at the company for some sort of reset. But the right way of doing this is a higher friction process that could require phone engagement, in person notarization, etc. It's certainly not to make this reset process part of the every day login experience based on this mistaken idea that passwords are always insecure.

Apple and Google should just short circuit this and directly be an Authenticator as well as manage the long lived token (the password) behind the scenes, which will eliminate the alt-tab dance.

I’d love for the “something you have” to be “my laptop.” It has a TPM; we can do this securely. Something like the MBP’s Touch Bar where there is a separate integrated physical device with a screen that can make security prompts is ideal.

That said, there's always going to be compromises and annoyances - I've been using MFA for 10+ years, and occasionally something glitches out, but other things (e.g. basic password systems) also sometimes glitch out, and having an account compromised is much, much worse than a minute or two of mild annoyance.

Anything that has a single or dual point of failure is dead on arrival. Too bad you will realize only after you are locked out of all your digital life.

This compares very favourably to, say, AWS where you can only have a single second factor and the recommended(!) way of protecting against loss of a second factor is to have multiple accounts with different second factors registered to each of them.

If other people could log in as you it would defeat the point

You can then 'add more second steps to verify it's you' including an option for an authenticator app (i.e. totp). Also worth generating some backup codes while you're at it.

I'm glossing over a few things (e.g. WebAuthn credentials can be stored in secure hardware, so can be more secure than cookies), but in general, WebAuthn secrets stored in a desktop TPM, while valuable in certain applications, aren't alone a very meaningful step toward getting rid of passwords—since passwords are primarily used for authenticating on new (never-before-used) endpoints.

A slightly degenerate case is one where you use passwords to sign into your (say) MacBook, but Apple syncs the WebAuthn credentials via iCloud so you don't need a password on any other services. Which, like, if you're gonna do this—why not just use Apple's password manager and sync passwords? :)

Now I'm stuck with a decade old phone just to confirm my online transactions, and if it breaks I'm out of luck. The alternative would be to not have working online banking for one or two weeks, which I cannot afford at the moment (thanks to Covid).

All you're really saying is you want them to ship the authenticator apps to desktop platforms as well as mobile..

1. There is an encrypted blob which contains distinct authentication tokens/passwords/whatever for every website/service I have an account at. This blob can be moved around, synced and updated however I like, with zero concern about who has a copy of it.

2. I decrypt this blob locally on device, using a combination of multiple factors such as what I know (a passphrase) and what I have (e.g. a copy of a static but un-guessable and un-rememberable account key, which is copied to all my devices, potentially stored at rest inside a secure enclave).

3. The decrypted blob then authenticates me on services using data which is entirely random and arbitrary.

I could only imagine how much more perfect this arrangement could be with total industry uniformity. Imagine if a common, uniform password manager API was integrated into computers from the earliest days, and all browsers integrating this system service from the very beginning of the Web. Every website could have been built be built around this workflow, not to mention every binary application on desktops and smartphones.

The solution is a competent hardware security layer and a reasonably strong passcode, such as offered on recent models of iPhone. This is sufficient for normal people to thwart opportunistic attacks.

Of course if your adversary is a Government or a corporation that has root permission on your device, you would obviously take a different security posture.

This is because the security of "2FA" isn't really from the fact that there are two factors, but that one of the factors is kinda just ok, and the other factor is ideal. A password on top of a proper 2FA method doesn't actually add any security to the typical login flow.

> So we’re back to one factor that’s ultimately secured by a device password/passcode anyway.

Unsure of exactly what you mean here - in what way is something like a yubikey secured via a password? Also, even if that were the case, changing the scope of passwords is important in and of itself.

> Plus if/when you’re not able to access the device, it’s much more painful to deal with.

Agreed, this is the big problem to solve - essentially this is just a subset of the "recovery" problem. It's one place where passwords may still fit in, though in a different role.

Ultimately, verifying identity at scale is just extremely difficult, and there will never be a perfect solution to recovery, but I think that we can mitigate that quite well with things like:

a) Phones as 2FA devices/ recovery devices

b) Multiple devices (ie: if we can reduce the cost of hardware tokens by an order of magnitude it becomes viable to buy 2+ for many more people)

c) Slower recovery methods that involve leveraging multiple identity methods - things like validating a government issued ID, mailing address, etc.

It isn't, which makes me confused about how it is supposed to be more secure. If I lose my keys with a physical security key attached, not only do I now have to worry about somebody breaking into my house, but all of my online/digital properties as well (assuming passwords become a thing of the past). If they have my phone which has Touch/Face ID enabled, that poses a much more significant challenge to an attacker (and can maybe be mitigated if I can remote wipe the device in time).

> but all of my online/digital properties as well (assuming passwords become a thing of the past)

For sure, and that's definitely not a threat to take lightly - another thing to consider would be when the attacker is someone who inherently has physical access to you (say an abusive partner, parent, etc).

You're totally right that a password can, at least to some extent, help in these situations. Like I said, I still see a use case for the password, it's just that the scope would change - like how password managers only require you to remember one single password, and that password is essentially only used in one place. This really reduces the risk of phishing.

> If they have my phone which has Touch/Face ID enabled, that poses a much more significant challenge to an attacker (and can maybe be mitigated if I can remote wipe the device in time).

Yeah, agreed - I think biometrics can definitely be a key part of how we get to a password-less world. There's other stuff too, like if the attacker has your key, but they're logging in from a new device, maybe it asks for some other verification like a biometric, or even a password / pin - but now the password again is taking a very different, much more limited role.

All I'm really saying is that the current way things work is pretty bad. Passwords get forgotten, guessed, stolen, reused, phished, etc. Using a device solves those problems really well, and while it does have its caveats, I think the caveats are largely addressable.

[0] https://developers.yubico.com/yubikey-piv-manager/PIN_and_Ma...

I can use biometrics/sms for the less important stuff.

As much of a Science Fiction fan I am with "iris logins" and similar, I am also a retro-futurist who appreciates things like punch-number security for secured doors.

I mislike this current 2FA path of security for several reasons, the least of which is what if the email never comes or I don't have a cell phone (let alone a smartphone)? I'm screwed.

Passwords, passcodes, number pads ... seems to be quite more Human than all of this "prove yourself in the name of security theatre" these days.

It's unchangeable and externally facing. The only truly secure enclave is the things in my head, and they have the benefit of being changeable if compromised, and I can make a positive distinction of value if under duress.

[Snark warning!]

"We were compromised. Rotate your passwords, chop off your finger and change your face."

[End snark]

Biometric measurements are fuzzy, by their nature. This in turn means that for every stored biometric identifier, there is a whole range of inputs / input signals that will match. On top of that, the measurement devices are on untrusted systems.

If you can compromise the device and extract the signal sent from the sensor, you should have a near universal replay payload. Right now that is still an espionage realm threat, but as these methods become more universal, mass attacks against large populations become more and more appealing.

Archives of valid (username, password) tuples are already sold on underground markets. It's not much of a stretch to predict that (username, biometric sensor dump) archives will eventually become a commodity too.

If the manufacturers had a sense of security, they would make the sensor into a hard-wired device that takes an auxiliary value as input and combines the input with a fuzzy extractor to provide a unique key per auxiliary value in such a way that neither the value nor the biometric can be extracted from the key.

But I'm not holding my breath!

Can you provide some more information on how using Google's security prompt provides "where you are and what you are doing"?

[1] https://support.google.com/accounts/answer/7026266 [2] https://www.forbes.com/sites/zakdoffman/2020/06/17/google-co...

They all do the same basic thing: userid and password let them know who you claim to be, which they validate using one of the second factors listed above.

[1] https://tools.ietf.org/rfc/rfc6238.txt

[2] https://en.wikipedia.org/wiki/Google_Authenticator

Sure it's broken if that password is "password123". And remembering 20+ characters (minimum to be good) isn't practical.

But all that is solved problem with password managers. Generate very long truly random & unique passwords which are never reused and that is actually very strong.

She knew the password but they wanted the 2 factor on her registered device. That device was traded in.

That’s ok, the backup plan was to send a code to your phone number on record… of course this fails as well.

It can get very aggravating when 2FA goes the wrong way and people don’t believe you are who you say you are. Assuming that users will always have the same device or the same phone number is an obvious mistake.

> Google prompts

> "To stop getting prompts on a particular phone, sign out of that phone."

Well, f* you too.

I genuinely hate this idiotic future where I'm not given a choice.

I have a yubikey, a TOTP, and backup codes. Leave my phone out of this.

To disable Google Prompts and just use your YubiKey's U2F, you could enroll in Google's Advanced Protection Program. But then your TOTP and backup codes would stop working, as would any third-party apps that need access to data in your Google account.

The YubiKey, by the way, is a great hardware TOTP key, in addition to being a FIDO U2F key. TOTP has an advantage over U2F in that you can keep backup copies of the TOTP secrets. Of course TOTP is less secure because it is phishable, but U2F is a real pain because you can't make backup copies of the key.

The backup is to have multiple U2F keys. I have over 10 U2F keys. Most (but not all) providers allow you to register multiple U2F keys.

Amazon AWS for some foolish reason (in my opinion) is one of those outliers which only allows one U2F keys to be registered. I've read people's reasoning on why that is and none of it makes sense to me.

Can you walk me through your workflow with these? Are some stored offsite? Do you have to gather all your keys together when you are signing up for a new service with U2F support?

I have 4 main ones that I try to keep synced with every service. Though I usually try to sync up a few more if I have them handy.

For me those four are:

Laptop (Yubikey 5C Nano) Desktop #1 (Youbikey 5 Nano) Desktop #2 (Yubikey 4 Nano) Keychain (Yubikey 5 NFC)

I also have one in my work-laptop but it is only registered for work related sites. I also register some of the previously mentioned ones for my work related sites as a backup.

The basic idea is to have two U2F devices with with the same device_secret but one of the devices (the backup) is pre-programmed to add a large offset to the so called counter value. Upon login the service must check the counter value and ensure that the received value is greater than the one it's seen previously. If you happen to lose the first key, you can use the second key to log into all of the affected online services and upon doing so, the service would accept the new larger counter value and thereby invalidate the lost key.

For real backup resiliency, you should have at least 3 keys, one of which you keep off-site. Presumably you keep one at home and one with you. Want to sign up for a new service? I hope you're at home where you can access two of your keys to register them. Then sometime later you need to go to your off-site location to swap that key, bring it home, and get it registered also. Do that periodically so all of your services are on all 3 keys.

Unclonable hardware keys work well enough when it's for a corporate service. Lose the key? Just visit IT and have them give you a new one or overnight it. But unclonable hardware keys are a huge pain when used personally with multiple services.

TOTP secrets, while less secure, are much easier to manage. You can write them down, store them on a USB stick, or store them in an online account. You can send them in a message or even read them over the phone. Ultimately the average user is more concerned about losing access to their account than being attacked by a nation state.

Dogma: If it isn't backed up then it doesn't exist.

Don't you have a second authentication factor to login on your phone? Fingerprint, pin, faceId.

I don't see how this is worse than a yubikey.

Seems like they prefer google prompt, then SMS, then the actually secure stuff.

So whatever you're seeing is not in fact some sort of Google policy to prefer insecure SMS.

I get that this makes accounts more secure, but I'm more worried about accidentally getting locked out because my phone isn't charged/nearby/working than getting phished. I really hate it when sites take your ability to choose away, even though I understand why they do it.

I wish the EU would regulate that sites must implement U2F (with proper support for multiple keys) so at least you don't have to deal with 100 different (and usually annoying) 2FA methods (often the insecure SMS 2FA).

Just sounds like more lock-in with Google, why is this interesting?

* Google is marginally increasing security by turning on 2FA automatically for some accounts

* Google's password manager has a new "import" feature

Based on the title, I expected maybe some radical new developments in WebAuthn or similar password-replacement technology, not incremental improvements to Google's products that benefit only Google users.

Because people should know what Google is actually doing.

GitHub is going down this road, too, announcing that they will soon disallow password-based auth on git operations.

I'm not sure if I will keep using it after that, because having to log into the website from every workstation, some of which may not even have a browser "good enough" for github.com, is more extra work than I'm willing to attend to.

They do allow you to generate OAuth codes with scoped access , which effectively acts exactly like passwords just giving more control to you and ensuring your account is safe.

I don’t think GitHub’s implementation is ill intentioned at all,

When compared to Google’s where it’s now effectively forcing me to keep using the gmail app Because of these prompts

:/

This post is just marketing.

I thought I'd try adding a 'Security Key'. There was an option named 'Google' so I chose it to see what it meant.

I was immediately presented with:

    Success! Security key added

    Your Google security key was added to your account.

    When you sign in with 2-Step Verification, you'll use your
    password and your Google.

    Make sure that Bluetooth and Location are on.
    When you're signing in, Bluetooth & Location are needed to
    check that your devices are near each other.

    Bluetooth pairing isn't required.

    Works only on Chrome
    Built-in security keys currently only work on Chrome

I'm guessing this is related to the Google phone app, but if I go to add another security key I can see 'Google' is now disabled and it says next to it 'Last seen 8 February' ... but I've opened the Google app on my phone more recently than that, because I've used it for 2FA for this Google account before!

I don't understand "Works only on Chrome". Is this saying I can log into Google on Chrome (desktop) by using the Google app on my phone?

I've got 'Authenticator app' set up already (not using Google Authenticator - you can use the code it provides to add to Authy or 1Password or whatever you like).

I also have backup codes as a paper copy ... so I think I might now be safe to remove 'Voice or text message' as a backup option, but I'm still wary of doing so.

Passwords suck and we need a per-site password policy that can act like an API. Kind of like a Robots.txt, to declare, "This site needs 8-20 characters, 1 symbol and the URL's for login, reset and forgot password are these URI's."

1Password (and iCloud Keychain, maybe?) can read these off of the input element and use them when they calculate the password.

shrugs

Most apps are not significant enough that people will go through the pain of checking their emails to get the new temporary password

Also , a lot of email clients still use STARTTLS while communicating with mail servers to fetch emails , which means a MiTM can reduce that connection to plain text (isp’s have been caught doing this before to read people’s emails) and then steal your password.

A site that enforces a rule like that must guarantee that its user’s email server only allows TLS only handshakes on client side (which is difficult if not impossible to do 100% of the time)

So even if the idea is great , due to the state email is in , it’s pretty risky and unsafe to MiTM attacks and network inspection.

In particular, the only two threats that 2FA as widely implemented on websites protect against are password reuse, and weak passwords. Both are the results of users choosing stupid passwords.

I really hope you don't work with users or are doing anything that affects them. Users are not stupid, they maybe lack understand or are lazy and things are inconvenient. But the world is easier if you can just pass of your responsibility to the ominous "dumb user", isn't it?

I agree. We can improve it so that others don't have to think about it and it actually solves their problem. Right now we pretty much just move the responsibility to the user.

Make the password unique and >128+ bits of entropy and that's all that is needed. At that point it is as strong as a shared AES key.

If we make them be pseudo sentences they will probably be easier to remember (the $adjective $noun $adverb $verb a $adjective2 $noun2)

Here’s some more ammunition for your argument though: https://www.csoonline.com/article/3272425/11-ways-to-hack-2f...

However, this feels more like having your sheep be herded by a fox...

Many here have already mentioned great points retorting this, so I won't beat a dead horse.

I will take the selfish opportunity to mention what my solution is that I'm working on: https://app.SrsPass.com

There's some rudimentary docs with a spec outline for those interested. But to sum it up, I share the same fears as others here of one device being some ultimate honey pot, or even worse, losing everything I have due to corruption or losing a/all devices where your pass vaults are when it comes to traditional managers. (Mind you, this coming from someone that runs RAID-Z3 NAS in multiple offsites).

Basically to keep it simple, I required the following aspects

- Available-source or Open-source (duh)

- Accessible on just about any device with a cpu, arm/x86 etc

- Vaultless & as stateless as possible

- No cloud, works completely offline

- Uses modern cryptography with sufficiently strong parameters

- Requires only one password to memorize

- Has uncrackable generated passwords (aka not feasible to crack in a long time period such as with 128 bits of entropy).

I believe SrsPass to meet all those aspects already. That is not to say that there aren't more features being worked on (the workboard is essentially public), however, I think you'd be hard pressed to find a more secure (when you build & run yourself) and accessible password manager than it.

The key element that didn't make your list is phishing. The next threat to Joe Average once he isn't reusing a crap password is phishing. Joe goes to a site which he thinks is the right place but it isn't, it's actually run by bad guys and then Joe gives them his credentials and helps them break into the real site Joe thought he was visiting.

Better passwords make no difference to that. Some types of password managers might slow Joe down a bit, as he needs to override a default presumption that this is the wrong site, but since the site has tricked Joe already this is very fragile. TOTP makes no difference, SMS of course makes no difference, and even the Google Auth tech AFAIK makes no difference.

But WebAuthn just stops this attack dead in its tracks.

WebAuthn does have its own issues and complications, mainly with how to handle account recovery on a lost or corrupted device. Sure, you can have a replacement device, as likely me and you try and do for most things, however, this is too burdensome for many.

I think the biggest issue with any new spec like WebAuthn is vendor adoption. As is... many banks fail to have any 2FA, and those that do, give you the terrible choice of SMS 2FA. In addition, they have odd and archaic password requirements, such as only these symbols, and only up to 20 characters etc... If they have failed on rectifying these in the last 2 decades, I'm afraid how far in the future away something like WebAuthn is to being in realized use. Hence I made SrsPass as hopefully a solution to today's passwords problems, the ones I considered sanely resolvable.

https://storage.googleapis.com/gweb-uniblog-publish-prod/ori...

Imagine being locked out of your house and bank accounts because your Google account got suspended. Maybe Google could introduced an account protection service for people worried about this happening - for a small annual fee of course - and unofficially turn it into racketeering.

Watches are better this way because you don’t ever set them down (and they’re cheaper), but I suspect pickpockets have some things to say about those magnetic clasps.

Something in your wallet or with your keys would be best but then you can’t interact with it easily. Those little physical security tokens you’d put on your keychain were always a PITA.

Then again, your Mac already has a TPM chip you can use.

But the only way to manually add one password is to craft a custom CSV and upload it.

I feel like a baller remembering my complex ones for important sites and other mechanisms for simpler sites - it might take a few attempts sometimes but it feels good and I can do it anywhere without requiring additional forms of auth

Thank you Google, but I'd rather keep my password than you worry about my logins. You don't know how valuable this account is to me, and what kind of protections I want for it (it's an account I use solely to set up play store on my otherwise de-googled phones).

> You'll enter your password [...] Then, a code will be sent to your phone via text, voice call, or our mobile app. Or, if you have a Security Key, you can insert it into your computer’s USB port.

https://www.google.com/landing/2step/#tab=how-it-works

I think I'll just stick with my FinalKey which I can build extras of and which can store the encrypted database and backups offline.

I am using 2FA with backup code stored and using unique generated passwords for each service

It's not easy nor simple but still better than trusting Google that offers "free" service and wanting "something" in return

Firefox also introduced a feature that offers to generate a secure password when it detects a sign-up page.

No, thank you, especially if Google is going to be the gatekeeper.

https://github.com/pcarrier/gauth FTW

It’s just a blog post about Google patting themselves on the back for how ‘awesome’ they are at keeping your passwords safe, and promoting some of their recent and upcoming tech to help manage passwords.

You are not the first to twist the meaning of words.

SQRL also requires users to get some additional software in order to work. Of course (this being Steve Gibson) that software is perpetually unfinished and buggy, and may not even be available for your browser (e.g. Safari) - but the next version will always be great...

But then unlike WebAuthn SQRL's anti-phishing protection is marginal, it might work, unless it doesn't work, and then it's your fault for not carefully matching things, a task machines are good at and humans are bad at.

Use WebAuthn.