SN965 and SN966: Passkeys vs Passwords

  • SpinRite v6.1 Release #3
    Guest:
    The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
    /Steve.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!

    /Steve.
  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)

ptdotme

New member
Oct 24, 2023
3
0
After all the passwords vs passkeys discussion in episodes 965 and 966, I'm still unsure of why and whether to proceed with a migration from password+TOTP to passkeys. Here are my unorganized separate thoughts. I hope someone could point out some benefit of passkeys that I've missed.

One thing that wasn’t really mentioned in those SN episodes is that passwords are strongly hashed, presumably at least with an account-unique salt, on high-value websites like Gmail, banks, iCloud, etc. SN listeners are likely to use very strong passwords — so even in possession of a password hash an attacker would have a hard time actually cracking its password. At the very least, attackers would have to selectively target individual accounts for expensive password cracking.

If a website is not salting and hashing passwords properly in the first place, how likely would it be to implement passkeys? Maybe someday they would, but for now passkeys don't seem like they'd replace many poorly-implemented websites' passwords.

It seems to me that a passkey in a password manager vault is a "single factor." After a password manager vault breach (like LastPass) using passwords with a separate 2nd factor (separate TOTP or hardware dongle) seems more secure than single-factor passkeys. Or have I missed something? Are passkeys stored in a compromised password vault more secure somehow than the passwords in the same vault?

In summary, though more convenient, I don't really see how passkeys are that much more secure than password+TOTP on either the client or sever side. If a website’s password store is breached, passwords are protected with salted hashing (a passkey is better, but a strongly hashed long unique password is still relatively safe). If a password manager vault is breached, accounts would be safer with a separate TOTP/dongle 2nd factor than with a passkey alone.

For now, passkeys seem like a good way to greatly increase the security for users who otherwise don't use a password manager. I'll experiment with passkeys for a few low-value accounts but it seems too way early to start moving all my accounts to passkeys.
 
Last edited:
An even bigger question is what likelihood that a site will properly purge your old password related info when you change from one to the other. I'm guessing too many sites will just mark it inactive, but not purge it. So if your goal is to prevent leaking if the site is hacked, then you may not actually be achieving your goal.
 
  • Like
Reactions: ptdotme
As far as Passkeys being better than password+TOTP, the discussion is not including how Passkeys are stored (Or at least, assumes they're stored on the security bit on your phone, for example, not in a password vault that can be relatively easier to steal).

In my experience, I almost no sites I use even support Passkeys (and most that do, treat it as a 2FA)
 
An even bigger question is what likelihood that a site will properly purge your old password related info when you change from one to the other. I'm guessing too many sites will just mark it inactive, but not purge it. So if your goal is to prevent leaking if the site is hacked, then you may not actually be achieving your goal.
I guess you could change your password on the site, then switch to a passkey for that site, then delete that password (and the password's history!) from your password manager. Yes this is such a headache it doesn't seem worth doing until we know for sure there's some real benefit.
 
As far as Passkeys being better than password+TOTP, the discussion is not including how Passkeys are stored (Or at least, assumes they're stored on the security bit on your phone, for example, not in a password vault that can be relatively easier to steal).

In my experience, I almost no sites I use even support Passkeys (and most that do, treat it as a 2FA)
It does seem more secure to use Apple's built-in passkey storage, and Apple probably has things locked down sensibly, so that's probably what I'll use when I try out some passkeys here and there. But from what I've seen in Apple's passkeys documentation, the secure enclave doesn't store the passkeys itself. Passkeys can be synced, for example, to my Mac. There's some sort of iCloud vault syncing going on but it's more of a black box than a standalone password manager.
 
I guess you could change your password on the site, then switch to a passkey for that site, then delete that password (and the password's history!) from your password manager. Yes this is such a headache it doesn't seem worth doing until we know for sure there's some real benefit.
You could always get the password reset through email too. Unfortunately, until the passkey replaces the password fully, with no fallback to the password, we are not getting any more security from passkeys.

The discussion was interesting though, as using a 3rd party passkey storage makes the passkeys portable between ecosystems, which is key to widespread adoption.
 
  • Like
Reactions: Steve