Hacker News Reader

Comment by account-5 | Hacker News Reader

I will probably use passwords until I am forcibly unable to. I'm happy with my password manager.

Tying login credentials to a hardware device that can easily be lost or stolen, and that (at least from my understanding) are hard to transfer to new devices seems like a risk I'm unwilling to take. And a step back.

I'm not adverse to replacing passwords with public/private key cryptography, but I need to be in control of it (not some multinational org) and I don't want it tied to a single hardware device.

View on HN

I have 2 yubikeys and always register them both. So if one is lost or broken then I still have another to log into sites.

As for theft, if you’re using your yubikey as a 2nd factor then they still can’t log in because they don’t know your password. If you’re using your yubikey as both factors then it either has a PIN or biometrics, so the thief can’t log in.

My main use for my yubikey is for SSH. I have PIN-protected SSH with a private key that can’t be exfiltrated

sudo, screen lock, luks, ssh, pgp, weblogins, keepass are all setup with yubikeys. I wish I could generate my own private fido key in similar way as pgp.

This is what I would require before migrating. Opensource local only Fido key generation.

But like I said in the comment below, I suspect these vendors are only here for vendor lock-in and targeted advertising. And the websites enabling webauthn are likely to require you to use a vendors app/service. Like banking sites today not allowing me to utilise keepassxc totp functionality trying to force me to download their app or SMS.

Yes, I think it would be great to be able to create the key otuside of the physical hardware token, just like you can do with the GPG applet on the Yubkey. Store the original on some offline, encrypted media, ideally in multiple places.

This way, you don't need to have two yubikeys on hand and register them both on every new site. But in case you lose, it's not impossible to create a new one. Yet, obtaining the key from the hardware token shouldn't be any more possible than with the current system.

These two goals are mutually exclusive. If you let people generate their own key material outside the enclave, people will be emailing it to themselves just in case.

Well, non-stupid people also use yubikeys, so they are not mutually exclusive

Maybe, but there are also a lot of people who don’t understand the point of yubikeys that want to use them but export the secrets. Those people cannot be trusted with their own security and need to be protected from themselves.

Nope, let them be burned, the sooner the better, before they own something actually valuable behind the account

What a truly psychopathic take, I really hope you’re not making decisions that effect people.

I have the same opinion of people who want to control others because they "need to be protected from themselves".

So I take it you’re against food safety standards, seatbelt laws, taxes on cigarettes, the clean air act, payday loan reforms, etc.

Most people will never understand this subject, and the fact that they don’t need to is a good thing. If you want a hobby, great, you can go figure out how to do that. The default needs to be safety.

No one mentioned exporting keys, but importing to yubikey (one way) same as it is already done with gpg on air gaped machine versus generating fido private key on reset within yubkey itself.

1) yes they did, I suggest you look again. 2) That’s the same thing. The end state is wanting the key material outside of the secure element, which is foolish.

Software-based passkeys can do this! Bulwark Passkey (https://bulwark.id) is a virtual Yubikey-like device, and you can back up the credentials file however you like.

I have two yubikeys too, but I definitely found services which didn't allow me to register more than one when I first set them up (a couple of years ago now).

Not sure how it used to be, but the only braindead implementation like that I’ve seen was AWS.

They fixed this a few weeks ago.

They announced a fix but it hasn't rolled out everywhere yet -- it requires converting to a new "Amazon Web Service" login that is separate from your normal amazon.com account

Oh cool, this has been my number one complaint about AWS credentials management since early 2016 or so. Over the years I've talked to a number of their project and program managers and until 2019 (that is, before the plague) they all told me that they were aware of the problem but had no plans - or even intent to fix it. Apparently the one-set-of-credentials constraint is so deeply tied into their platform that fixing it was simply deemed infeasible.

Appears that while they couldn't fix it, they have gone ahead with a workaround and made multi-device 2FA support a feature in a potential auth replacement system.

Must have been a particularly frequent and loud complaint.

The elephant in the room is that this just isn’t feasible for “normal” (non-IT) people, and those people are usually the ones who need strong protections, as they’re the ones with bad habits like choosing bad passwords, reusing passwords, forgetting them, etc.

I'd think password managers would be fine here. Also, don't fuck up other user's experience just because average one is clueless...

I use a password manager too. The yubikey is usually my second factor

You’re totally right. I never recommend Yubikeys to non-technical people

I bought four yubikeys back in 2012, two pairs as recommended - one in use, one backup. At the time Yubi had a video up of their keys being run over and otherwise maltreated, and still working.

One of my keys failed spontaneously after a just few weeks in my pocket, on a ring with my other keys.

I decided to stop using yubikeys. A password manager has worked very well for me ever since.

I’ve had one on my keychain for at least 5 years now with no issues. It would have been longer but I did switch to a USB-C key two years ago. I kept the old one enrolled as my backup key.

I use a password manager, but my Yubikey has all my 2FA. Including TOTP.

I had a YubiKey fail when I touched it and a static shock wiped its memory. I was able to reinitialize it using their app, but the previously loaded key was lost.

> I have 2 yubikeys and always register them both

How does this work? Do you have to physically retrieve both any time you sign up with a new service?

If that's how it works, it sounds like a choice between two bad options: either having both of them handy at the same time, hurting redundancy, or registering them at separate times, hoping you remember to do both. Is that the case?

That’s what I do. I keep my backup in a fireproof, airtight container

excuse me if i think this is BS.

You will have to retrieve your key when you sign to a new service. at this point you risk losing both.

or are you saying you cloned the private keys and know how to correctly advance the counters when you need the backup?

I don’t use 2 factor for most sites. Do I really care if my HN account is compromised? So for sites that I do care about (e.g. GitHub), yes I register both. It isn’t as inconvenient as you’d think because I don’t sign up for many sites.

Since I use my Yubikey for SSH, I’m frequently adding both Yubikeys as authorized keys on machines. But I keep an authorized_keys file with both public keys so I don’t need to physically grab my backup

But if you register both every time, it means you always carry both yubikeys with you, right? I hope you don’t have both on the same keyring, but if you carry both around, the resilience/redundancy of that setup is lacking in my view.

This concern is valid depending on your threat model, but improvements are quickly coming to this area. Apple, Microsoft, and Google have announced that they will allow syncing credentials between devices in their ecosystem (fully end-to-end encrypted, like a password manager), and several password managers have started to add software implementation of FIDO authenticators to their offerings. Hopefully in the near future we'll see the big vendors open up their APIs so that password managers can use the device hardware as well.

Of course, multi-device passkeys will not work for high assurance situations, as TFA calls out, but that's not likely the case for any of the services you currently use a password manager for anyway.

As it stands today, using passkeys with a software implementation, barring implementation bugs, is no less safe from credential loss than passwords in a password manager.

Apple, Microsoft, and Google have announced that they will allow syncing credentials

While your comment is fair, and I know you were just providing info, from where I sit, these are the sort of entities I never, ever involve in any form of private work, security, or communication.

This is a minority opinion though when compared to usage and market share of these orgs.

as a US citizen, I absolutely do not accept these three giant companies running my access to financial services and governmental functions; just, no. Secondly, I will say that the entire surveillance-capitalism ideas of constant-on ID comes from a model of money lending that was built in the 1960s, ultimately by VISA and MasterCard. This worked well enough to generate the holders massive capital. no, no, no

> Tying login credentials to a hardware device

The article specifically states (about passkeys as opposed to Yubikeys):

> They’re different because Platform created passkeys will be copyable by default using the credentials for the underlying cloud account (plus maybe an additional password manager sync passphrase), whereas passkeys in YubiKeys are bound to the YubiKey’s physical hardware where they can’t be copied.

That brings its own challenges of course (e.g. you have to trust the Cloud syncing and E2EE by the vendors).

Apologies I was trying to make my second condition about these providers. I don't want hardware specific credentials, or <insert multinational cloud provider> controlled credentials.

The first introduces risks with damaged or stolen hardware, not to mention migration.

The second introduces lack of control and enables these companies to track you. It's not lost on me that nearly all the companies offering authenticator apps are basically advertising companies: Google, Microsoft, Apple. They're getting in at the start for a reason

It does not need to be hardware specific. After all, talking to hardware is just software.

Your password manger could implement passkey support. And I suspect that 1password will do that soon with their recent acquisition.

The real benefit to passkeys is that password isn't sent over the wire, only the proof that you have the secret. Similar to SSH keys. This prevents a whole range of attacks.

I use keepassxc, I would love to manage my private/public keys in the same way I manage my passwords. I'm in complete control.

But from my reading, and I believe the way this will be implemented but services, I doubt very much you'll be about to do this. Certainly at the moment it looks like vendor lock-in to me. Vendor lock-in with a heavy dose of targeted advertising.

1Password already has passkey support in development. They have a demo[0] which works on the latest version of the browser extension. It even syncs with my Macbook and Windows machines though unfortunately doesn't work on Android yet

[0] https://www.future.1password.com/passkeys/#demo

I’m not seeing the threat model. Assuming E2EE of the password manager, how does it track you when syncing keys across devices?

Also, how is Microsoft not an enterprise security company? Their revenue from security products is probably 100x that from advertising.

Apologies I don't understand your first paragraph. I'm preferring my password manager because it doesn't track me. It's offline and local.

Microsoft might be an enterprise security company. But they are clearly all about tracking and targeting their users too. The two things are not mutually exclusive.

Re: first point, I don’t see how E2EZe sync of keychains exposes you to targeted advertising. My understanding of the systems is that they use a single encrypted DB that does not expose either the sites, usernames, or passwords to the provider. I’d welcome correction if you know otherwise.

Re: Microsoft, I suppose there’s no harm in being maximally suspicious. But I have some knowledge of their systems and Google’s and Microsoft does not have , for instance, a single user profile that joins interests and infers demographic data like Google does. I expect the same is true for Apple.

My concern is that of relying on one of these vendors for managing the passkeys. And their knowledge of which sites I have accounts with. And my suspicion you'll have an extremely hard time migrating devices and vendors.

I've no internal knowledge of MS systems but the fact that they make it hard to use their operating system without an online account and you can't opt out of all telemetry and the fact it's default opt-in for all telemetry leads me to be extremely suspicious of them. I'm not saying they're any worse than Google or Apple.

I’m confused about know they know which sites you have passkeys for. To the best of my knowledge, neither Apple’s nor Google’s password managers expose that to those companies.

See for instance: https://support.apple.com/guide/security/secure-keychain-syn...

I have a feeling we might be talking about different things. I'm not talking about password managers, and having never used any password manager that wasn't opensource and offline I'm in no place to comment. What I do know is that at no point do I want these companies in charge or gatekeeping the keys (so to speak) to my kingdom. Their motives aren't ultruistic and are only self serving. In the case of Google certainly you could end up locked out of all your accounts if their AI decides to shut your account down without recourse or a Twitter/HN thread about it.

I think we’re talking about the same thing. There is no gatekeeping of keys. There IS gatekeeping of the services that syncs keys across devices.

If one of these companies locks you out of your account for any reason, you don’t lose access to the keys. They are not removed from your devices. You do lose the service that moves them between devices.

Anyway, I appreciate you sharing your perspective and I admire your commitment to only use fully open services. Just saying the closed ones may not be as malicious or a usable as you think.

I 100% agree. I really like the idea of getting rid of passwords, but I wanted to be able to control my own information. That is why I built Bulwark Passkey (https://bulwark.id), an open-source virtual passkey manager which allows you to export your credentials out of it, or sync them across devices.

Passkeys have a lot of advantages, but the current plans for implementation are rather limited. If you're interested in passkeys that you can actually control, please check Bulwark Passkey out!

It looks like the only options are local-only (single device) or cloud-synced (bulwark cloud). I want credentials that are not tied to a single device OR tied to a cloud service. I want to be able to make backups to be used in the case of device failure or loss, and I don't want to be tied to some "underlying cloud account" (in Yubico's words). Just standalone, backupable credentials. Can you do that?

Using passwords is not something very comfortable, and needing to remember a password to a password manager, has some risks, like suddenly forgetting. Using a yubikey is also not very practical since it can be stolen or lost. A phone is always with us, and has small chances of being lost (also there are backups).

I use a yubikey to secure my passwordsafe file https://pwsafe.org/

Password safe runs on multiple operating systems. I sync my file to cloud storage so it's up to date on all my devices

I have a backup key in a drawer and one on me at all times.

I really need to buy a few more backup keys.

It's not a perfect set up but it works for me.

Consider trying SyncThing to sync your files between your personal devices, rather than entrusting access to your data to a cloud provider.

I did this recently and the experience has been surprisingly way easier and better than I could have imagined.

That looks great. Looks it might be viable for me. Security risk in my setup is is cloud storage. And also I'm relying on a password safe Dropbox sync app.

A phone has the same chances of being lost and I would say a higher chance of being stolen.

My question would be who is in control of the backups? The same vendors who want to lock you into their ecosystem?

And the same ones that also lock you out without recourse?

> A phone has the same chances of being lost and I would say a higher chance of being stolen.

Not the same as a small key that can be stolen.

> My question would be who is in control of the backups? The same vendors who want to lock you into their ecosystem?

You, as it's encrypted (in case of apple, not sure about Google). Backup is up to you, you can also backup to other services such as nextcloud.

Phone has a significantly higher chance of breaking.

Owner of a Pixel that just died in my hands. Had I not been with company that day, I would have been in a real situation.

Edit: also, if I keep it on the phone, will Apple/Google deign grant me access to export my secrets on demand or will they deem I cannot be trusted with such power?

> Phone has a significantly higher chance of breaking.

_Breaking in_ is very hard since the security model for phones is very high, especially in cases of Pixels and iPhones. Even if a pin is used, the security chip makes it very hard to break in. If you mean also in case of losing it: Not as a small device that has much more higher chances of being lost.

> Edit: also, if I keep it on the phone, will Apple/Google deign grant me access to export my secrets on demand or will they deem I cannot be trusted with such power?

Don't know about that, since passkeys are still pretty new, but probably it will be an option. Does a yubikey allows you to export secrets?

Edit: typo

> Does a yubikey allows you to export secrets

No, that would defeat the purpose. If you want exportable secrets just use a thumb drive.

That was a rhetorical question.

Why is a passkey any different? Can’t one think of it as a password stored in a password manager? Is it more that you don’t want your browser to function as the password manager?

There seems to be a API already for a browser to delegate passkey storage to a Yubikey, can’t a password manager do the same thing?

Browsers having just API for password managers is separate discussion but yes, that should happen.

Password manager's job should not be to scrape pages for login fields. That still could be a separate plugin (if browser would not do job good enough), but password manager should really get credentials name, some metadata, notes and password to store, nothing more

Right now APIs for third parties are fairly limited, so it can be difficult to have support for passkeys with password managers. I was able to solve it for Bulwark Passkey (https://bulwark.id) by emulating a USB device and building the WebAuthN protocol off of that. This means that it supports all browsers, but also means that iOS support will be more difficult, though not impossible.

> I will probably use passwords until I am forcibly unable to. I'm happy with my password manager.

A random password stored in a password manager is literally what a passkey is. Several password managers have announced support for storing passkeys just like your passwords.

I've been keeping track of this GitHub issue to follow the progress of getting the feature in FOSS password managers:

https://github.com/keepassxreboot/keepassxc/issues/8214

It appears that we are still in the "walled garden bullshit" phase, so I'll pass for now.

I don't understand your last sentence. If a random password stored in a password manager is a passkey, then all providers already support them

Passkey is about the random password stored in the password manager AND the protocol between the browser and the password manager to ensure the password isn't phished. It is the protocol that needs implementation.

"A random password stored in a password manager is literally what a passkey is."

This is not quite true; a passkey is still somewhat more secure than a password in this scenario.

With passwords, the password itself is sent to the website and a hashed version is stored in their database. If someone can intercept your connection to the site (MitM) or can access their database (hacker), they might be able to get your password and log in as you, especially if the website doesn't implement their hashing very well.

These attack vectors don't apply to passkeys, even generated and synced by a software password manager: the private key never leaves your computer, only the corresponding pubic key. The website generates a unique challenge on each login that can only be solved by your private key, so intercepting a particular challenge or stealing the public key from the website database doesn't let anyone log in as you later.

> and that (at least from my understanding) are hard to transfer to new devices seems like a risk I'm unwilling to take.

It's not really hard. They're quite flexible. You can't read the key from them, but you can write to them. You can generate the key outside, write it, save the backup somewhere you trust to be safe according to your threat model, and that's it. If you lose the device, buy a new one, write the key from the backup. The backup can also be used directly if you can't buy a new device for whatever reason.

At least, this is how it works when used as an OpenPGP smartcard.

I use keys as my default way of login but I have 'phishable' backup methods (OTP codes or backup codes).

For me, the main thing is that using the keys by default make my accounts more secure and I would only use the phishable methods in case of emergency (if my house goes up in flames with my keys, computer, mobile, etc). One important thing for me was to remove my mobile number for SMS OTP or password reset, as sim cloning is a posibility.

And a password manager is still indispensable as most sites don't accept hardware keys at all.

With how "secure" average app is I think there is probably much higher chance of them just fucking up than someone that uses password manager and doesn't run random shit off internet getting hacked.

If it was "here is your private key, you can use it in sofware or you can load it on a key and just use" I'd be much calmer about it but the whole push "your authentication and sometimes whole identity is inseparably tied to your device" is frankly scary and disgusting.

I have one of the old blue keys. Never found a good use for it. I don't have my keys with me at my desk, so I never put it on my keychain. So then it's just laying around and gets shuffled of the desk and into a drawer.

Meanwhile, my phone is always near and bitwarden just works.

You don't have to be tied to a single device. A common set up is a root yubikey you create children of. The root key is held in a safe location and the children have either copies or even better, short live keys signed by the root.

I'll have to take your word for it. That all seems complicated to me, maybe it's not and is just out of my frame of reference.

YubiKeys can't have copies of themselves, that's a big portion of their selling point. As far as I know and strictily in FIDO, there is no solution here. The closest that Yubico has is this draft: https://github.com/Yubico/webauthn-recovery-extension which will roughly make an authenticator register two keys with an RP. The draft itself is not implemented anywhere as far as I know and while better than the current state of hardware key backups, it's still not problem free.

I personally would love to see it implemented, so it can be used for logging in to the service that provides a WebAuthn sync fabric.

"passkeys in YubiKeys are bound to the YubiKey’s physical hardware where they can’t be copied."

Unless you are talking about something entirely different that scenario isn't possible.

I don't know about this "root key" setup you describe, but you can certainly program sets of yubikeys with the same OTP secrets at setup time, resulting in cloned/backup keys. The OTP secrets can also be stored (presumably offline) to create new copies of the key in case of recovery.

Reply on news.ycombinator.com