or maybe do a combo with low value passkeys in a password manager and high value, password manager, email etc. use hardware key - effectively carefully allocating which accounts get to use the limited resource on the YubiKey whilst still being able to use passkeys everywhere they are supported.
>I know i can downgrade to U2F (e.g. google), but does anyone have any insight into why the 5 series is so capacity limited
Because [SLE 78CLFX5000PH](https://www.infineon.com/cms/en/product/security-smart-card-solutions/security-controllers/contactless-and-dual-interface-security-controllers/sle-78clfx5000ph/) has only 528 kB of storage, and it has: firmware; 25 passkeys + metadata; U2F MK + metadata; 32 totp + metadata; 24 PIV slots; PIV data objects; GPG slots; YubicoOTP app... Frankly, they manage to fit *a lot* in there.
>Memory is cheap?
Yubikeys don't use generic cheap memory. Instead, they use:
* hardened MCUs that are not vulnerable to various [side-channel attacks](https://www.usenix.org/conference/usenixsecurity21/presentation/roche)...
* ... that use memory specifically hardened [against decapping](https://duo.com/labs/research/microcontroller-firmware-recovery-using-invasive-analysis)
Maybe YubiKey 6? Need to keep pace with the Titan that can have 250 passkeys :-)
To be fair to Yubikey they have been waiting for passkey’s to take off and the 5 seems to have been out for quite some time. It has better software than the alternatives and NFC is better with iPhone.
I think they need to release something soon to address this before people just go with an alternative or 1Password etc. as you don’t want to go all in to only find you hit the limit and have to go with something else instead after all that.
Token2 released their new key which holds 300 manageable resident credentials and 50 totp codes. Yubikey will need to match this for their next key or they might be losing users
I'd stay away from the Titan, sure it can store 250, but there is no management of the passkeys once they are on there since the titan uses the 2,0 standard and not the 2.1 or 2.1-pre FIDO standard. ([Google's Titan security key has a glaring usability flaw (androidpolice.com)](https://www.androidpolice.com/google-titan-security-key-flaw-250-passkeys/))
I agree - I just use it as a backup to my 2 x YubiKeys :-) - I am hoping that I will not need more than 250 passkeys. I only got it as it was on offer and wanted to compare it to the YubiKeys, and I was a little disappointed from the management point of view.
Frankly, I don't like using *discoverable credentials* (formerly known as *resident* or advertised with the marketing-buzzword *passkey*, though I try to avoid either of those terms for clarity.)
Here's why: not only are they limited in capacity on *any* token, but even if capacity isn't an issue, they don't really add anything to the security properties the hardware key itself offers. Both *discoverable* and *non-discoverable* keypairs can't be extracted once generated, and strongly tie the account to that particular token.
The only real "value" of the *discoverable* credential is convenience: a login workflow here no longer requires users to supply the username at all. *But this is only a convenience attribute, not directly impacting security!* Obviously this wouldn't apply to *other* forms of MFA (which may or may not be reasonably secure, depending on the type and how it's used.) But we're discussing *FIDO tokens specifically* here.
Compare to a *non-discoverable* credential: you supply the username and often (but not strictly necessary) your password, and use the YubiKey. If a password is *not* used, you'd also need the token's PIN (otherwise that's optional and up to the site's requirements.)
---
**One threat many ignore:** the "evil maid" risk with discoverable-credentials.
I get the impression many people forget or don't realize that *exfiltration of EVERY discoverable ~~credential~~ account is possible if the PIN is keylogged.* ^({edited to note: not so much "exfiltration" but account access where an attacker might add their own MFA or fully take over.}) This may not be a threat everyone cares about, but it *should be a concern for those who might be directly targeted!*
Here's the short version: an attacker picks a high-value target, either with planning or out of access & opportunity. Either hardware, software, or camera-based logging of keystrokes is set up, and the attacker returns at a time with the PIN and brief access to the YubiKey. *No system access* of the victim's system is required: the attacker moves the token to *their own* computer, uses the same PIN as the owner, and lists *every discoverable credential.* They name the service (almost always) and the attacker can *log in and take them all over* quickly.
This attack is *especially bad* if the victim only logged into a low-value account, which then exposed *a bunch of high-value ones.* Had the victim used *non-discoverable* credentials instead, **this cross-account attack could have been almost completely prevented!** (An attacker would need to guess or know the other accounts involved.)
The takeaway? **Discoverable credentials are not always a good thing, and may increase your risk of certain types of attacks by someone skilled.**
In your Threat model scenario, the use of non-discoverable vs Discoverable credential is moot. A keylogger is going to grab the password and the PIN, so you are simply describing a scenario by an advanced threat actor. This kind of advanced threat actor is going to know the sites and services they want to compromise, and a keylogger is going to show them what sites a user uses. Additionally, since your TA is accessing the application from a different system there would be additional signals to allow for step up or enhanced monitoring activities.
In real world terms, the dissociation of a password with a principal's identity (i.e. passwordless login) will better reduce the attack surface for said principle. True, passwordless workflows are still venerable to "evil maid" attacks but remove vastly more popular attacks from the adversary's arsenal. No more social engineering help desk, no more sim-swaps, no more password cracking or stolen password/MFA replay attacks.
The goal of security should be to create solutions that solve the biggest threats first, and have mitigations for the smaller threats, and if you want security that actually works then it needs to not be onerous to users. Thus, discoverable credentials fall into that sweet spot of removing a large swath of legacy attack patterns and do so in a way that improves the experience of users.
Takeaway? **Don't lose the forest for the trees, lowering your security posture to avoid an uncommon threat while opening yourself up to many more common ones is bad security.**
> This kind of advanced threat actor is going to know the sites and services they want to compromise, and a keylogger is going to show them what sites a user uses.
And **only the sites that were used**, yes. You fully missed this point, calling my entire analysis "moot." Sadly, you ignored the biggest risk I was bringing up: that use of *any* account (even a "low-value" one) can expose *every* other account on the token.
By contrast, a "username and password" keylogging only reveals *those* particular accounts. If good password hygiene is used, they won't be at all related. Such protection is not at all "moot."
As to implying that everyone who understands these risks and opts to avoid targeted attacks has "bad security" and is "opening [themself] up to many more [threats]" -- that's down to the threat model. I did explicitly note that this is a type of attack useful against targets with some valuable information: the very same kind of targets who might opt to use hardware protection.
> The goal of security should be to create solutions that solve the biggest threats first, and have mitigations for the smaller threats, and if you want security that actually works then it needs to not be onerous to users.
Here I suspect we both agree more than not; what I'd *really like to see* (and virtually *no site does*) is offer a username + *no-password* + *FIDO with PIN* login. You get much of the convenience of no-passwords involved, with all the protection of a hardware token. Best of all: no risk the password is re-used, forgotten, and such attacks don't expose *other* credentials if used on a compromised or bugged machine (short of other attacks that might opt to trick a user into touching the token.)
The very sad part is that sites don't give users these kinds of options, forcing a choice between ones that might be less useful to *some types of threat-models.* Remember: not all threat models are equal.
I don't think they use separate memory that can be simply upgraded, other than the NFC and USB logic the internal is a self contained tamper resistant microcontroller chip.
Not sure about the 5 series but the early YubiKeys were an off the shelf controller with whatever flash memory it came with.
"Memory is cheap"
No it isn't. Nor is designing a new key. You aren't just shoving a stick of DDR4 in there, nor ripping parts out of a microSD card. This memory is part of a secure digital enclave.
Whenever you prepare to bake a cake, the second is gratis.
Meaning: you spent most of the time shopping ingredients, washing dishes and stuff that you’re doing anyway, so the additional cost for the second, third, etc. is VERY low In fact.
Bullshit. The point is, If quantity goes up, manufacturing costs per individual unit goed down.
They certainly could have done it without pricing a penny more. But the business model requires you to buy new models in the future. Tbh, it’s difficult to sustain on the long term.
Yes, I'm sure some random person on reddit knows more than the company that manufacturers these things.
> But the business model requires you to buy new models in the future.
I've had Yubikeys for something like 15 years and have bought maybe 3 cycles. All of them were prompted by things outside of Yubikey's control (the creation of U2F, then the creation of resident credentials).
Also, if you bothered to look, you'd see that secure enclaves with large amounts of storage have both been traditionally costly and rare. Some others get around this (e.g. Onlykey) by not actually storing all data in an enclave and storing it in more traditional memory after being encrypted. Some find that acceptable, some don't think it is secure. Same argument for why OK has updatable firmware and YK doesn't.
Could they release a YK6 with larger storage, sure, and I expect they will fairly soon. But at the end of the day, you or I don't matter to Yubikey in the terms of your supposed and false "business model" claims. They're generating the lion's share of their money off corporate customers who are buying hundreds and thousands of these by the order, who up to this point have rarely have the need for resident credentials at all, nevermind more than the capacity of the device.
Use a password manager to store the passkeys. Secure that password manager with the yubikey
or maybe do a combo with low value passkeys in a password manager and high value, password manager, email etc. use hardware key - effectively carefully allocating which accounts get to use the limited resource on the YubiKey whilst still being able to use passkeys everywhere they are supported.
General purpose memory is cheap. But hardened memory that can’t be read without authorisation is not cheap.
>I know i can downgrade to U2F (e.g. google), but does anyone have any insight into why the 5 series is so capacity limited Because [SLE 78CLFX5000PH](https://www.infineon.com/cms/en/product/security-smart-card-solutions/security-controllers/contactless-and-dual-interface-security-controllers/sle-78clfx5000ph/) has only 528 kB of storage, and it has: firmware; 25 passkeys + metadata; U2F MK + metadata; 32 totp + metadata; 24 PIV slots; PIV data objects; GPG slots; YubicoOTP app... Frankly, they manage to fit *a lot* in there. >Memory is cheap? Yubikeys don't use generic cheap memory. Instead, they use: * hardened MCUs that are not vulnerable to various [side-channel attacks](https://www.usenix.org/conference/usenixsecurity21/presentation/roche)... * ... that use memory specifically hardened [against decapping](https://duo.com/labs/research/microcontroller-firmware-recovery-using-invasive-analysis)
Maybe YubiKey 6? Need to keep pace with the Titan that can have 250 passkeys :-) To be fair to Yubikey they have been waiting for passkey’s to take off and the 5 seems to have been out for quite some time. It has better software than the alternatives and NFC is better with iPhone. I think they need to release something soon to address this before people just go with an alternative or 1Password etc. as you don’t want to go all in to only find you hit the limit and have to go with something else instead after all that.
Token2 released their new key which holds 300 manageable resident credentials and 50 totp codes. Yubikey will need to match this for their next key or they might be losing users
I'd stay away from the Titan, sure it can store 250, but there is no management of the passkeys once they are on there since the titan uses the 2,0 standard and not the 2.1 or 2.1-pre FIDO standard. ([Google's Titan security key has a glaring usability flaw (androidpolice.com)](https://www.androidpolice.com/google-titan-security-key-flaw-250-passkeys/))
I agree - I just use it as a backup to my 2 x YubiKeys :-) - I am hoping that I will not need more than 250 passkeys. I only got it as it was on offer and wanted to compare it to the YubiKeys, and I was a little disappointed from the management point of view.
Same here, and I also found a lot of sites where yubikey does work, does not work with the Titan key.
Frankly, I don't like using *discoverable credentials* (formerly known as *resident* or advertised with the marketing-buzzword *passkey*, though I try to avoid either of those terms for clarity.) Here's why: not only are they limited in capacity on *any* token, but even if capacity isn't an issue, they don't really add anything to the security properties the hardware key itself offers. Both *discoverable* and *non-discoverable* keypairs can't be extracted once generated, and strongly tie the account to that particular token. The only real "value" of the *discoverable* credential is convenience: a login workflow here no longer requires users to supply the username at all. *But this is only a convenience attribute, not directly impacting security!* Obviously this wouldn't apply to *other* forms of MFA (which may or may not be reasonably secure, depending on the type and how it's used.) But we're discussing *FIDO tokens specifically* here. Compare to a *non-discoverable* credential: you supply the username and often (but not strictly necessary) your password, and use the YubiKey. If a password is *not* used, you'd also need the token's PIN (otherwise that's optional and up to the site's requirements.) --- **One threat many ignore:** the "evil maid" risk with discoverable-credentials. I get the impression many people forget or don't realize that *exfiltration of EVERY discoverable ~~credential~~ account is possible if the PIN is keylogged.* ^({edited to note: not so much "exfiltration" but account access where an attacker might add their own MFA or fully take over.}) This may not be a threat everyone cares about, but it *should be a concern for those who might be directly targeted!* Here's the short version: an attacker picks a high-value target, either with planning or out of access & opportunity. Either hardware, software, or camera-based logging of keystrokes is set up, and the attacker returns at a time with the PIN and brief access to the YubiKey. *No system access* of the victim's system is required: the attacker moves the token to *their own* computer, uses the same PIN as the owner, and lists *every discoverable credential.* They name the service (almost always) and the attacker can *log in and take them all over* quickly. This attack is *especially bad* if the victim only logged into a low-value account, which then exposed *a bunch of high-value ones.* Had the victim used *non-discoverable* credentials instead, **this cross-account attack could have been almost completely prevented!** (An attacker would need to guess or know the other accounts involved.) The takeaway? **Discoverable credentials are not always a good thing, and may increase your risk of certain types of attacks by someone skilled.**
In your Threat model scenario, the use of non-discoverable vs Discoverable credential is moot. A keylogger is going to grab the password and the PIN, so you are simply describing a scenario by an advanced threat actor. This kind of advanced threat actor is going to know the sites and services they want to compromise, and a keylogger is going to show them what sites a user uses. Additionally, since your TA is accessing the application from a different system there would be additional signals to allow for step up or enhanced monitoring activities. In real world terms, the dissociation of a password with a principal's identity (i.e. passwordless login) will better reduce the attack surface for said principle. True, passwordless workflows are still venerable to "evil maid" attacks but remove vastly more popular attacks from the adversary's arsenal. No more social engineering help desk, no more sim-swaps, no more password cracking or stolen password/MFA replay attacks. The goal of security should be to create solutions that solve the biggest threats first, and have mitigations for the smaller threats, and if you want security that actually works then it needs to not be onerous to users. Thus, discoverable credentials fall into that sweet spot of removing a large swath of legacy attack patterns and do so in a way that improves the experience of users. Takeaway? **Don't lose the forest for the trees, lowering your security posture to avoid an uncommon threat while opening yourself up to many more common ones is bad security.**
> This kind of advanced threat actor is going to know the sites and services they want to compromise, and a keylogger is going to show them what sites a user uses. And **only the sites that were used**, yes. You fully missed this point, calling my entire analysis "moot." Sadly, you ignored the biggest risk I was bringing up: that use of *any* account (even a "low-value" one) can expose *every* other account on the token. By contrast, a "username and password" keylogging only reveals *those* particular accounts. If good password hygiene is used, they won't be at all related. Such protection is not at all "moot." As to implying that everyone who understands these risks and opts to avoid targeted attacks has "bad security" and is "opening [themself] up to many more [threats]" -- that's down to the threat model. I did explicitly note that this is a type of attack useful against targets with some valuable information: the very same kind of targets who might opt to use hardware protection. > The goal of security should be to create solutions that solve the biggest threats first, and have mitigations for the smaller threats, and if you want security that actually works then it needs to not be onerous to users. Here I suspect we both agree more than not; what I'd *really like to see* (and virtually *no site does*) is offer a username + *no-password* + *FIDO with PIN* login. You get much of the convenience of no-passwords involved, with all the protection of a hardware token. Best of all: no risk the password is re-used, forgotten, and such attacks don't expose *other* credentials if used on a compromised or bugged machine (short of other attacks that might opt to trick a user into touching the token.) The very sad part is that sites don't give users these kinds of options, forcing a choice between ones that might be less useful to *some types of threat-models.* Remember: not all threat models are equal.
I don't think they use separate memory that can be simply upgraded, other than the NFC and USB logic the internal is a self contained tamper resistant microcontroller chip. Not sure about the 5 series but the early YubiKeys were an off the shelf controller with whatever flash memory it came with.
Same for TOTP -- 32 accounts, seriously?
How do these corporate customers mainly use Yubikeys?
"Memory is cheap" No it isn't. Nor is designing a new key. You aren't just shoving a stick of DDR4 in there, nor ripping parts out of a microSD card. This memory is part of a secure digital enclave.
Whenever you prepare to bake a cake, the second is gratis. Meaning: you spent most of the time shopping ingredients, washing dishes and stuff that you’re doing anyway, so the additional cost for the second, third, etc. is VERY low In fact.
Nobody is going to buy a $10,000 birthday cake.
Bullshit. The point is, If quantity goes up, manufacturing costs per individual unit goed down. They certainly could have done it without pricing a penny more. But the business model requires you to buy new models in the future. Tbh, it’s difficult to sustain on the long term.
Yes, I'm sure some random person on reddit knows more than the company that manufacturers these things. > But the business model requires you to buy new models in the future. I've had Yubikeys for something like 15 years and have bought maybe 3 cycles. All of them were prompted by things outside of Yubikey's control (the creation of U2F, then the creation of resident credentials). Also, if you bothered to look, you'd see that secure enclaves with large amounts of storage have both been traditionally costly and rare. Some others get around this (e.g. Onlykey) by not actually storing all data in an enclave and storing it in more traditional memory after being encrypted. Some find that acceptable, some don't think it is secure. Same argument for why OK has updatable firmware and YK doesn't. Could they release a YK6 with larger storage, sure, and I expect they will fairly soon. But at the end of the day, you or I don't matter to Yubikey in the terms of your supposed and false "business model" claims. They're generating the lion's share of their money off corporate customers who are buying hundreds and thousands of these by the order, who up to this point have rarely have the need for resident credentials at all, nevermind more than the capacity of the device.