Pass the key, passwords have passed their sell-by date The UK's National Cyber Security Centre (NCSC) has officially endorsed passkeys as the default authentication standard, marking the first time the agency has told consumers to move away from passwords entirely. New official guidance states that passwords should not be used where passkeys are available, overturning decades of …
So now instead of relying of memory or my trusty paper notepad I have to rely on an internet connected device and the benevolence of the cloud provider.
Of course, now everybody and his dog will INSIST on using a password..., sorry, passkey for everything, even if that's not necessary. And a special app working only on the latest flagship devices.
I understand that passkeys add a strict dependency on a specific device, an Internet connection being available, a specific cloud service being available, or a combination of the three, depending on implementation. Any of these is a point-of-failure, which can and does fail in real life, and whose mode of failure is that you're locked out of the service you want, with no easy workaround.
By comparison, a proper password manager with encrypted local storage and sync across several devices lets you use high entropy passwords that are immune to guessing and bruteforcing, and only locks you out if all of your devices are unusable AND you're offline on top of that.
If I'm wrong, I'd like an explanation or a pointer to where I can get one.
You are wrong. You can create a passkey via say KeePassXC, create a backup of your passwords file and transfer that to any device. It is automatically encrypted on local storage and you can sync across several devices as you wish, or run it in the cloud if you are into things like that. If you use high entropy passwords that you do not write down the only added point of failure is getting your browser on all devices to talk to KeePassXC or equivalent, you cannot just copy and paste.
Password == Entropy stored in your brain
Passkey, Token, Keyfile, Biometric, etc. == Entropy stored in something you have
The functional difference is what matters. Passwords store a secret in your brain, everything else is distinguished by where it stores the secret outside a human.
Passwords are never going away, no matter how much clueless ministers and corporate PR hacks encourage the plebs to put their keys in the cloud and sign in with their face.
Even where a physical secret makes sense, securing it with a password also makes sense. Gosh, I wonder why a government would discourage storing things in the one place a search warrant can't access.
Long, unique passwords work and make sense. Passkeys introduce additional barriers which people really don't need. Many still barely cope with passwords, never mind 2FA, which simply replaces one point of failure with two. Passkeys require uniform tech and kill backwards compatibility. The more tech you use, the less resilient and accessible your services are.
I will continue to use passwords whilst I can, and then consider migrating as much as I can back to paper.
Hopefully passkey systems will get hacked before we are forced to use them, rather than afterwards, as has been the case with the French state ID service.
The NCSC are detached for the reality of everyday non-tech users and should go ruin someone elses day. We have enough shit to put up with every day in the UK now, without them adding to it.
NCSC really aren't that stupid. There are countless stories of security professionals - people who should be aware of what they are doing - being phished into entering their long and unique password into a fake site.
Passwords are easy to understand and if they fit your security profile then fine. But don't think that because you've got a long unique password you're safe because I can assure that you those security professionals who have been phised also thought they were safe.
Long and unique passwords are only viable if you use a device to store those long and unique passwords for you. So they don't "work" for the majority of people who don't want to use a password manager, and if forced to use long passwords will either use the same/similar passwords on many sites or will write them down somewhere that can be lost or potentially compromised (if it is e.g. a notepad file versus pencil and paper)
Total side-question, but I know that in some places the authorities can't demand a password or pin but they can demand other access methods.
Where would you stand legally if the feds show up at your door and demand a passkey? Or, more likely, they call up Amazon and demand your passkey?
The police get your phone, use your fingerprint or face to open it, and gain access to all your passkeys because your device is now unlocked. Brilliant.
With a phone's password I don't have to divulge, it gets much harder. With a master password and hardware token to an encrypted database, their job hacking a site just got a lot harder.
As I understand it Amazon doesn't have your passkey - they have a public key that corresponds to the private key of the passkey you generate for Amazon. If they give the public key to the feds, the feds can theoretically use it to verify you are in possession of the private key, if you respond to an authentication challenge for that passkey. Passkeys are generally tied to a domain though, so the feds would have to take over amazon.com for your client to respond to a challenge for that passkey.
Because a password gets transmitted to the service you're logging into. Anyone who can intercept it has the password too. The external service also frequently receives the plain password and you are relying on them to throw it away every time when they no longer need it. A passkey is a cryptographic key where the secret part you have does not get transmitted, so neither an intercept nor the external service ever sees the bytes you have which allow access.
The browser doesn't automatically apply any kind of security to an input of type password except to obscure its contents from shoulder surfers by replacing its contents with dots.
The only thing securing the vast majority of web-based passwords is encryption within a TLS stream. The remote host application still receives a plaintext password. Attackers sniffing the TLS stream still receive a stream which, if decrypted in the future, still includes the password in plaintext.
Attackers sniffing the passkey enrollment transaction cannot use the information gained in that transaction to impersonate the authenticating party in future transactions.
Attackers man-in-the-middling the passkey enrollment transaction can go about their business, however.
I have the same problem with passkeys as I do with non-TOTP 2FA: losing access to any part of the authentication chain means authentication failures, and no third party service gives two shits about reintroducing liability distinguishing between someone locked out of their account and an impostor. At least with TOTP I can use oathtool and the encrypted vault I already have.
How do you think passwords are verified? The hash is what is stored at the remote end, if they're doing it right. Even then, we frequently find that services store passwords in plain text or encrypted but not hashed, you know, services with only a few users and no technical staff like Facebook. But how does the service verify the password when you log in? It still involves the user sending a string for verification on the remote system. Encryption in transit makes interception harder, but not impossible. I'm holding out hope that I'm misunderstanding what you're saying, but it's looking like one of those people who heard about hashing passwords and doesn't know how that works and what it does.
Ah, I see what's happening here. This is a test to see how much a relatively unimportant comment board can stress out people who know what they're doing. We appear to have quite a few people who don't understand what hashing passwords protects you from (recovery of the passwords from the data on the remote service) and what it doesn't (retrieval and replay of the passwords from the ephemeral communication between an authorized user and the remote service) and that there are places that don't hash passwords even though they definitely need to, and all on a place where the readers are generally expected to be knowledgeable about IT. This is one of the main reasons we have security problems: smug people who think "hash" is a magic word meaning nothing bad can happen with passwords if you use it making the same mistakes over and over, whether about passwords or something else. If you don't care about this, that might be sufficient justification, but if you think hashing the password means it can't be seen during communication, then you are wrong and you will be wrong until you learn how it works.
Being technically correct on these forums leads to a lot of downvotes if the thing you're being correct about is heretical. Breathe, relax, remember that UDP over IPv4 guarantees that 508 octets of payload can be transmitted without fragmentation but that IPv6 doesn't make any such guarantees because there is no defined limit to the number of extensions that can be passed on a header, and just generally don't listen to the voices advising you to commit acts of violence.
Passkeys are technically superior to passwords, but the fact that Firefox doesn't have a built-in software-based authenticator as a less-secure fallback kills them for me. For their part in making the web-based consumer security ecosystem an all-or-nothing affair which empowers their members primarily while acting under the guise of openness, and with all due respect: the FIDO Alliance can eat a bucket of shit.
(Also, if Firefox does actually have a built-in software-based authenticator, I'd love to know how to enable it, and especially so if Firefox can opt to use it even when the Relying Party doesn't want to permit it. The fact that I can't disable CORS to inject arbitrary resources into sites I'm visiting rather indicates that Mozilla aren't inclined to enable my proclivities, but alas.)
Many addons available for this. YMMV as I'm not familiar with what hurdles some sites might put on operation, but I use the top one (the craftily-titled "Authenticator") can screengrab the key when the site puts it in a QR code, or it can be manually entered. The key syncs via Firefox Sync to other devices (desktop; I don't use it on mobile so dunno about that) and the key list can also be exported to text file.
Are you assume the log-in is just on a dumb HTML page?
I doubt that's the case for many banks. Unless it builds exclusively to a very early browser standard, a bank can certainly hash the password on the user's end of the internet, and/or send down a bespoke public key for the submission.
What I see happening, here, is worst-case scenarios being combined to drive agenda.
Conceiving and remembering a password sufficiently complex is not difficult. Where you need to avoid reuse (and there isn't really any reason not to have a common password for the mass of low-grade stuff we use on the internet), you can add random tails (or prefixes) that you record somewhere readily accessible by you, but that isn't screamingly obvious to find. Layer on some steganography, and maybe tag the respective services by nicknames, and no-one's ever going to get your password, unless he manages to reverse harsh whatever the service provider is storing. I hate the one-time codes sent to the 'phone, but, on top of a password, they pretty well guarantee a bank that it's not taking instructions from a hacker.
"I doubt that's the case for many banks."
You doubt, or you have any reason whatsoever to think your approaches actually get implemented? The code that would implement them is sent to your browser before you log in, can you find me a single example of a page that does that? One reason you'll have trouble finding that is that the approaches you recommend don't do what you think they do:
"a bank can certainly hash the password on the user's end of the internet": In this case, anyone who has the hashes can log into any account, defeating the original purpose of the hashes which required them to be individually broken.
"and/or send down a bespoke public key for the submission.": Anyone intercepting that communication could replace it with their public key. In effect, that's what TLS does already, and the discussion was partially about what happens if TLS is defeated.
> You doubt, or you have any reason whatsoever to think your approaches actually get implemented?
Exactly. It's telling how many people on what used to be an IT oriented site, don't know how to open their browser's console and *actually look* at what goes on when they log into a site. It takes less time and effort to do that than to come here and write a post about how "they think" it works.
> Unhashed plain-text password transmission stopped being a thing about 30 years ago.
No it hasn't. For nearly every password flow on the web, what protects the password from MITM attacks is the HTTPS encryption layer. The password itself *is* transmitted in clear text (and therefore known to the other party), as can be seen by firing up the developer tools in your browser.
The pass key thing, being a public key asymmetric authentication flow, avoids this issue. In theory, it makes it harder for the system you are authenticating against to pretend to be yourself (if you care about that sort of thing).
You are mistaken. The hash is computed on the destination, not the source. One reason is that, if the hashes from the destination were compromised, computing them on the source means an attacker can instantly log into every account by sending the pre-stored hashes. The transmit password, compute hash on destination flow is what is done in almost all flows, from HTTP logins to SSH, and you can verify this very easily by looking at the traffic sent and watching the cleartext password zoom by.
Encryption on that channel means this is often not a big problem, but that and machine authentication of the destination are the advantages of passkeys. Only by knowing the real differences between the methods can you decide whether you think one is better. If you assume that passwords do something they don't, you'll have an incorrect basis for comparison.
"computing them on the source means an attacker can instantly log into every account by sending the pre-stored hashes."
They can double-hash; can't they? Hash with shared salt at the client end, transmit to server, hash with private, account-unique, salt on the server, and, finally either, depending where in the password's lifecycle we are, store in or compare with the server data base.
> In a normal secured password system it's a hash that gets transmitted.
Please provide an actual example of such a system.
And while we're at it, please be aware that it wouldn't be any more secure than a plain text password in the absence of a shared salt (and only marginally more secure in its presence).
I suspect your confusion might arise from you having heard of SCRAM or similar challenge-response authentication methods, suitable for use over insecure channels. Those are *not* commonly used on the web (or pretty much anywhere these days, when TLS channels are abundantly available).
AFAICS it is you who is wrong. From TFA "Passkeys work by creating a cryptographic key pair between a user's device and the protected account." After that just about any quickly found explanation on the web seems to resort to hand waving, the more detailed mentioning "challenge" but if it requires a cryptographic pair on the two ends it suggests that it involves exchanging some encrypted text.
This is not the same as having KeePass generate passwords that look like line noise and store them encrypted. Having said that the KeyPass option would be my choice. The ability to share copies across devices avoids the reliance on a single device.
Or I can remember a 24 character password phrase and control who gets access to it. i.e.. Nobody. (Well until April 12, 2161 when the Psi Corp is formed. :P)
If my device is seized by a dictatorship (like when going through US Customs & Immigration or when subjected to UK RIPA), they don't get instant access to every one of my connected devices because they pick up my passkey from my "secure storage" on my laptop. Oh, store a passkey on a Windows OS and you may as well just tattoo it on your forehead.
If I am forced to reveal my laptop password to a government when travelling that's all they get because (shocker) I have different passwords for pretty much everything. You are only forced to hand over passwords for connections on your laptop. I use incognito browser mode for all my connections so when I turn it off they are all gone.
I never asked for Passkeys and opt out of them wherever possible. Anything that reduces my personal privacy and gives governments (and snoopy corporations) instant access is not helpful in the slightest. ...and frankly a massive step backwards IMHO.
A passkey can be synced with equal ease as a password and doesn't require any specific service. They are long enough that, unlike most passwords, you are unlikely to be able to memorize them. If you're using a password manager already and relying on passwords you don't have memorized, you are no more independent with your approach than you would be using passkeys.
> A passkey can be synced with equal ease as a password and doesn't require any specific service. They are long enough that, unlike most passwords, you are unlikely to be able to memorize them. If you're using a password manager already and relying on passwords you don't have memorized, you are no more independent with your approach than you would be using passkeys.
I would like to know what kind of insecure, childish idiot is down voting these posts without providing an explanation.
There is nothing inaccurate that I can see about the post I'm quoting.
What many (most?) people are missing here is that passkeys provide a significant barrier to other ways your account can be compromised. It doesn't matter how long or otherwise strong your password is, if you can be persuaded to enter that password onto a site you think is what it is but in fact is a phishing site. If that happens (and in the absence of 2FA or other security measures), your account is compromised. Likewise, if you have malware on your device that can scrape the password field or is recording your keystrokes, your account is likely to be compromised.
Passkeys - correctly implemented - solve both those. Your passkey for site <X> will refuse to authenticate on <Fake-X>. Your passkey can't be guessed or intercepted over the wire to site <X>.
Yes they are not a perfect solution but actually they solve the most likely threats other than people using ridiculously weak passwords and reusing passwords across sites.
I have one bank that has gone to passkeys. Here is my personal experience.
In my case I have to use my primary laptop running Windows to access their web site.
Then I have to use my cell phone to scan a QR code.
The login process fails 50% of the time because the devices don't sync fast enough.
The 'advantages' for me are that I can no longer log in with my desktop or other laptop. If my primary laptop or phone die or get upgraded, I can no longer access my account. For all my other secure logins I use KeePass with 20 character randomized passwords and Google Authenticator. I'd use longer ones, because length doesn't really matter when I copy/paste, but I ran into many sites that can't handle longer passwords. My KeePass files are stored on my NAS on a secured share and encrypted. So they are backed up and available to all my PCs (regardless of OS). And I have Google Authenticator set up on two devices.
It's discouraging seeing government agencies go this route because private businesses will use them as an example for forcing it on their customers. I intend to close my account as soon as I can spend down the balance. I can stop using one bank that won't listen to customers, I can't stop using all of them if they all migrate because some government agency says it's the new gold standard.
Locking access to devices that get upgraded every couple of years is not a good plan.
"In my case I have to use my primary laptop running Windows to access their web site."
Why, the passkey has nothing to do with your computer. The only reason I could see for this is that your bank has put in some stupid restriction that on Windows is authorized.
We use passkeys at work, I can authenticate just as easily on my Windows machine as I can on my Linux machine.
As far as slow sync, that's on you, no them! The public part of the passkey must be sent from your phone to YOUR computer over bluetooth. If bluetooth isn't working properly then you WILL have issue.
I will side with you on this count, any security system that relies on bluetooth is a deficiency!
If you are that concerned you can buy a USB fob to store all your passkeys! Insert it in every time you want to authenticate.
> you can buy a USB fob to store all your passkeys
Assuming this isn't just a memory stick (otherwise you'd've called it that)...
Now to identify a genuine and reliable source for one of these USB fobs, verify it works (without giving it access to any real passkeys, just test data - ugh, how does one arrange a test setup for this stuff?), verify that I can copy the data to another one if these fobs (one day, it'll die, at best); what about when I change Wonder if I can issue a "destruct" or "disallow" whe the fob is nicked or otherwise lost?
Not as bad an issue as the sudden reliance on Bluetooth (at least this fob is an "optional" extra).
Although you do seem strangely committed to the idea that, if someone, say a bank, suddenly requires me to use Bluetooth it is entirely my fault that that banking service is now out of my reach.
@HereIAmJH
Do you want to name and shame the bank out of interest?
I personally do not do any online banking * so no idea what the banks I use do.
* I know always a chance for something to go wrong & that UK banks are generally customer hostile and will use any chance to blame the customer rather than themselves so if their security screws up cost me money it would likely be a tortuous battle to get it refunded. Doing stuff in branch then they can only blame themselves for any screwups.
It also helps that I have no pressing need for online banking, bank will still send out statements, various direct debits setup for utility bills, I withdraw cash from ATMs for general shopping etc (cannot overspend when you take cash to the shops unlike paying by card** & so helps you keep to a strict spending budget to manage finances). I do boycott places that are card only.
** Obviously I have a card (e.g. for ATM withdrawal) but its only use is cash withdrawal and emergency use
Do you want to name and shame the bank out of interest?
There's not really any point to naming them, they aren't a bank you get to choose. In 'Merica, depending on your healthcare plan, you have the option to deposit pre-tax dollars in a special account to pay for healthcare services. It's called a Health Savings Account (HSA). The bank is chosen by your employer and are usually crappy little backward entities with a lot of low balance accounts. Unfortunately, in preparation for retiring I deposited the maximum allowed for several years to cover future healthcare costs. And avoid some income taxes.
I actually only have to log in to their site occasionally to get my balance. Which probably makes things worse because I never get familiar with their convoluted login process.
You know you can generate passkeys yourself, no corporation involved? A service can choose not to support them the same way they can choose not to support any passkeys at all, but the structure does not require any third party at all, let alone whichever corporation you think is mandated. There are a lot of annoyances with passkeys, but there are a ton of people here who seem to think they're something completely different than they actually are.
> The passkey is generated on your device! The only thing shared with the service you are using is the public part of the key! The private key is never stored anywhere except on your device!
Done properly, as with any public/private key system, the private key key should be generated and stored solely locally - and should from that point on be easily and clearly located and managed locally.
SSH being a good example of that - and you'll find plenty of people here who understand SSH (as well as, IMO, a growing proportion who don't understand SSH, even amongst those who actually use it). Similarly PGP, although (again, IMO as we don't have figures) there are fewer who know PGP than SSH.
BUT as with everything, these things can be done improperly: it is perfectly simple to set up a web site that will offer to generate SSH and/or PGP keys for you. Of course, you would have to be insane to go to a website and let it generate private keys for you! Who knows what a random web page is doing?! It *might* be running entirely local JavaScript and not doing any more comms to the outside world after the page load is done, but can you be sure of that? And can Joe Bloggs?
Now look at your web browser as it offers to create passkeys for you.
Gosh, doesn't that look just a web page that is offering to generate private keys for you?
Now, one or two of those offers *do* look sort of like part of the browser's own UI, very similar to the one it uses when offering to save your password for this site (only used for low to zero value sites, of course). Note the "looks". Others appear in the middle of the page, with varying appearance - now, are those happening purely locally? Even the ones that are branded?
> The ignorance on this site is astounding!
And do *any* of those popups provide any guidance whatsoever on what passkeys are, how they work, where you can find any reliable information on all this? Nope. Not that I've been offered[; have you fared better?[1] OTOH if you feel like getting into PGP you can easily (well, it used to be easier, but "modern web design" demands all content be hidden) find out how it works, the web of trust, how it is definitely *you* who own and manage your keychain file. Actually, let me modify that: GPG is all in the open, PGP less so (getting corporate) and anything about digital signatures from Certain Big Corporations is - oh, look, pushing you towards keeping your keychain (not that they'll call it that) on their Cloud "for your convenience"...
> The passkey is generated on your device!
Okay. Let's assume that all these players are genuinely doing it properly (citation!). And the lack of trivially accessible documentation is just forgetfulness on their part (unlike, oooh, ssh -h). That all of these apparent webpages are totally benign as they create your private keys.Then:
> The ignorance on this site is astounding
How about you provide the references, at least to get us started.
* If they are locally generated, how do I generate one? Can they be securely generated by me, using demonstrably local commands?
* Where are they stored? How do I access my own set of private keys (e.g. keychain file)?
Etc etc
[1] Yes, yes, you'd hope that anyone on a techie site like El Reg would have looked up all this stuff, as something to fill the long Winter evenings, but - well, ref my opinion on how many here grok SSH.
> And do *any* of those popups provide any guidance whatsoever on what passkeys are, how they work, where you can find any reliable information on all this?
To be fair, that's what schools were supposed to be for, before they turned into basically kindergartens. In this day and age, if a school curriculum does not teach public key cryptography, they should be criminally liable.
@AC
Well, you may be right - now!
I was at school in the 1950's, so not so much, and I'm still baffled, having been out of the game for a number of years. I'm slowly losing track of the technical side of things, especially as I was mainly a main frame programmer.
It's all getting a bit beyond me.
I'll settle for passwords which I generate - and take as much precautions as I can.
…is why didn't they just piggyback on SSH or GPG rather than reinventing the wheel? I haven't read the WebAuthn RFC (if there's one), maybe it's explained there, but it seems to me like giving the browser the ability to talk to an existing and mature system to perform a limited set of operations would have been less complex and risky than reinventing the whole damn thing again, badly.
> The private key is never stored anywhere except on your device!
That is how it's supposed to be, yes. My understanding is that the criticism (and some confusion) comes from the practice of storing the private keys on cloud services managed by GAFAM.
If you use pass keys, perhaps you could share your usual practice with the audience, for education purposes?
I do not use them, as I find the technology a bit immature and inconvenient in my (strictly FOSS) systems, although I do use public key authentication (SSH, GPG) for various non-web purposes, so I cannot give advice on this point.
> The ignorance on this site is astounding!
No argument there! It has really taken a nosedive since the move to .com
I hear: "The ignorance on this site is astounding".
Well it actually isn't. Ignorance is a state of nature, and it is cured by transmitting knowledge freely and kindly from one person to the next.
And that's why I think that it is rather "The unwillingness to REALLY EXPLAIN something, if you already KNOW something" that is more astounding to me.
Don't curse the darkness, light a candle!
Thanks!
Well, let's see. I suspect Mr Dog could have put it more diplomatically, but I gather he was taking issue with this part of my fellow AC's post:
> I have to rely on an internet connected device and the benevolence of the cloud provider.
Technically, neither an internet connection nor a cloud provider (benevolent or not) are required to successfully use pass keys, so Mr Dog's observation is valid.
Other than that, the criticism from Mr AC is also valid too. Pass keys are essentially a *higher friction* mechanism to set up and use compared to a password… and cloud providers conveniently promise to help you avoid that friction, at the cost of ending up being (even more) dependent on the bastards to go about every little detail of your life.
That, to me, is not worth the theoretically increased security they're supposed to provide in certain scenarios.
I do have a pocket-computer (aka smartphone) but it's not my main phone and I definitely don't have it with me all the time.
Storing them in the browser works only when you are on your computer or when you spend an unhealthy amount of time fiddling with softwares and devices so everything is sync'ed and integrated.
Right.
I rather resent the notion that I am to have my cell phone with me at all times. Two factor is annoying enough.
For some reason, this all reminds me of a rather silly but now apparently prescient movie from 1967 called The President's Analyst where. . . well, take it Wikipedia
TPC [The Telephone Company] has developed a "modern electronic miracle", the Cerebrum Communicator (CC), a microelectronic device that can communicate wirelessly with any other CC in the world. With the CC implanted in the brain, a user need only think of the phone number to be called, and is instantly connected, thus eliminating the need for The Phone Company's massive and expensive wired infrastructure. For this to work, every human being will be assigned a number instead of a name, and will have the CC implanted prenatally. Schaefer is to be forced to assist the TPC scheme by blackmailing the president to pushing through the required legislation. TPC uses a short animated sequence (a parody of the animation in Our Mr. Sun) to explain the plan to Schaefer.1To go all Patrick McGoohan on you. . . "I am not a number! I'm a free man!"
Hahahahahahahaahahah.
_________________
"I can store passkeys in my browser or 1Password which are stored locally on my machine."
I can store my passwords locally on my machine in Keepass. I can sync to my local NextCloud and from that to my spare machine.
Keepass is encrypted and protected by its own password which is the only one I need to remember.
> Keepass is encrypted and protected by its own password which is the only one I need to remember.
Being a single point of failure that gives someone who cracks it the literal keys to the kingdom or microkingdom thereof.
But let me meditate on all of the "solutions" I'm seeing in the comments -- backups, browsers, cell phones, etc.
All of the above are second nature to the vast majority of The Register's readers -- we've been soaking in it for the better part of our lives. But that's not necessarily the case for everyone nor, honestly, should it be.
I just want my car to start when I push the botton or turn the key and to get me from point A to point B1 and I don't want to have to learn he niceties of auto mechanics to do it.
And the requirement of having keyfobs or cell phones or whatever can lock some people completely out of necessary services.
Believe it or not, there are a lot of people on the lower end of the wealth spectrum who can't afford even a cell phone, much less a computer with network access and may be dependent on public access such as in libraries.
To draw an anology, here in the States the Internal Revenue Service has done away with paper checks for refunds and relies on "direct deposit" -- but that assume the taxpayer actually has a bank account, which is not always the case either because they don't have enough money to maintain a minimum balance or they just don't want one. Sorry, that's no longer possible:
Don’t have a bank account? Visit the FDIC website or the National Credit Union Administration using their Credit Union Locator Tool for information on where to find a bank or credit union that can open an account online and how to choose the right account for you. , , ,2In other words, conform or forfeit your refund, which you might be depending upon, that is, assuming you even meet the minimum requirement for an account, especially one without high fees and/or penalties.
But I digress.
To return to the point, it seems to me to be fallacious for every person in the world to be as technologically adept as most of the readers here might be and it's rather presumptious for us to expect them to be.
___________________
1 Obligatory Adams: "People living at C, being a point directly in between, are often given to wonder, 'what's so great about point A that so many people from point B are so keen to get there? And what's so great about point B that so many people from point A are so keen to there?'"
I digress as well, often, and with gusto!
As for the IRS example and the laws forbidding tax refund checks to be issued by mail: The way it actually works is that instead of sending you the refund check, the IRS will first send you
a letter, named CP53E, wherein they encourage the taxpayer to provide a bank account number within 30 days.
This letter doesn't say though, that if you have no bank account, or you can't read, or you don't open IRS mail because it is too scary, then the IRS will ACTUALLY still print and mail a check
out after a waiting period of 60 days, I think. Isn't bureaucracy wonderful?
Sorry, only tax experts know this sort of stuff.
> I can store my passwords locally on my machine in Keepass. I can sync to my local NextCloud and from that to my spare machine.
Personally, I fucking hate Keepass. Overengineered and annoying PoS. I *did* give it an honest go but uninstalled it after a few days as it just gets in the fucking way and provides no tangible benefit.
I do remember most passwords that I use anyway (which are perhaps a dozen or so) and for the low importance, occasional ones from sites I rarely use, a text file decrypted to /dev/shm does the trick just fine.
There are passkey card options like PIN protected Fido2 cards for 15 quid. 300 passkeys per card. Though you'll want to maintain a backup card or 3 for the important services.
www.token2.com/shop/category/fido2-cards.
We'll see over time, hopefully they are less vulnerable to breakage over a long term than the older TOTP synchronised number generators.
Most (95%) of my accounts that currently use passwords don't protect anything of any value (sorry, but that does include the el Rego. login.)
Basically like suburban fences - keeps honest people… well, honest. The serious miscreant will easily hop over them.
The inclusion of a device identifier in the passkey generation will be a PITA where the service is accessed from multiple devices (phones, tablets, notebooks and desktops - from experience that can easily add up to well over 6.)
Most banking apps seem to use passkeys already (and 2FA) but with most users having everything on the one phone the security is only as good as the phone's I suspect.
I wouldn't mind using an optional TOTP where I provide the secret (key) - the otpauth:// URI format is accepted (either directly or via QR code) by most OTP clients. Getting the six digit code via SMS seemed just plain daft to me.
Getting the six digit code via SMS seemed just plain daft to me.
Hah! Try moving between countries, and finding out that your Canadian bank refuses to send the SMS to your new British phone number, making their phone app entirely useless.
One of the BIG problems with all of this are the people who more or less never leave California, much less settle in another country, with differing banking and phone systems.
Handing your security to someone else and insisting on a cloud connection is not safe or wise, especially as all the big passkey providers are US based. Seems more secure as cert based but really makes it less usable and potentially more exploitable due to a permanent file holding the security information.
Password manager, complex by default unique passwords with MFA MUCH more secure. Using passkeys will eventually seen as a bad decision, much like contracting Palantir or thinking an Oracle implementation will stick to budget.
I actually believe too that password managers are much more easily explainable to your average person using a computer than pass keys. You can be sure that most average users will change their phone completely forgetting they ever set up a pass key, they do this with 2FA already.
If they knew they had to get their password manager app installed and use the one password they do need to remember then they're at least in with a chance. Yet these password managers don't appear to be promoted or encouraged much, which is odd.
Also Passkey still requires the user to choose and remember a password for account recovery purposes. If you lose that mobile phone then you need a password to get set up again on a new one.
And that recovery service needs to be readily findable, require only a password, and must provide a way of revoking existing passkeys lest they get used by someone else who has stolen the phone, or similar. They’re as open to misuse and abuse by attackers as any other security measure.
I know the advocates of passkeys acknowledge this, but claim that they’re better than using a password all of the time. That’s a somewhat subjective claim, still based on the vagaries of human nature. Careless or ignorant users will still do careless or ill informed things, like use one recovery password for all accounts. Telling them they’re smart for getting with the program isn’t actually going to help…
Also Passkey still requires the user to choose and remember a password for account recovery purposes. If you lose that mobile phone then you need a password to get set up again on a new one.
You are assuming they have set up an account recovery process. My bank has no published recovery process. There is no information on configuring a new phone or PC. And both are required for access. It's a bank that has gone from codes sent via SMS to what appears to be half baked passkeys. When they could not implement support for an authenticator app, I find it difficult to believe they have correctly implemented a 'more secure' process. My guess is that you'll have to call customer service, they'll zap the passkey from your account and then the first person to try to log in gets to configure new devices.
And btw, it doesn't matter how secure the passkey handshake is, it's still dependent on how well they implemented it on their systems.
OMG! The BANK only has the public part of the passkey! The private part is on your phone.
When you backup your phone, you back up that key! Most providers will fall back to SMS, yes, you activate your new phone with the same number to get SMS before restoring.
Calling customer service won't help you, they DO NOT have your full passkey! They CANNOT decrypt your backup to get it!
If you are seriously paranoid get a USB passkey device (Google Titan, $29.99 250 keys), or 2, this will always be your backup for your passkeys!
> Calling customer service won't help you, they DO NOT have your full passkey!
So what? Who on earth cares about your "full passkey"? Nobody! All you want is to be able to log into your bank account, and it's the bank who decides if you can or not.
So yes, calling customer service can and will help you.
(Didn't downvote you though.)
There's a lot of benefits to Passkey for sure, and I don't think it needs any cloud connection as such above the site you're trying to authenticate with. The bigger issue is that it needs some sort of management software, and from what I've seen that's now all over the shop, and least supported on PC.
For the average Joe it protects against a lot of problems. But the average Joe also needs a reliable manager to manage them, passkeys fragmented across 3 apps, and only on their mobile.
Am I missing something - if I need a passkey to log into an internet site, then doesn't that mean that I use that same connectivity to access my passkey or however that exchange takes place?
I do know that there are problems with sending TOTP to a mobile device on an airplane since it isn't delivered over the cellular networks but can be delivered via WiFi calling and RCS. There's a chicken and egg situation - need to be connected to get the PIN but can't connect until you get the PIN...
And the other question: I'm losing track of the number of different ways that a website can ask me to log in.
Let me count the ways:
password
password + one-time PIN
password + passcode / authenticator code (what is this called when you open an authenticator app and get the rolling code?)
password + authenticator popup/approval
Passkey? what is that? And why does the site want to throw away all the other options if I elect to use a Passkey.
and how many other ways are there? I'm getting confused because I had passcodes and now passkeys but they sound like the same thing.
El Reg needs an icon for "get off my lawn".
> ... a lot of benefits to Passkey for sure ...
In the abstract, PERHAPS.
In practice, unmanageable for most people, unless they sign up to one of big operators to do it all for them. And we know who those operators are, and whose orange-stained kingdom they all live in.
It would be great if I could just use my YubiKey to log in to the various web sites and services that I use. It would also be great if I could log in to Windows and RDP sessions at work with a YubiKey.
Is the company I work for planning to use passkeys? Nah, they think Windows Hello is a good idea. FFS.
Do any of the web sites or services that I use support passkeys? Only one of them.
Passkeys are a great idea, but as far as I can see, there's too much "not invented here" and inertia to make them commonplace.
As someone who recently suggested and trialed this myself:
Yubikeys are an absolute pain in the butt to manage across a dozen different services.
Just the onboarding is a nightmare enough to justify not using them.
Now multiply that onboarding by a thousand users.... no way.
I'm sure, once EVERYTHING is configured, it's at least okay. But the onboarding is different for every single service, complicated by all kinds of things, and basically is NEVER obvious, especially to an end-user.
I have one, sitting on my work keyring, right now. I got it working for half a dozen services. And I honestly can't justify even one of my users having one.
That's before you even begin to look at things like centralised management, duplicate keys for critical services, etc.
Onboarding is an absolute nightmare across the board. Almost everything is actively user-hostile, and the only reason anyone does it at all is because they don't have a choice.
The only exception seems to be TOTP on a smartphone via QR code, but that still means installing a TOTP app - and figuring out how to have a backup.
This post has been deleted by its author
I like passkeys and the idea of them - it's the implementation that leaves a lot to be desired. I can't create a passkey on my Nintendo account, despite it having been supported for about two years now, because they use server-side code to only allow their creation on Android or iOS. I have a modern Yubikey which has had support (and been used) on multiple other websites, but no - the site insists I must use a mobile device, and even blocks the Yubikey on those.
Tying your account logins to another layer of account lock-in to a giant provider/operating system vendor is plain stupidity, so unless sites as a whole get their act together and stop limiting by device, they remain a no for me. And for god's sake, let me add more than one passkey so I can log in from another device without having to sync to a server!
I wish I knew your secret, because it just doesn't work for me. Every time I try, it just says "passkeys are not supported on your device" and won't let me even try to enrol it. I've used user agent switcher extensions for the browser, tried different browsers, even different operating systems and it just doesn't change unless I try from iOS Safari or from an Android device (and even then, it refuses to let me use the Yubikey instead and forces a cloud option).
Emailed their support about it once and got nothing but boilerplate responses saying to use iOS or Android as they are the only supported OSs.
Password managers are all very well for people who use one or maybe two devices.
All though I have a primary PC at home and one at work, I use several devices both at home and work where I either cannot use a password manager or have no desire to use one with.
Some of them will also be 'guest' accounts or some generic account that I don't want any personal data stored on.
I know little about how passkeys work as there seems to be no particular standard but I'm guessing it would be a similar situation as I've described?
Other than a physical key, such as a USB key, I don't see how anything can be more secure than 2FA, assuming the user doesn't fall for social engineering attacks etc?
Or maybe I'm just a stubborn old git who needs to get with the times!!!!
Passkeys fail too! Not only the key, but the device to read or write them as well. In the most obvious example the USB port, destroying your passkeys at will. (USB-Killer the other way around...)
Password as fallback always needed. Or make it Bitlocker style: Recovery key as fallback. They CAN use BASE32 encoding for the recovery key tough to make it shorter.
"... undermine the security benefit of having the passkey?"
There's literally no security benefit from having a passkey. While normally you have 3 keys needed (username, password and text message or similar), passkey is the only key needed and therefore *less* secure than other methods. No matter how long it is, it is still *a* key.
Ideally the key is two factors - the possession of the key within a physical device, and unlocking it with a bio metric or pin.
The security benefits are more around using asymmetric cryptography rather than a shared secret so that even the service you use never gets possession of your password. Therefore a phishing site can't get it by pretending to be the legitimate site. There is still some potential for an attacker in the middle. Most implementations won't authenticate a passkey to the wrong domain, but a good password manager should also do this.
...I need a key file that exists on my device that anyone who manages to somehow gain access to my device will be able to use.
Unless I put a password on the key file at which point I now need a password and some device - which is basic 2fA which I already have for most services that support it.
Except I presume people are expecting me to use a password/pin/pattern/thumbprint/faceprint to unlock the device, which is considered "as good" as a password per key file, except clearly it's not because now one only needs defeat one password/pin/pattern/thumbprint/faceprint to get access to all my key files as opposed to having to break each password separately.
How is this better again?
"They (keys) can't be guessed or phished,"
These people must be idiots: *Anything* can be phished. Literally.
Basically these people firmly believe that a *single step* password (because that's what it is once you remove BS talk) is "more secure" than any other method, without any proof whatsoever.
Guessing a password which has 16 characters? Good luck on that too. Do these people understand anything at all?
i hate passwords and hate mfa even more.
i've got nearly 40 mfa codes on my phone. hate it
with passkeys, nothing to remember & whatever device i'm on I can use, face, finger print or worse case scenario the laptop login password.
the only problem is microsoft getting ppl to scan QR codes but apart from that fuckery they're great.
the comments on here just show once again that techies don't understand normal human beings. the autistic might be able to remember 50 long complicated passwords but the rest of us don't particularly want to.
Password mangers on the browser are inherently insecure & after having to be up until 5am changing every password because Lastpass were dumb enough to let a developer use their personal laptop with a dodgy version of Plex on it, password mangers are just a pain. As well as having to pay for one.
Passkeys are easy for normal people who have a multitude of accounts, who usually use the same password for everything & don't particularly want to learn how to use docker to run a local password manager.
You can get the security of an asymmetric keypair without rolling over to Big Tech. Passkeys don't have to be a "locked-in" nightmare.
- Google/Apple/MS/Salesforce/Samsung authenticators are data traps with no export buttons. Use a manager that supports local exports (.cxp or .json).
- Air-gapped backups: Export your vault to a encrypted USB drive (VeraCrypt or Cryptomator)
- "Analog" fallback: Use the recovery codes provided at setup to bypass the passkey if everything fails. You can even write them on paper.
Benefit:
The website only gets the public key. They have nothing to lose in a breach. Your private key stays in your cross-platform vault. Effective protection from phishing use near-enough looking pages.
Downside:
You do need a password manager (and not the browser). But you should use one anyway - 1Password, Proton Pass, Bitwarden, NordPass, Dashlane, Keeper, etc.
Your private key stays in your cross-platform vault.
Vaults. Plural.
I maintain my on-line life as a collection of disjoint identities. Some, which I care little about, can easily be tied to each other. And maybe me. Others stay in isolation. So that tracking me across accounts will be ... difficult. The downside to all of these asymmetric key generation schemes is that, in the background, I can never be certain that the cloud service, phone app or USB dongle hasn't generated a unique ID and tacked it onto the end of every authentication transaction. Pretty soon, that gets around to all the banks an other online services and I lose my deniability.
Since when have passkeys been granny / OAP friendly?
Or friendly to any of the vast majority of people who are technically illiterate?
Most people reading this thread would have given up after the first couple of comments since they wouldn't have a clue whether the techies claims were valid (evidently even the so-called techies disagree).
If their phone dies, or is stolen, they'll never have access to their accounts again without some serious grief that will make them into sworn enemies of passkeys.
I know, I shouldn't trust orange-face led country, but I have been using lastpass and long, truly obscure passwords for a very long time.
Looking at various websites, the concensus seems to be that if Lastpass vanishes into liquidation, then I can still access my password protected sites using my own password backup but "moving passkeys between passkey managers is not possible at this time (2025)" all you have to do is to create new ones for the 855 sites on which you used them (if of course you can log in given the non-availability of your current passkey manager (and all of its copies on other devices that you own);
Do I read correctly?
If so passkeys are a real hostage to fortune or, at best, a total lock-in.
Regards, Ray
There are two problems: understanding of how passkeys work is poor, even in the technology aware (as evidenced by other posters here). Secondly implementation, there's a lot of confusion between MFA and passcodes then issues like how to share access to a passcode protected account, everywhere I try to set up passcode access the arrangement is different, if I with a tech background, am finding it a bit of a PITA then what chance I can get my mum to use them (it was a struggle to get her to change from a password of "password").
Technically, passkeys are good. I view them like SSH keys for the masses. But there are way too many options for implementation. Some are mutually exclusive or incompatible or both.
There is a lot of misinformation about passkeys out there. Some of that comes from the wide variety of implementations. Some comes from misconceptions. Some from PR/Marketing types trying to explain something technical they themselves cannot comprehend.
Some of the poor implementations are driven by the desire for lock-in or from ignorance or laziness or creativity or agile.
I have passkeys stored with Windows hello on my work laptop. I have passkeys stored on a FIDO/U2F USB/NFC key. I have passkeys stored with my password manager. I do not have any exclusively on my Android phone, save from my password manager. I have decided using the password manager as the passkey provider is the best way.
BTW, a passkey provider is a local vault where the private keys reside. A passkey provider is not like a Certificate Authority or a federated authentication service. But a service like Duo could through it's apps be a passkey provider. You are supposed to choose your preferred passkey provider, like I chose my password manager. But, thanks to variety of implementations, that choice is being made for you in a lot of instances. I have a bank which seems to offer using passkey, but I have yet to find a passkey provider it will offer to create one with and I am comfortable with. (not Windows Hellno, or other half baked passkey provider)
Early on in the passkey era, I was attempting to setup a hardware key with Microsoft. They decided it should be a passkey provider without my knowledge. The process prompted to setup a PIN which I thought was to be another authentication factor. It turned out it reconfigured my hardware key from unpinned 2FA mode to pinned mode to store the passkey. But in the process the unpinned crypto key was wiped out and it could no longer be used with previously registered sites. Leaving me without a backup key. Perfect example of poor passkey implementation. I think MS has multiple implementations across their services. I use MS as little as possible.
Google's passkey implementation seems to be good.
My password manager exports the passkeys. I theoretically can then move them to another if I should want or need to. Fully portable, not locked to a device, backed up locally, off-site, and to the cloud in quantum-resistant encrypted form.
Doable by a "regular Joe"? Probably not. passkeys suck because of all these shortcomings and other valid ones mentioned by others.
