I’ve been 1Password since its inception. I’ve got the whole family using it as well, which is really practical, on Mac, iOS and iPadOS
BUT…
Ever since 1PW8 and their transition to Electron, it’s been an exercise in frustration - mostly on the Mac with Safari:
Very frequently (80% of the time, if not more) 1PW for Safari won’t for recognize if 1PW is unlocked.
Just as frequently, Passkeys are not recognized. Instead, I get the QR code overlay, which kind of defeats the purpose.
clicking the “unlock” icon in the password field is usually ineffective - I need to click the icon next to the address bar.
Sunk cost fallacy, I just don’t have the energy to move the family over to something else. I keep thinking it will improve, but …
I’ve been using 1Password for a couple of years, and I’ve never seen this “QR code overlay” and wouldn’t know how to enable it. Is it some sort of setting?
I am also puzzled by this statement. What are you seeing, and is it related to the passkey that was stored?
I’ve only seen QR codes implemented in 1PW in relation to setting up 2FA codes for passwords, and really not even there because sites using OAuth for that are displaying a QR code that 1PW can read to take in the long string of characters; and to display a WiFi password access code for others to scan.
Not denying what you’re seeing, of course; just wanting to know more detail about what you are seeing.
Interesting…I’ll have to keep them in mind if I ever decide to leave 1PW…although as I said I’m staying on v7 as long as I can because I can use DropBox.
Just a data point that might be interesting. I’m still using 1Password v6 on Sequoia. The browser plugins quit working long ago but the other features still work. Given how long v6 has continued to work with macOS upgrades there is a good chance v7 may be all you ever need.
1PW v6 was released in 2016–the same year as macOS Sierra.
Good to know. I actually have a subscription so could switch to v8…the only heck no issue for me was the lack of ability to do a local user based backup,and restore but they finally admitted how to do that. I prefer DropBox but using their server is ok now that I can backup/restore. The v8 app isn’t macOS native, it’s one of those Elektron (or whatever it is) things…but I don’t use the macOS app much, just the autofill or auto select of an entry via LaunchBar or the browser plugin that lets you select which one to use. But v7 ain’t broke so it doesn’t need fixing.
I’ve been using 1P since the time when they used Apple’s cloud storage. When they went to their own cloud storage, it forced me to take on their subscription model IIRC to keep family sharing. Overall, I love the app, but it does not function 100% perfect all of the time; I would say probably 98%. The most common failure that I see is the “Open and fill” function. Many websites expect one to click on a LOGIN button and 1P can’t seem to do that. I find this easy to work around. I use 1P mostly in Safari, but occasionally in Chrome.
While I need to word this tactfully…I sometimes put off a necessary upgrade because my dear TTalk friends fret about things like “it’s not a native app” or “I can’t use X with it”. Controversially as I’m well aware, the Microsoft Office suite is anathema for some because of the subscription model Microsoft adopted. When my standalone version of Word just got too crufty to work well (I think I bought that license near the turn of the century!), I finally bought in to Office365 and discovered that…it was not awful.
1Password is like that. I clung to my v7 standalone license for three years, but ultimately decided to give in when I was offered a subscription on terms I couldn’t refuse. My data are now in their cloud instead of Dropbox’s cloud. And the interface bears no resemblance to the horrors I was given to understand lurked there. In many ways it is more pleasant and easier to manipulate than the ancient, stark structure of earlier versions. I see no penalty for it being built in Elektron vs. something like Swift (if I even understand what the objection is, or is it something else?).
I freely admit that I may have simply spared myself the pain of early adoption, but if as @mtrodgers99 Michael says the interface works correctly 98% of the time, and the underlying data are protected 100% of the time, I am absolutely fine with 1PW8.
I’ve got a trans-device, cross-platform password manager that organizes my information and is immensely helpful in setting up/maintaining myriad log-ins.
I’ll second Matt’s message. I had put off an upgrade to v8 as well, due to discussions here. I finally bit the bullet when v7 was unable to fill credentials via the Safari plugin on multiple websites (United Airlines and Chase Bank were two in particular that I recall).
The upgrade to v8 was painless and I don’t have any complaints.
here you go - basically what seems to happen is a conflict between 1PW and MacOS, where the trigger (for lack of a better word) for the Passkey brings up the OS-generated QR code.
If I cancel, I’m back to square one. If not, that kind of defeats the purpose.
in other instances, I have both the QR code and the Sign in modal from 1PW, but of course, canceling one means I can’t use the other… or something went wrong!!
I’ve been testing passkeys on Google recently and haven’t run into this. When I sign in and it detects my passkey, I just get the 1Password dialog. The QR code dialog has come up in other situations when the passkey isn’t available on the Mac so it has to go to another device that has it.
Thanks for the screenshots and description. Like Adam, I haven’t run across this either with Google.
The QR code as I understand it is passkey-related but is a 2FA challenge. The 2nd factor in this case is another device (something you have) that is known to your Google account.
It appears that just having the passkey on one device (via 1PW) is not enough for Google to authenticate you. Have you tried using this or the “try another way” link to move forward through this?
Again, forgive me if I’m misunderstanding the issue.
As I understand passkeys at this point, no 2FA challenge is necessary when you use one. Passkeys rely on the theory of possession (do you have the device?) and presence (are you physically in front of the device?). The private key can’t be phished, copied, or used remotely, and you must be physically present to unlock your device. Nor can you be tricked into providing a passkey to a malicious website.
That’s not to say you’re wrong—Google may still be doing this as a 2FA challenge for reasons I don’t understand.
Where I get the QR code is if I use a browser that isn’t connected to Passwords or 1Password (both of which contain a Google passkey). In Opera, for instance, it’s the only way to log in with a passkey.
But possession of which device? My understanding is that the QR code is because, in that instance, it wants to know about your possession of the passkey on a phone or other device.
That’s what I’m thinking. 2FA may have been enabled to work with passwords, and it’s still being triggered (inappropriately) in response to a passkey. It would explain why there’s no logical way past it.
On its face, this is exactly what Apple does when I’m trying to log into anything to do with my AppleID; it will ask me to go shag my iPhone (or, comically, send a 2FA code to the same device I’m using for login). It will also offer a “try some other way” link if that’s not possible.
But that’s with passwords, not passcodes. I don’t understand why Google would need it for the latter.
The device on which the passkey is stored or accessible. If you’re using Apple’s Passwords, that means the device with the Secure Enclave in which the passkey is stored. If you’re using 1Password or another password manager, it means a device on which the passkey is accessible after authenticating.
It is highly unlikely that the passkeys themselves are stored in the Secure Enclave. While I don’t know the specifics about Apple’s processors, security chips typically don’t have enough storage to hold the amount of data that would be required to hold login credentials for every web site you visit.
More likely there is a file somewhere on your SSD holding all your login credentials (maybe one of your keychain files) and that file is encrypted using a key stored in the Secure Enclave.
MacInTouch recently posted a link to Apple’s Platform Security Guide which—among other stuff that will be interesting to anybody who’s into privacy and security details—might contain information on where macOS/iOS/iPadOS store passkeys: https://www.macintouch.com/post/47027/apple-platform-security-guide-2/
I got curious, because “Passkeys” aren’t mentioned in the Platform Security Guide, so I went digging. They’re in the Passwords app, and they’re saved to the iCloud Keychain (but they’re not visible from Keychain Access). The PSG does go into some detail on the security around the iCloud Keychain itself.
Just as a Passkey stored within 1Password can be used across devices (assuming access to 1Password in a method where the Passkey can be accessed), a Passkey stored within the iCloud Keychain via the Passwords app can be used across devices. This implies that Passkeys aren’t directly involved with the Secure Enclave, but I believe that the Secure Enclave stores the key(s) used to unlock the iCloud Keychain (and thus have access to the Passkeys) using the device biometrics or passcode/password.
From the dialog:
Passkeys are digital keys saved to your iCloud Keychain. They
are backed up and sync across all of your Apple devices. You
can use a passkey to sign in to apps and websites on iPhone,
iPad, Mac, Apple TV, Vision Pro, and web browsers on other
platforms.
Passkeys keep your accounts more secure than passwords
do. They use powerful cryptography, which makes every
passkey strong. Unlike passwords, malicious websites cannot
trick you into giving away your passkeys.
You sign in to apps and websites with passkeys differently
than you do with passwords. When prompted to sign in with a
passkey, you use Face ID, Touch ID, Optic ID, or your device
passcode. Your biometric information and device passcode
are never sent to the service you’re signing in to.
