171–180 of 227 posts
Why don't web browsers have good password managers (like keepass or bitwarden) built in? It seems like a good solution would be to make random password generators more usabile than to throw out the baby with the bath water.
Am I the only one who doesn’t want a future without passwords? There are problems with them, of course, but all the alternatives also have serious usability/security issues. And just when we’re starting to get wider 2FA adoption, companies want to get rid of one of the factors. So we’re back to one factor that’s ultimately secured by a device password/passcode anyway. Plus if/when you’re not able to access the device…
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.
I don't trust Google to fill this role of being arbiter of access to things. 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 fou…
I had to invest 50 € to buy back my old phone number for a week to get to my old Google account. I had password, backup email address, could answer the questions. But the google bots insisted on sending me a SMS to a number that didn't existed. There are many points where I lost trust in google, and this was one of them.
Somewhat controversial opinion: The biggest problem with passwords is that users select them, and users are stupid. We would get 95% of the benefit of 2FA (For forms of 2FA that aren't yubikeys, as yubikeys have benefits related to phising, but nobody uses them so its moot) if websites chose passwords for users instead of the user choosing the password. In particular, the only two threats that 2FA as widely implement…
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.
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.
Earlier quoted context omitted.
Your laptop (probably) already supports FIDO2 with your TPM, now it's a matter of Google (and others) implementing it.
They have it already in WebAuthn in a completely siloed way. That is, they only implement hardware token support and if you want software tokens, they will make your life painful.
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? :)
Earlier quoted context omitted.
I've yet to run across one browser / operating system combination where WebAuthn is implemented well. Stuff like assertion interface not showing up if you have two authenticators present. Browser and OS vendors should really fix their shit before any mass WebAuthn adaptation happens.
What don't you like about the Win10 + Edge implementation?
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.
Earlier quoted context omitted.
Personally I think the basic building blocks of the password manager workflow is pretty damn close to perfect. Maybe the contemporary password manager could be refined further, but I do like the building blocks: 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,…
In your system, doesn’t security still just come down to the passcode of your phone and physical access to it? With access to your phone, the attacker will have access to your email, which will likely allow them to reset the password on any account.
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.
I don't trust Google to fill this role of being arbiter of access to things. 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 fou…
Can you share the incantation that summed a human, for future reference?
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 - 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).