1

Hey everyone, I was just reading David Berlind’s article about passkeys over on ZDNET (If We Want A Passwordless Future, Let’s Get Our Passkey Story Straight ) and, I’ve got to say that, by now, I have read dozens of articles extolling the advantages of passkeys. But NONE of the articles (including his) talk in depth about the many “edge cases." Minimally, I’d like to see some answers to the following questions. But I’m sure there are others.

  1. What if the device I saved my passkey on breaks and can’t be repaired? Do I lose access to all my accounts whose passkeys were only on that one device?

  2. What if the device is stolen? How do I prevent the thief from exploiting the stored passkeys?

  3. How do you establish passkey access from a 2nd or 3rd device that you own? Does that require use of a password to establish a new passkey?

  4. Do passkeys have any role if you’re using a borrowed device (e.g. at the library, or a friend’s house)? Or does that kind of access require passwords once again?

  5. Can I delete passkeys from a device I want to sell or trash?

  6. Passkeys may improve security and convenience, but unless and until websites allow you to (or require you to) completely eliminate passwords, then don’t we still have a security vulnerability?

9 Spice ups
2
  1. depends if there is any other form of access to those accounts
  2. entirely dependent on the security used to protect the passkeys on that device
  3. just like the first time - yes typically use of password and MFA
  4. intended for use on a device that is yours or you have your own unique (secured) profile on
  5. yes
  6. yes

worked example on my personal windows 11 laptop:
I have may sites/services for which I use passkeys.
To set these up I have to sign in the the service using ‘standard method’ u/p + MFA then a passkey is created.
passkey secure on the OS using windows Hello (which uses the TPM to store them)
If device is stolen - they are only secured by windows security - i.e. if someone knows my PIN/password they have access to everything.
This is why I use a hardware FIDO usb key for key individual services that I want to protect further.

7 Spice ups
3

you forgot to ask how a passkey is any different \ better than a unique long random secure password?

4 Spice ups
4

Best answers I can give from my only basic understanding from using them for accounts like Google and Sophos.

  1. IIRC, Apple, and Google (and maybe Microsoft, I’m not sure as I only use my phone for my passkeys) all back up your passkeys to your account by default.
  2. As m@ttshaw said, depends on the security of the device - if you can remotely wipe your phone and/or it’s protected by a strong PIN or password, and set to auto-wipe after a certain number of attempts, then you should be safe. Also, at least on Android, you have to authenticate with your biometrics a second time to allow the passkey to be used.
  3. Four options:
    a) Sync the passkeys between your devices via your Microsoft/Google/Apple account (or third-party password manager like Bitwarden)
    b) Use a physical hardware token like a Yubikey instead of a PC or phone (these have a PIN you can set on the device via your PC to add a second factor for Passkeys, can be edited via the Windows Settings app, at least on Win10)
    c) Set up separate passkeys on each device
    d) A PC can use the passkey stored on your phone over a Bluetooth connection by just scanning a QR code on the phone (though scanning the code is only needed the first time as you can choose to save the connection if it’s your own PC)
  4. See 3d above - just don’t save the connection to avoid registering your device to the PC to connect without the QR code
  5. You should be doing a factory reset wipe/erase, which if done properly should clear the TPM (or equivalent) where the passkeys are stored.
  6. I think we’ll probably be in a transition period for a while, but while business-class PCs are still getting built without wireless cards for mobile QR auth, Password + TOTP/push-notification will still be in use as a backup for a while yet.
1 Spice up
5

Passkeys (and FIDO2 security keys before them) are considered unphishable unlike a password or OTP code - passkeys can only talk to the real website due to the use of public/private key cryptography.

And as you are required to enter your device’s PIN or biometrics to unlock them as they’re stored in a TPM/Secure Enclave/etc., they’re considered 2FA (have (the device with the passkey on) + either know or are)

2 Spice ups
6

interesting.. what about the case of using a password manager to store them? such as bitwarden?

2 Spice ups
7

I am not a fan of passkeys whatsoever, and I think it’s weird how aggressively they’ve been pushed all of a sudden within the last 6-12 months. Nobody I know in the industry likes using them. I do not think passkeys will become the new perfect security standard that they’re being heralded as.

2 Spice ups
8

I also find them annoying.. its fine to have as an option but so many sites now try to force one down your throat on login… every time…

2 Spice ups
9

An additional edge case: I worked in an environment where we used reboot to restore software on staff machines. We did not encourage the use of passkeys since staff could not make changes to their computers.

“how a passkey is any different \ better than a unique long random secure password?”. Passkeys do not share a ‘secret’ with the server. In the case of user/password combinations the server has to know both for validation. And this is what makes them less secure. Poorly protected credentials on the server side are compromised by hackers regularly. Passkeys address this particular issue.

3 Spice ups
10

Hi @rtrauth2 … could you offer more detail on the edge case you identified? What do you mean by “the staff could not make changes to their computers?” Where do passkeys come into that edge case? Based on all these questions, I’m going to write some more articles to address these edge cases.

11

@molan Most of the time, we hear about the end-user benefits. But there are benefits to relying parties as well (which is another reason they’re pushing them on you). One area is reduced support costs. The way the thinking goes, as the passkey experience becomes more frictionless and consistent (especially vs. user IDs and passwords), the lower the support costs will be. But in their present state, my guess is that they’ll cost more to support.

2 Spice ups
12

@itskieran @molan actually… it’s not required to enter the device’s PIN or your biometric. For example, you can configure BitWarden’s inactivity period to last for a long time (which means that PIN or biometric is not necessary for every authentication workflow with a relying party).

1 Spice up
13

Hi @davidberlind,

Because staff computers were configured with reboot to restore software any changes made to the system would be wiped on a reboot including potential changes to TPM.

We setup our computers with all system settings and software configured before installing Deep Freeze from Faronics (There are other reboot to restore options such as Reboot RX that do basically the same thing as Deep Freeze). While staff could make some minor changes to their computers (things not locked down via a policy) they would not remain resident after rebooting because the Frozen (in Faronics parlance) computer would revert to its pre-changed state.

Computers would need to be temporarily thawed (again in Faronics parlance) to allow for a permanent change. The Faronics Data Igloo product does allow for data to remain on a system with Deep Freeze in a frozen state, but since I haven’t used that product I am not sure how it would interact with changes to the TPM.

We were (I am not longer with this employer, hence past tense) in the process of rolling out 1password that can save passkeys without having to make changes to deployments using Deep Freeze.

Deep Freeze does not, in and of itself, store passkeys so other methods or configurations must be considered when using this product.

1 Spice up
14

honestly, these edge cases don’t get talked about enough. A few quick thoughts:

  1. If your only passkey was on a lost or broken device, and it wasn’t synced (like via iCloud or Google), yeah, you could be locked out unless there’s a fallback method.
  2. If your device is stolen, passkeys are tied to biometric or device PINs, so someone can’t just grab the phone and log in — unless you left it unlocked.
  3. You usually add passkeys to new devices by signing in with a password or another passkey. So yeah, passwords still have a role.
  4. Borrowed devices typically mean falling back to a password or MFA — passkeys aren’t portable in that sense.
  5. Yep, you can delete passkeys from a device in settings before you sell it.
  6. Totally agree — until sites go full passwordless and enforce it, passkeys are just one piece of the puzzle.

Hope that helps a bit!

1 Spice up
15

OK. Now I understand @rtrauth2. Thank you and yes, I could see how that presents a challenge. But it sounds like your olld employer has done the right thing by electing to use a password manager to store your credentials in a software vault rather than the TPM. Then, it’s just a matter of reinstalling the password manager, logging back into the user’s account, and re-synchronizing the user’s previously established credentials to the system.

16

@davidberlind

The password manager certainly has been an important step in reconciling this problem in the office. The other benefit of storing passkeys in the password manager is that when using multiple devices you aren’t creating multiple passkeys for each hardware device you use.

For example, if I use Windows and store a passkey in TPM, and then logon to the same site from macOS it asks me to save the passkey again. In the case of storing it on the Mac it is going to store that passkey in the Mac’s secure enclave.

This presents the potential of creating multiple passkeys for the same site; one passkey for each device. Doesn’t seem to make sense to do that. Almost everyone I know uses multiple devices, and other than office environments most do not use password managers, and most do not understand the concept of passkeys. So, this could be confusing to many less tech savvy users who don’t understand why they are ‘always’ being asked to save a passkey again.

2 Spice ups
17

@rtrauth2 I could not agree more with the potential for confusion. In fact, it is that very confusion that was the inspiration for all the articles that I’m publishing on ZDNET because, as it currently stands, users will have to educate themselves on a variety of nuances (only one of which is the syncable passkey that’s not stored to an enclave vs. a non-syncable passkey that is stored to some sort of enclave/tpm/etc).

Some of these complexities are not going to change which means that, as much most of us would rather not, we not only have to build up our passkey expertise, we have to advance-plan a strategy. For example, know the pros and cons of syncable vs. non-syncable passkeys and then decide which is best for you. Some people might like the idea of passkeys that are not synced through the password manager’s central cloud (or other equivalent central resource).

But I think you make an important point about the user experience. Just the idea that you might get asked to create a new passkey and save it (after already having done so) will be very confusing to many users who are used to working with passwords. After all, regardless of which device you are logging-in from, it’s always the same user ID and password for a given account. The allowance for multiple passkeys per account is both a blessing and a curse (and most definitely, a complexity!). Thank you for providing your thoughts. They will help me to shape future editorial.

5 Spice ups
18

@davidberlind Your points are well taken. The complexities are what will trip up most average users. In my work experience, I had some users blindly clicking on the option to create a passkey when logging in using username/password, simply because they thought they had to, not because they understood what it meant. I absolutely agree with, “…we have to advance-plan a strategy”; this is imperative if users are to successfully manage and control their credentials.

In my experience, end users don’t understand the difference between user/password logon vs. passkey logon. Most could care less as long as they get successfully logged in. One would hope that those who have been around since the early days when usernames and passwords were first introduced, having been carried along by ever more complex password requirements and MFA requirements, would be more astute to the value in moving to passkeys. However, those that I have talked with just don’t understand it. Most blindly go along with it because it seems like the right thing to do, not because it is better than what they have been using for decades.

I spend a lot of my time educating people on why using a password manager, creating complex passwords, and using passkeys is good idea, but as the saying goes, “You can bring a horse to water but you can’t make it drink”. I know so many people who will not use more secure options simply because they don’t understand the technology, and thus are under the misconception that something they don’t understand is inherently less secure.

1 Spice up
19

Yes. but you can also configure it for a short time, which any enterprise customer will do if they don’t trust the initial SSO on computer startup as secure enough.

Lots of security settings are not required but it doesnt mean they can’t (and should be) be implemented as standard.

All you are doing here is picking holes for the sake of it when every single one of your points has a solution (and are only really valid if IT ignore best practice), and others like your assumption about support costs have no factual basis whatsoever.