cross-posted from: https://lemmy.bestiver.se/post/1390699
You must log in or register to comment.
30 minutesAs far as I know using a password manager such as KeePassXC or Bitwarden solves all of these problems?
- kepix@lemmy.worldEnglish4 hours
dude speaks about not being able to write down his passkey, then he acts like it can only be saved in bigtech clouds, then some random ai rumbling starts about ads being show to us? can you guys stop posting these god damn fearmongering password articles written by ai?
- 5 hours
Please just stop using a service when it gets unbearable. There is no online service you -need- except maybe bank and tax stuff.
- 7 hours
This is the feature that means you no longer get to make the calls about your passkeys. Fortunately, attested passkeys are not yet required on most websites. But the FIDO Alliance standard makes attestation a part of the passkey ecosystem, whether you want it or not. And even if the website doesn’t require attestation now, simply by using passkeys you indicate to the website that your setup supports the FIDO Alliance’s passkey standard and that you as a user are capable of using passkeys.9 This means that once Twitter (formally X) is satisfied that the overwhelming majority of its users would be unaffected, they can flip the switch – perhaps not all at once, perhaps just for ten thousand users at a time so as not to cause a fuss – and start rejecting non-attested passkeys.
Critically, remote attestation requires the co-operation of your cryptoprocessor, your passkey manager software, your device’s operating system, and your device’s firmware to all pass the remote attestation check. After all, your phone’s operating system has total access to all the 0s and 1s in every app that’s ever run, so it’s not enough for Twitter (formally X) to trust your passkey manager if it can’t even trust your phone’s underlying operating system. If any single one of those things were to fail – say, because your phone stopped receiving security updates so you installed a custom operating system like LineageOS to keep yourself safe without having to buy a new device – then Twitter (formally X) will be able to notice and prevent you from logging in.
Remote attestation can allow them to verify that your device is not capable of, say, sending and receiving encrypted messages, or running a competitor’s app, or using social media without verifying your ID. They don’t want you to be able to turn off the mandatory built-in AI image scanner on your phone that scans everything your phone sees for nudity. (Yes, I’m serious.)
The convenience of using passkeys is a double-edged sword.
This is also one of the ways Playstation stops you from installing Linux and other unauthorised software on the PS5.
- 7 hours
It’s wild seeing people spaz out over passkeys, clearly venting at something that isn’t passkeys.
- 13 hours
Zero trust is the end station, if you allow organizations to treat your personal devices as being theirs. Organizations that could actually benefit from the increased security (which isn’t Twitter, except for some high-profile individuals, maybe), should provide the user with resources to do so, at their expense (issuing a dedicated TOTP device for example).
But what tends to happen instead, is enshittification of service, while offloading it onto the client. A similar trend can be observed with car parking: where operators remove parking meters, and require the customer to use their device and data plan, to make a payment to the operator…
We’ve been on this trajectory for quite a while now: from Outlook enforcing IT-policies of email administrators (dictating screen locking requirements as device administration app), to SMS-based 2FA requiring one to have a mobile phone number and tying all to this tamper-resistant identifier. So why not a black box snitch, paid for by the client, further restrict their freedom for “security”?
It seems perfectly in line, and I think this article draws all the right parallels.
- 6 hours
I didn’t even know what they were until now. And still don’t. Every explanation sounds like a long convoluted MLM pitch. They smell fishy as hell. They may need more grameters to prevent side fumbling.
- uszo165@futurology.todayEnglish16 hours
Passkeys mean a spread of enshittification to ever more areas of life. Specifically, they
- force me to use an extra OS on an extra device and keep it around just to use a site with passkeys.
- add insecurity and inconvenience. I neither can backup the passkeys nor use them on another device. (That’s not implemented on Windows.) This user experience is laughable in 2026. The passkeys are forever locked on the device where I created them. I am forever chained to exactly one device. If it breaks down, my life ends because our lives depend on digital technology.
- take away control from me and force me to trust third parties. I have to trust the hardware, the OS, the proprietary software, which makes me feel very uncomfortable as someone used to use Free software. Security by obscurity was always a bad idea.
- deny me anonymity and control over my accounts. I can have only one account per domain.
- are a black box with no user interface. With passwords I know exactly what account name and password I enter at which site. With passkeys I get asked for a PIN. That is all. There is no indication what exactly I authorize. This is a lot like clicking links in emails and giving your banking details to everyone who asks.
The recommendation “do not use them” is cute. They are forced on people. I can’t choose.
- 13 hours
I’m not familiar with any of these limitations that you described. Those might be limitations of the specific credentials manager(s) that you’re using. You might want to try a different one.
- 6 hours
Yeah I’m confused. I also don’t remember ever using a site tha would force use of passkeys. I always have standard TOTP alongside those.
- 16 hours
some of this is disingenuous. For example you’re supposed to make multiple passkeys for your devices so that you can still Access your Accounts even if you lose your Main device (Ofc its still shitty because this forces you into the cloud if you only have 1). Also thats why the passkeys being bound to their „birthplace“ is Not really more of an issue than the others. Also im Not sure where they are forced? In fact i wish it would be more supported in certain apps
- 14 hours
Indeed. Every device should get a passkey. Its like client certs where you can lose a device and just remove that passkey from your account. Also, you /can/ store passkeys in pure software. Bitwarden can store passkeys for example. Lots of options for FIDO keys too. I have never heard a non technical person give me a secure password strategy. That is 100% of nontechnical people I have asked use bad password schemes. Passkeys at least enforce a truly randomly generated key.
They still suck at usability but it is an attempt to solve a real problem. Basically the only thing standing between 99% of people and having all their accounts compromised is service password attempt rate limiting.
- 6 hours
That’s how they work, regardless of how users think. Though you’re correct: the majority of computer users don’t understand what they’re doing and do feel threatened by change, even if that change is positive by any measure other than “I feel uneasy about changing something I have no grasp on”.
- uszo165@futurology.todayEnglish16 hours
For example you’re supposed to make multiple passkeys for your devices How do I do this? Can you link to a guide?
Also im Not sure where they are forced? The big transition is underway. Switch to passkeys or you are out.
- 13 hours
Log in to a website that supports passkeys, go to the account security page, press add passkey. Your browser looks for connected security keys to add the passkey to or if you have an extension installed, it might start your password manager. in the security key case; It asks for your pin and it’s done. If you use a password manager to store it, it will ask you where to put it. Once done; you can repeat and add any number of passkeys to your security keys or database. You should do at least two, for redundancy.
I would not tie my passkey to windows/ios/android or whatever. I won’t let a third party manage or sync them. Only on a security key I own or my password database.
- 22 hours
Despite the attention-grabbing headline, the only negative thing I can find in the article about passkeys are this section:
Attested passkeys7 are the last but most important type of passkeys you need to know about. These types of keys use what’s known as remote attestation to cryptographically verify – using the aforementioned tamper-proof cryptoprocessor that lives in all your modern devices – that you are using one of the several approved passkey managers, and not using a custom one that you vibecoded yourself and which can lie.
This is the feature that means you no longer get to make the calls about your passkeys. Fortunately, attested passkeys are not yet required on most websites.
I don’t see why we should assume this hypothetical is going to happen. There is a lot of different software that supports passkeys (I use keepass for example), and going against the open standard and forcing all their users to use a specific software would basically make them unusable.
Overall every password / login style has its dangers and bad ways to use it, including passkeys. That doesn’t make them “traps”.
- 7 hours
Ooohh, don’t think corpos and banks won’t go for that hypothetical. A lot of apps already turn haywire if you have developer options enabled, accessibility options enabled, have a specific installed or using a custom ROM. If the optional attestation is enforced by your bank that they only accept passkeys from google’s password manager or apple passwords, then using something like Keepass or Bitwarden isn’t an option.
Look… I love passkeys. They are convenient and more secure. But if a service cares about on what device and software it was created then it is pointless and just an ecosystem lockdown mechanism.
- 11 hours
The only area I could really see this taking off is with internal company stuff. Like forcing employees to use a very specific and weird way to do 2FA is already a thing in a lot of companies. They won’t let you just use any old authenticator app. You need the “special” one that sucks ass. So maybe they’ll do the same to passkeys, but for normal users I don’t think they’d do that. Users are way too bad at doing things. It would cause too much of a tech support burden or just user bleed.
- 22 hours
A lot of platforms will happily not allow people to login with a KeePass passkey. Just like some platforms already no longer let me login with a password and force me to login with a code they send me per email instead.
- 20 hours
Also, like, if it doesn’t allow me to set up a passkey because my manager or OS is not supported…I guess I’m not setting up a passkey then, which is OK by me, so there is no problem.
- 1 day
Pepperidge Farm Remembers when the FIDO Alliance threatened to recommend the blocking of FOSS implemententions because they gave the users control. Control over backing up. Control over not using biometrics.
When something wants too much power, you must avoid.
FIDO 2 level 2 also requires the supply chain documented and a bunch of expensive certificates, which locks small vendors and open hardware implememtations out.
- 19 hours
So… Uh… What’s a passkey? The article is saying they’re pure evil. Everyone here is saying they’re good. Everyone knows what they are except for me.
What’s the difference between a passkey and a password?
Imagine if a romantic partner said “I will send you a unique string, probably exactly 8 characters” to verify that I am your partner. You would laugh and remind them it takes less than a second to generate every 8 character combination possible.
Instead, your SO makes a key and keeps it with them at all times, and you promise to talk to them using a machine that makes secret messages only their key can decipher. For fun, they give you a key and make a machine too… Explaining this shit is complicated I’m sorry for what you’re about to read.
They send “heyy”, You send “whatup”, They send “send pics”, You take one, encrypt and send the pic, They say “huh? Wtf?”, You remind them about the secret key, They have no idea what you’re talking about -fail OR they send something in return back (which you decrypt) -success
That’s basically the same thing as authentication with a passkey oversimplified and only slightly wrong but good enough. There’s shitloads of devices that do it, yubikeys, authenticator apps, but they’re all doing that.
- 3 hours
It’s something you pass around–like a word, but a key instead. If you’re familiar with passwords–instead of a word–imagine a key: a passkey. That’s what passkeys are. The issue with passkeys is–as you pass them around they begin to open more and more stuff; everyone is opening stuff with your key as it’s passed. So they need to be sanitized every now and then. Deposit them into a furnace and buy a new passkey. Every two to three days. If you have more questions please feel free to ask!
- 13 hours
Password is a shared secret: When you want me to prove myself, i repeat the password we both know. Both of us could loose that password and it happens every day. Can’t go a day without a major data breach news.
passkeys use public-private keys. Anyone can posses the public key, so that is ok to leak. The private key you keep to yourself. When you ask me to prove myself, you hand me a challange which i manipulate with my private key and hand back to you. You check it with the public key and conclude that i am indeed the one that posseses the private key. Mathematical magic! The private key was never shared.
For the user, the password is replaced with a file stored somewhere. Either in your usb security key or in your password manager of choice. Stored in a security key (aka authenticator), the private key never leaves the authenticator and all cryptographic operations are done inside it. The private key can’t leak. Amazing! Passkes in a security key are called hardware bound, very secure and nice. The security key, you can plug out and take with you. There are built in hardware like this in phones and computers. But you can’t take that with you. That sucks. They only authenticate that device. But you can make any number of passkes for all your devices.
The bad part is that some big corporatins would like to control where and how you can store the passkeys and preferably make it harder for you to escape them. The solution is to not use the services of these malicious corpos.
- 6 hours
Nice explanation!
Can you elaborate on this part?
some big corporatins would like to control where and how you can store the passkeys
- 3 hours
Attestation means that whatever code runs on your authenticator has been submitted to the FIDO Alliance (google and buddies) and they signed off on it. After that it can’t be changed.
Security keys like the Solokey Hacker (the superior version), is not signed and never will be, cause I can tinker with it in any way I wish. It’s truly mine.
Like the article highlights, attestation is part of the standard. The remote service can ask for cryptographic proof that your authenticator, where you stored your passkey, is attested. I have not seen any service doing that so far. IT managers are doing that internally, for their employees for sure. They don’t trust bobs homemade solution, only their chosen vendors. From that standpoint it’s reasonable.
This gives the service the power to deny you freedom of choice of where to store your passkey. They might say only yubikeys allowed or only microsoft hello or only IOS secure enclave or whatever they wish. It might become a scenario where they don’t allow any passkey solution that can run outside their platform. Running LineagOS or Linux? Google and microsoft will say it’s “not secure enough”.
They will abuse that power to make your decision for you and lock you in. “Password manager not allowed, Use our cloud insted”.
Ideally it’s not part of the standard and they don’t get the option of knowing anything about your authenticator. It’s none of their bussines how i choose to store my secrets.
Any sane service will just not ask about the attestation. They don’t have to ask. I would not ask my users on my webpage. You can store your passkeys on printed paper for all i care. Although, storing them on a usb/nfc key is pretty damn secure and cool!
- 5 hours
Personal anecdote to illustrate: the last time I tried creating and using passkeys for my Google account, I got the impression they (Google) would only accept keys coming from either Google Authenticator (their 2fa smartphone app) or something like macos’s built-in keychain. No way to give them a key generated using a local, offline service that I could store however I want - it needed to be accessible using, basically, a big corpo['s software] as the intermediary. This coming from how their website would request the keys from my browser (which means mozilla seem to be in on it as well :/).
Given that I currently use a pure file-based password manager that I can move around and switch the keys for as I please, the current state of passkeys feels like a step back in terms of allowing me to control my digital identities.
- 17 hours
So in order to log into most websites, you need your username/email address and a password.
You can save your username/password in your web browser or in the cloud.
Sometimes people get lazy and reuse passwords, sometimes people forget their passwords.
Passkey is a replacement for usernames/passwords. It does require that the passkey is saved somewhere, often on your device (in the cloud is possible, but non-standard).
When you “create” a passkey, this passkey is used only at a single place. For example, you’d have a passkey for your bank, another one for your email, another one for Lemmy. You have no say in the matter, that’s just how it works.
When you log into a website that has passkey enabled, your passkey/password manager pops up, you click on the passkey and that’s it. There is no email address, there is no password, no MFA.
edit: oh, you also asked about the difference between passwords.
It’s all about improved security.
You go to certain websites, and they’ll only allow a-zA-Z0-9, others require a minimum length of 8 characters, needs 3 symbols (except ! for whatever reason ;)
Then you have no idea how the website is storing your password. Are they encrypting it? Did they do it correctly?
If you look at the number of “breached/leaked” passwords on the internet, it’s because it’s hard to securely store passwords.
Passkey solves all this. Websites are just given “a public key” and it can be “just stored”, no special treatment necessary.
- 13 hours
10 PRINT "So in order to log into most websites, you need your username/email address and a password." 20 PRINT "" 30 PRINT "You can save your username/password in your web browser or in the cloud." 40 PRINT "" 50 PRINT "Sometimes people get lazy and reuse passwords, sometimes people forget their passwords." 60 PRINT "" 70 PRINT "Passkey is a replacement for usernames/passwords. It does require that the passkey is saved somewhere, often on your device (in the cloud is possible, but non-standard)." 80 PRINT "" 90 PRINT "When you "; CHR$(34); "create"; CHR$(34); " a passkey, this passkey is used only at a single place. For example, you"; CHR$(39); "d have a passkey for your bank, another one for your email, another one for Lemmy. You have no say in the matter, that"; CHR$(39); "s just how it works." 100 PRINT "" 110 PRINT "When you log into a website that has passkey enabled, your passkey/password manager pops up, you click on the passkey and that"; CHR$(39); "s it. There is no email address, there is no password, no MFA." 120 PRINT "" 130 PRINT "edit: oh, you also asked about the difference between passwords." 140 PRINT "" 150 PRINT "It"; CHR$(39); "s all about improved security." 160 PRINT "" 170 PRINT "You go to certain websites, and they"; CHR$(39); "ll only allow a-zA-Z0-9, others require a minimum length of 8 characters, needs 3 symbols (except ! for whatever reason ;)" 180 PRINT "" 190 PRINT "Then you have no idea how the website is storing your password. Are they encrypting it? Did they do it correctly?" 200 PRINT "" 210 PRINT "If you look at the number of "; CHR$(34); "breached/leaked"; CHR$(34); " passwords on the internet, it"; CHR$(39); "s because it"; CHR$(39); "s hard to securely store passwords." 220 PRINT "" 230 PRINT "Passkey solves all this. Websites are just given "; CHR$(34); "a public key"; CHR$(34); " and it can be "; CHR$(34); "just stored"; CHR$(34); ", no special treatment necessary."- 10 hours
I wish I could give more than one upvote for the commitment to the bit on this.
- 12 hours
No, I mean the actual code. It’s been decades since I’ve used BASIC but a password programd would look vaguely like this:
10 x=1234
20 Print “What is the password?”
30 If user input equals 1234 goto 60
40 Print “Incorrect”
50 Goto 20
60 Print “Correct”
- 11 hours
Your 1234 example is stored in plaintext, which is bad practice but still happens sometimes. Usually 1234 will be hashed (irreversible and functionally unique string) and the user input gets hashed with the same algorithm to check against the server’s stored hash.
Passkeys are fundamentally different and work with public-private key pairs. It’s not possible for your public key to be “stored incorrectly” because it’s meant to be public. Your private key stays private and you never have to send it to the server to be checked against what they have stored. Instead, the server sends you a mathematical challenge that you solve with your private key. The resulting answer is also irreversible and functionally unique, but in such a way that the answer can be checked with the public key to make sure it was solved by the associated private key. It’s really clever math that’s worth watching or reading up on to understand.
I don’t understand the maths well enough to give you a pseudocode example, but I always found trying to simplify it made it difficult to understand anyway. Every analogy ended up falling short because it was an analogy and not what was actually happening under the hood.
- 14 hours
Imagine instead of inventing and storing passwords in your head and typing them in each device. With passkeys each device generates a real, cryptographically strong password for each site and stores it in a secured part of the device. Nothing to memorize.
Sites must now to let you have many passwords so you can have many devices without needing to sync between devices like a password manager might do.
No one can guess your password and it is never reused because they are machine generated. They are protected on device by the security of your device (typically behind a pin) so if you trust your OS, it is safe (which, in effect is the same as passwords you type).
Unfortunately, the experience still sucks and shitty companies might use them to further lock people in if they end up with all their passkeys on one iphone, for example.
- 6 hours
Oops, I lost my device or bricked it, now what? Login with passsword? Password reset?
- Helix 🧬@feddit.orgEnglish4 hours
Password reset, and your mail account used for that is secured by a passkey 😬
Please send a blood sample to Google Gemini to confirm your identity.
- 10 hours
Microsoft has been a major annoyance on me with passkeys. I don’t like not knowing for sure that I can get back into an account if any of my devices get fucked (authenticators are nice and I do have some things setup but always worry if my phone is broken or lost out of nowhere). They (Microsoft) have such a dark pattern way of pushing passkeys. When I have to help someone get into their MS account at work (normal consumer PC stuff not IT/corp stuff) which is already hard since the people I try to help already don’t tend to realize how important even simple things they don’t think about WILL fuck them later. Some examples are stereotypical “boomers” that default to adding their land-line when an account asks for a phone number, or that they were even making an account (another dark pattern from Windows 8 where sooooo many people created @outlook.com accounts without really paying attention).
Obviously I experience a higher than average amount of tech illiterate folks (that also seem to just not care like shit is still the Windows 7 and earlier times). But Microsoft pushes dialog prompts/boxes for physical security keys and passkeys in a way that at first seems like the person has one of those setup. In some cases trying to sign into an account without a passkey/security key it will do what I expect. Give an extra option to not keep using a password or password+text/email code, or setup passkeys to “not have to worry about remembering passwords”. Though I still think they don’t really clearly explain how crucially important it is to make sure the person’s information for the account is correct and making damn sure to know recovery options if anything happens.
But I started seeing just a box pop-up that looks like a system prompt that only gives two options. Enter your PIN/insert security key, or to use the authenticator app. No obvious option for picking that neither are setup. The only way for not using those is to click the X on the top-right of the prompt. In some cases I have seen people click on the options and it just acts like they are setup. Pick the authenticator option and it asks for the code on an app/device that doesn’t exist. In the cases that it does start the process of setting up passkeys, I still feel like they are trying to trick people into it rather than the users choosing to do it.
Again I deal with more than average “I’m not a ‘techy’!” kinds of people along with older folks. But it really does seem like any level of tech literacy keeps getting worse based on running into more and more people of all ages. Which is what freaks me out about how these things are suddenly seemingly pushed on folks at the worst moments. A lot of people first trying to setup their new device just want to get into it as fast as possible, and really don’t understand how they can just lose access to so many things they didn’t realize are now tied together. Let alone be aware that they should export those things to something that isn’t tied to the OS in the event they for some reason want to get something else (PC to Mac/Mac to PC/Android to iOS/iOS to Android/etc).
- 16 hours
As the article states, they’re an extremely malicious solution to a problem that has better, simpler, and easier to understand solutions.
It’s also a very good solution to the “problem” of users being able to do things our corporate overlords don’t want us to do.
In short, they’re even worse malware than the ones they’re sold as protecting us from.
Enshittification manifest.
- 6 hours
problem that has better, simpler, and easier to understand solutions.
Can you give an example?
- 19 hours
Sounds like a turbo encabulator.
Also, that website is full of sand traps. Every time I accidentally mouse over something, a huge menu covers up the definition.
- Klox@lemmy.worldEnglish1 day
This is some weird doom and gloom take on a real improvement in public security that we don’t see very often. Of course there are a lot of stake holders. Of course every protocol is complicated. I run security for a company, and my auth systems mandate attested (i.e., company-provided) hardware keys. You’re not using a passkey on my systems that I’m not providing you. Pretty simple concept, yes?
Do you have any examples of any public service requiring attested keys? No, because it really doesn’t make sense. But because the protocol supports it, people shouldnt use passkeys? Shitty hot take.
I agree it would be helpful to make the feature set clearer to the end user, but the UX are still a mess across OS and websites. IMO that’s not a reason to not use them.
Passkeys are much more phishing resistant. They apply unqiue-credential best practices. I’ve been managing unique passwords for decades, and passkeys are a great improvement. Very few companies are going to completely remove other forms of auth, and so suggesting passkeys are ruining people’s ability to share passwords is really premature. And even so, companies have been pursuing other strategies for identifying shared accounts much more effectively than shared credentials. Thinking that’s a reason to not use passkeys just tells me you aren’t valuing how passkeys elevate public opsec.
Passkeys are projected to overcome TOTP market share next year. That is honestly amazing. I like the writeup on the features, but this nefarious, conspiratorial narrative doesn’t fit what’s actually happening.
- 1 day
My background is very much not in this world so caveat my questions/response below with that mind set. I do however try to practice decent personal opsec such 2fa (TOTP), password manager with random generation, etc.
I feel like a lot of what you stated was covered in the article. For example the article states that problem isn’t the number of stakeholders, it’s that none of them are consumer advocacy groups.
I understand that the author maybe leaned on the password sharing example too much but I think that was in an effort to present the material in a friendlier manner to the average reader. The closing statement makes it clear it’s not really about Netflix, etc. The main concern is that attested passkey requirement will now be the easiest way to force specific software and hardware upon user. The GraphenOS example is a good one.
You might not use the attested flag in that manner but I have zero doubt that once passkey adoption rate passes a certain threshold Google will be more than glad to miss-use that flag to lock people out of their gmail account unless they have the most recent phone and software.
Do you have any examples of any public service requiring attested keys? No, because it really doesn’t make sense. But because the protocol supports it, people shouldnt use passkeys? Shitty hot take.
I think this is a bad take. “Because this potential is not being misused right now it won’t be a problem in the future” has not really served us well thus far.
My understanding is that the article is saying that passkeys are giving away too much control to the second party. That can and will be abused.
But again, layman’s understanding from my end.
- 12 hours
The main concern is that attested passkey requirement will now be the easiest way to force specific software and hardware upon user. The GraphenOS example is a good one.
Exactly, and it doesn’t take any effort to come up with software that will make it impossible for most people to even consider doing things a different way than big tech wants them to. Download the wrong app, use the wrong OS, attempt in any way to reclaim your privacy, and all of a sudden you can’t be authorized to open your own banking app because of some bullshit “security” message. What option does that leave you? Either become a hermit and reject all technology with whatever cost that has for you, especially in a decade or two as technology transitions to something completely mandatory for everyone, or fall in line and use everything the way they intend you to.
- 7 hours
This is already the reality without passkeys. The correct response is to bank with a bank that isn’t enabling Google’s monopoly. Pretend passkeys don’t exist–nothing’s changed. You still can’t use your bank’s app without a Google Account if your bank is an enabler of Google’s monopoly. So… again, myopic dimwits are getting angry at something, but don’t know what. They’ve latched onto passkeys though. Amusing.
- ChunderBustickles@piefed.nzEnglish2 hours
sorry, not OP but I’m not following your logic.
Are you assuming everyone’s using a Google wallet or something (what’s tying one’s bank to Google?).
Fuck that - that’s why we have credit cards…
- 42 minutes
No, I’m not assuming people are using a Google wallet.
Most businesses only release an android package via Google’s PlayStore. (“Download our app via PlayStore.”)There’s no reason a bank couldn’t host their .apks on their website (if you’re unfamiliar with the .apk extension imagine it’s a .exe: you click on it and a program runs; an .apk is to Android what an .exe is to Windows). To download packages from Google’s PlayStore requires a Google account. Google demands a few things from these two parties: publishers need to pay Google a fee to have their .apk hosted by Google and users need to run Google’s spyware in order to access those .apks hosted by Google.
It’s often stated that if you want digital-freedom/privacy use GrapheneOS (if you have a compatible Android-device) or use a linux mobile-phone. To which most users respond: but my bank app doesn’t work on those platforms, therefore I won’t use either GrapheneOS or a linux-phone.
The bank app won’t work, because Google’s spyware is not included in GrapheneOS (a point of GrapheneOS is to avoid such spyware). Because GrapheneOS (or linux) doesn’t include Google’s spyware Google will do its best to block such devices from accessing Google’s PlayStore. Such computers are violating Google’s demands: if you want access to the PlayStore you have to run Google’s spyware.
Even if you were to get the appropriate .apk by avoiding Google directly (perhaps a friend who got it from Google then passed it to you) the bank’s .apk would fail to run on a device free of Google’s spyware, because you’re not capitulating to Google’s demand: you didn’t get it from Google’s PlayStore and the ‘app’ knows that by the lack of Google spyware. (Google’s spyware and the bank ‘app’ talk to each other. If the app can’t talk to Google’s spyware it will halt.)
Therefore if a bank only has an ‘app’ to interact with that bank is saying: you have to download it via Google’s PlayStore–which necessitates a Google account and running Google’s spyware. Therefore if you want to use banking ‘apps’ you need to enable Google’s monopolistic, spyware practices (you have to enable the corporations to practice surveillance-capitalism). Google defends this practice often with security-theater (“Google says it must be done this way for security.”) when in reality it’s about entrenching a market monopoly.
This is absolutely removed and I do deride users who say they want computing-liberty and -privacy, because there are banks who still have usable websites. You don’t have to bank via an app. If you do bank via an app you do so with full acknowledgment that: a) you’re rewarding anti-competitive behavior; b) you’re entrenching Google’s monopoly over Android; c) you don’t actually want computing-liberty or -privacy.
It’s piss easy to change banks. It’s impossible to stop Google. If you want privacy you have to ditch Google, which means banking with a bank that allows you to bank via a desktop-computer (via a website) or in-person through bank-branches. If the only way to bank with your chosen bank is via an app that then means the only way to bank with your chosen bank is by enshrining Google’s monopoly into your life.
Passkeys are a completely separate thing. They’re an increase in security for all users. Users are frustrated by ‘big tech’s’ increasingly monopolistic practices and instead of doing anything practical (like not running those particular pieces of software) they’ve latched on to decrying passkeys, which the majority of the commentators are actually clueless about. They’re just seeing those ‘big tech’ companies forcing yet another change onto them. They’re lashing out against their lack of power. They’re lashing out against their subjugation by ‘big tech’. That they’re being forced to use “passkeys” when they don’t even know what a passkey is.
Passkeys are an open standard. They’re not entrenching anyone’s monopoly. Increased security is desirable by all parties (corporations, governments and individuals). Passkeys enable that. You’re not locked into Google’s Android, or Microsoft or Apple. People are under the assumption they are however.
I could host my own website using passkeys as the method for authentication. No big-corp involved. Offline. Spooky. Big-passkey is coming for you.
That probably left you with more questions than answers…
- Klox@lemmy.worldEnglish22 hours
Happy to discuss a few points you’ve brought up.
it’s that none of them are consumer advocacy groups.
I would put that more as a curiosity than a red flag. I doubt they were excluding groups, but happy to hear about if they were (e.g. donation minimums or something to that effect). The author actually says that whole paragraph is “notable” – great, noted. I hope that doesn’t mean they were using it as an argument for “Do not use [passkeys]” (the title of the article). FWIW, W3C recommends use of passkeys. EFF has had blog articles for 3+ years suggesting advantages of Passkeys. I also don’t know what a consumer advocacy group would suggest differently here – DONT implement an attestation spec? Attestation is a massive improvement for specific types of security.
The GraphenOS example is a good one.
I went and looked for what you were referring to and didn’t find anything. What do you mean by this? I use GrapheneOS. I use passkeys. Google being hostile to third party OS doesn’t seem related but maybe I am missing something.
I have zero doubt that once passkey adoption rate passes a certain threshold Google will be more than glad to miss-use that flag to lock people out of their gmail account unless they have the most recent phone and software.
Well this seems like a reasonable point I should expand on. Maybe I can plant a seed of doubt about this hypothesis. A few comments:
-
People being locked out of their email is actually one of the biggest logistical nightmares for email providers. Proving someone is who they say they are is actually fairly difficult as well as doing it at scale. People lock themselves out of their own email. People get locked out of their email because of phishing attacks. In practice, Passkeys reduce phishing rates significantly. That’s a massive win for email providers in reducing their burden. Intentionally locking out a massive number of their customers is an unthinkably bad move, comically bad. It wouldn’t happen.
-
Email is the most important mechanism of communication for people’s security. Bank and financial accounts, paid services, government notices… they are almost all through email. The idea that they will vendor-lock email to specific hardware… it’s not realistic. They would face such massive PR And public blowback. Email is also accessed from more than just your phone. “Requiring” an attested phone would kill a massive use case.
-
People already feel locked to their email provider – it’s extremely difficult to change all contacts you have to a new email address. Passkeys don’t change that. Phone hardware doesn’t change that. So I’d say it’s just a continued problem, and not a reason to not use passkeys.
-
The FIDO Alliance had like three phone manufacturers out of 250 members.
Overall, I don’t see how passkeys, or attestation, could lead to a world where any public service would want to require attestation, and even if they did, there’s no reason it would be “requires my X branded phone”. These companies supported the development of this protocol for the specific reason of NOT wanting to cater to specific vendors. This is a vendor-neutral specification. There are many hardware and software providers. They all have their own motivations, and they hope implementing the spec brings in more customers, improves consumer security, and reduces their operational costs. Do you still have zero doubts about a future world with vendor-locked attested passkeys for public services?
passkeys are giving away too much control to the second party.
There are already dozens of hardware and software passkey vendors. It’s honestly amazing how little lock-in there is. There’s a half dozen FOSS authn services providing passkey services. You can buy dedicated hardware for passkeys from multiple independent companies. What “control” are you referring to? Companies could always force rotate your password, make it invalid, etc. Any control you thought you had was an illusion.
Cheers
-
- SteveGoob@lemmy.worldEnglish19 hours
There are lots of reasons to like passkeys from a technical/enterprise standpoint, but I do think you’re missing the critical issue the article is speaking to: digital sovereignty.
Passkeys, while more secure in the average usecase, shift the balance of control over your access to services. Yes, you can no longer write your password down on a post-it and leak it in a photo—thats’s a good property. But trading that at the expense of your freedom to run software as you see fit on hardware you bought and paid for? For many people, myself included, that’s not an acceptable tradeoff. There are plenty of tools and systems around passwords that folks can use to make passwords+2FA match or even exceed the security properties of passkeys.
The thing that should chill everyone is the fact that built into the standard is a switch (given to service providers, not users) that locks out the people that do want to have control of their digital infrastructure. Not everyone can or should be expected to run like that, but they should not be blocked from doing so. Similar with the Right to Repair; not everyone can exercise that right on their own, but no one should be prevented from repairing what they bought.
Similary, I do believe it’s my neighbor’s right to practice a religion of their choosing. So if the government tries to prevent them from doing that, I’m going to go grab my pitchfork, not because I share their religion, but because they should be able to make that choice. Likewise, while I might not want to exert control over how my credentials are backed up, I still reserve the right to do it, and support anyone else’s ability to do it.
And to address the slippery slope objection, I have to point out that this is not particularly theoretical. When Big Tech has provided service providers with the opportunity to enforce restrictions on your device, service providers have used it. Widevine DRM, Google Play Protect, etc… It’s why my LineageOS phone can’t use banking apps, which is a shame since some features like Zelle payments are specifically a mobile-only feature, and so I cannot use it anymore. I either run my phone to the exact specs and settings that my bank and Google prefer, or I’m denied access to basic banking anywhere but my desktop (and who knows how long until the block my access there, I run Linux afterall).
I do not trust Big Tech with my devices, and passkeys increase their capability to deny anyone who doesn’t buy into their ecosystem, and further entrenches those who already are. I for one find that despicable, and an unacceptable tradeoff. There’s no reason it has to be this way though, passkeys could have been the best of both worlds. However, they’ve been compromised with features that serve platforms at the expense of user freedom. It’s the kind of disempowerment that happens when you give the reins to power-hungry, profit-seeking corporations.
- Klox@lemmy.worldEnglish18 hours
There are plenty of tools and systems around passwords that folks can use to make passwords+2FA match or even exceed the security properties of passkeys.
Likewise, while I might not want to exert control over how my credentials are backed up, I still reserve the right to do it, and support anyone else’s ability to do it.
Widevine DRM, Google Play Protect, etc…
I do not trust Big Tech with my devices, and passkeys increase their capability to deny anyone who doesn’t buy into their ecosystem
I can only speak for myself, but I hold all of those values you claim. I see no evidence, technical or otherwise, that passkeys are subverting or acting counter to any of these principles. Frankly, it’s a baseless claim that passkeys lock people out of their own control/infrastructure. I think people conflate non-transferable, TPM passkeys with passkeys. Just don’t use that if you don’t want to.
FWIW, passwords were never “yours”, they are PSK (Pre-Shared Key) with a service. Maybe you invented the credential, but it’s not yours. You have historically enjoyed being able to bulk export credentials, and if that property is important to you, then you should be using transferable passkeys. Passkeys have a well-defined transferable format – if they are the type that can be exported.
I can only continue repeating that the passkey spec is public and transparent. If the service is not supporting passkeys in a way that you want to use them, then complain to that service. I don’t decide that service X doesn’t support transferable passkeys, but they should.
DRM and other gate keeping efforts, IMO, are tangential to passkey support. Passkeys are fine, vendor-locking and walled gardens are not.
- SteveGoob@lemmy.worldEnglish17 hours
I see no evidence, technical or otherwise, that passkeys are subverting or acting counter to any of these principles. Frankly, it’s a baseless claim that passkeys lock people out of their own control/infrastructure.
The evidence is in the fact that the passkey standard provides the means to deny service to anyone whose passkeys do not match the service provider’s preferences. This is a non-issue with passwords, since there’s no way for a provider to tell whether or not, for example, a password is simply remembered, stored in your password manager, backed up, shared, etc… The threat model of the user can inform what choices they make there. The platform may require certain things of the password, like length requirments or another factor, but it ends there.
You’re correct in that the standard supports passkeys with similar data sovereignty properties; however, the standard includes controls that allow service providers to dictate that those properties be configured to the provider’s preferences, not the user’s.
Just don’t use [locked down passkeys] if you don’t want to.
It would all be well and good if that were actually entirely my choice, but it’s not. The standard specifically includes a trump card for the service provider in the form of remote attestation. You seem to think that’s tangential, but I reject that. It’s kinda the whole point.
Authenticating based on a shared secret is an interface with a special property: there’s no way for a service provider to know how you remember a secret. That guarantee is extremely important. Service providers accepting password based authentication are guaranteed to not be able to enforce requirements on how you remember your password.
The Passkey standard removes that critical protection by explicitly supporting remote attestation in the standard. It does not matter that the standard is public if it does not preserve that guarantee.
Passkeys are fine, vendor-locking and walled gardens are not.
If you’re not a fan of walled gardens, I would recommend against giving corporations the mortar, bricks, gates, and locks with which they use to build them. Maybe they won’t use them in ways you don’t like, but you’ll never have a guarantee that they won’t.
- 13 hours
means to deny service to anyone whose passkeys do not match the service provider’s preferences. This is a non-issue with passwords, since there’s no way for a provider to tell whe
Yes it is. I have had to work with many companies that set password specifications, and sometimes they prevented secure passwords. My bank maxed out at 11 characters for many years!
You dont own the specification for a password, the service provider does. I always wanted to use deterministic password generation (i.e. hash(servicename + memorable password), but never could because every provider has different “password rules” about different character types, etc.
- Klox@lemmy.worldEnglish16 hours
IMO you’re reading way too much into the value proposition of passwords. Services can “deny service” for arbitrary reasons already with zero consequences, but your idea is that they will ban based on… passkeys? You’ve got people banned from youtube for arbitrary comments. You’ve got MS locking out non-profits for arbitrary reasons. But in your mind, those all pale in comparison to what will happen if we all start using passkeys? I’m not buying what you’re selling.
You seem to think that’s tangential, but I reject that. It’s kinda the whole point.
I didn’t say it was tangential. Attestation is for very specific purpose. Non-attested credentials are not sufficient for government and corporate security. I cannot allow BYO hardware to authenticate my users on my services. I highly doubt any public service would require attested passkeys. I doubt passwords will stop being allowed, almost ever, so you probably have nothing to fear. Maybe you can throw that comment back in my face in 20+ years, heh.
Here’s another counter-point: Google, Apple, et. al already implement proprietary authentication mechanisms. Sign-in prompts on recent devices, email codes, etc. are all proprietary. None of these companies killed passwords despite having implemented the tools to do exactly that with vendor lock-in. All the evidence is the opposite. This is one of the first times we’re even getting an open standard authentication, the exact opposite of “walled garden”.
Authenticating based on a shared secret is an interface with a special property: there’s no way for a service provider to know how you remember a secret.
The same special property that allows rampant attacks on the public. I deal with so many people with compromised email inboxes, malware installs, stolen credentials, etc. Passwords are not the end solution to end user security, and I welcome improvements that also simplify UX.
I think we’ve probably hashed out enough of the sides of the argument. Good luck to you.
- SteveGoob@lemmy.worldEnglish15 hours
But in your mind, those all pale in comparison to what will happen if we all start using passkeys? I’m not buying what you’re selling.
Because you appear to be misunderstand what I’m saying. Be careful to not put words in my mouth. I said nothing regarding bans.
I am, however, arguing that a service provider can reject your passkey if they dont like how you manage it, (e.g make it copiable). To access that service using a passkey, you’ll have to accept storing your credential on their terms.
And to be clear, I’m in no way blind to the issues with passwords. We’ve had to tack on a bunch of extras to have password based security keep up, like TOTP, password hashing, recovery methods, phishing resistant tokens, security questions, and so on. I’m not arguing that passwords are perfect; I’m arguing that they preserve the users ultimate control over the credential. I’m totally open and hopeful for improvements to authentication as long as they similarly preserve the user’s freedom to manage their credentials as they see fit.
And this may be where the difference in our values shows, since it appears that you view the user’s freedom as more of a problem than a boon:
The same special property that allows rampant attacks on the public. I deal with so many people with compromised email inboxes, malware installs, stolen credentials, etc. Passwords are not the end solution to end user security, and I welcome improvements that also simplify UX.
I’m sorry you’ve had to deal with that, but I simply don’t think some users making mistakes justifies allowing a service provider to remove a critical freedom from the user. I dont believe that improved UX and security has to come at the cost of user freedom, but that’s what passkeys explicitly allow for by design. I fundamentally disagree with that.
I didn’t say [attestation] was tangential. Attestation is for very specific purpose.
Fair enough, I tend to thow it in the same category as “DRM and other gate-keeping technologies” which you did call “tangential.” At the end of the day, for the purposes of my argument, they are the same: a service wishes to exert control over how a client runs, and I object to such limitions broadly speaking. The computers I own work for me, not the service. (Of course this changes in enterprises that own their own clients, like the workstations used by their workforce. But even in those situations, however, I would argue that there are generally more effective measures than remote attestation. But I digress…)
I highly doubt any public service would require attested passkeys.
Ah, but how can you be sure? You’re missing the guarentee that they can’t flip the script on you. The standard allows them to start forcing users to rotate their passwords and passkeys for ones that require attestation of their preferred settings. Maybe it’s unlikely, but “unlikely” is still a massive downgrade from “impossible.” IMO, it’s unacceptable.
Here’s another counter-point: Google, Apple, et. al already implement proprietary authentication mechanisms. …
Just because a standard is open does not mean it isn’t rigged in the favor of closed platforms. This is especially the case with passkeys, where platforms use them to further entrench you into their ecosystem, often under the guise of “look how good the UX is!” For example, MacOS really, really wants you to tie your passkeys to their keychain, so that they can control how it’s backed up, transferred, and stored. Remote attestation only makes this worse, opening the possibility that a service provider can enforce that you have to use MacOS’s keychain. Sounds like a walled garden to me.
- Klox@lemmy.worldEnglish14 hours
Apologies if I miss-stated your point and conflated service’s other arbitrary decisions with what you’re suggesting may happen with passkeys.
Maybe I have one follow-up question, there are a number of websites that just don’t use passwords at all. It’s always one-time codes sent to emails. Where does this fall on your freedom spectrum?
Do you have similar arguments about HTTP 3? QUIC? Web RTC? There’s so many protocols that could be used in a way to lock in users. Just because it has some bits in the schema, doesn’t really mean much. Particularly when it’s actually supplying a very real need in other contexts. Nobody wants 30 versions of passkey-alt protocols.
Cheers
- 5 hours
I’ll summarize the disagreement between the two of you in one sentence: what’s good for locked down highly secure enterprise is not good for public access services.
It’s understandable your factory has cops. We don’t wasn’t to have cops at home.
- 7 hours
Consumers are pent up and lashing out at passkeys. It’s wild. Like, you all still want to use the dictatorial software that is YouTube, Google and Microsoft, but passkeys are the hill to die on? lmao “No! How dare you provide cryptographic security!”
- 17 hours
FWIW, passwords were never “yours”, they are PSK (Pre-Shared Key) with a service. Maybe you invented the credential, but it’s not yours. You have historically enjoyed being able to bulk export credentials, and if that property is important to you, then you should be using transferable passkeys. Passkeys have a well-defined transferable format – if they are the type that can be exported.
This is the equivalent of Sony arguing that you never owned any games, you owned a license. Congrats. You’re the best kind of correct - technically correct.
There is no flag on a password that determines if it is transferable. There is no amount of “if you don’t like it, don’t use it” that will work out in your favor if you’re not in the majority. If you give corporations the power to limit consumption while increasing prices, they will eventually use it. Especially if they provide a product you can’t get anywhere else (and this is their goal for every product - even if they have to buy other companies to do it - even if they have to collude to offer the same service). It’s the foundation of our entire economic system.
- Klox@lemmy.worldEnglish17 hours
This is the equivalent of Sony arguing that you never owned any games
It’s far from that and bad analogies pollute otherwise very simple conversations. If you want a more apt analogy, this “debate” is shaping up closer to LED vs incandescent bulbs.
It’s easy to say passwords are sufficient when you’re one person practicing good op-sec. It’s not when you’re supporting thousands of people of varying technical proficiency, thousands of machines, thousands of services, and thousands of bad-actors. It was an even simpler time when 4 digit PINs were “sufficient”, but the world you and I live in is more complicated. Certain passkeys are transferable, so you’re not even losing out on that capability. Curmudgeon arguments aren’t convincing. Passkeys aren’t “giving power away”. Using passkeys doesn’t mean your giving up freedom. Passkeys have no bearing on the “economic system” and inflation. As far as the IT ecosystem is concerned, we’ve never lived in a more open and capable time. There are so many alternatives to every service (that isn’t tightly coupled to copyright). Of course companies are trying to offer unique products people can’t get anywhere else. None of this has to do with passkeys.
- 5 hours
Here’s what I don’t get. When I posted this, you were posting every 10 minutes at most defending passkeys. How do you have so much energy and time to defend them so vehemently? Are you heavily invested in a passkey business? Are you an LLM that’s been instructed to defend LLMs at all costs?
I’m not sure the latter is possible since you wrote a large paragraph starting with “it’s easy to say passwords are sufficient” when that has absolutely nothing to do with my opinion on passwords. I suspect an LLM would’ve stuck a little closer to my own words.
- Klox@lemmy.worldEnglish5 hours
No, I’m just a professional software engineer that has been in security and privacy for the last ~9 years (unrelated to passkeys). But I am also head of security for my company and rolled out updated hardware keys in the last year, so am somewhat more familiar with the topic as of recent.
I also generally enjoy discussing privacy topics. Even more so when I feel the community’s understanding is off /shrug. Was chilling on my phone while the kids were crashed this afternoon.
- twoBrokenThumbs@lemmy.worldEnglish20 hours
My issue with passkeys is the fallback. For instance, when the biometric fails, you can use a fallback login. That’s fine (and good that it exists). But the fallback for me is a pin number. That pin is far less secure than my password or a randomized TOTP number.
How do you handle that for your setup?
- lemmyvore@feddit.nlEnglish19 hours
Maybe you’ll prefer more practical criticism then:
To put it simply, every passkey is locked into a large combination of factors: device + platform (OS) + app + the service being used. It is not trivial and often downright impossible to change any of these factors or to render them agnostic. This makes it complicated or impossible to backup passkeys or make them portable.
It’s fine for them to not be portable when they’re used on a work phone, running the company mandated OS, authentication app and passkey store, to login into a suite of apps that are also company-approved.
I do need portability and backup as an individual who wants to be able to login into multiple services across multiple apps running on multiple OS on multiple devices. But I can’t, because the big tech players (Microsoft/Google/Apple etc.) are actively trying to capture passkeys into their platforms and make it hard to get out in any practical way.
With passwords and TOTP I can run something that will sync them across devices and fill them in into any app in a unified manner (or use copy & paste if all else fails). With passkeys I can’t.
- 13 hours
Passkeys can be transferrable and syncable ( see keepassx, bitwarden, and relatives). But ideally, eventually, you never sync them because every time you log into a service with a new device, that device gets its own passkey. No need to sync them and you can revoke a devices access if it is lost or stolen without effecting any other device. They are closer to client certs than passwords in that respect.
- Klox@lemmy.worldEnglish19 hours
I think there’s somewhat of a conflation of concerns. It sounds like your concern is, I have a credential manager and want to migrate to a new credential manager. I just want it to be simple to migrate my massive number of passwords, right? I need to bulk export + bulk import. EASY. But… what if your first password manager has a bug in the seed generator? Oops, you have to rotate 500 passwords now… there is no easy, off the shelf solution for that. It’s basically the same for hardware-bound passkeys. If you generate hardware-bound passkeys, you’re not going to simply replicate them to another hardware-bound passkey. The whole purpose of that type of credential, is to make it hardware-bound. There are a lot of meaningful reasons to do that from a security POV.
Now, I think what probably needs to be made clearer, is that if you do want that kind of credential, you shouldn’t be using TPM-backed passkeys. You should be purchasing independent hardware (FIDO2 hardware keys) or only make software+transferable passkeys. Personally, I have several hardware keys and I register them with one being a backup. If the vendor posts a vulnerability notice that there’s some big gap in their hardware, I will have to go and rotate every passkey. I know that is what I am signing up for, but maybe not a lot of people do.
- lemmyvore@feddit.nlEnglish18 hours
It sounds like your concern is, I have a credential manager and want to migrate to a new credential manager.
No. My concern is that I want to choose my own credential manager, and I want it to work with any passkey usage out there. And that’s impossible.
- Klox@lemmy.worldEnglish18 hours
Which credential manager, and which service is not working with it? Just looking for an example to understand what you’re struggling with. I feel like I don’t have these problems heh.
- lemmyvore@feddit.nlEnglish18 hours
What do you mean, which. All of them have this problem. You can’t force any platform owner to use your favorite credential storage when they decide they don’t want to. All of them will tell you “for my services you use my storage, period”.
- Klox@lemmy.worldEnglish18 hours
Literally just name a service that forces this. If it’s all of them, it should be pretty easy.
- lemmyvore@feddit.nlEnglish18 hours
OK, Apple. How do I use passkeys created on iOS for accessing Apple services, on a Linux laptop?
- 19 hours
I haven’t found this to be the case in practice (IE passkeys are plenty portable). I’ve successfully used passkeys on multiple browsers, OS’s, and apps, all stored using a FOSS password manager (keepass). Any FOSS password manager that is either self-hosted, or syncs, should work just as well with passkeys as it does for regular passwords or TOTP.
- 1 day
If your security relies on a password, you will always be anxious that somebody, somewhere, has somehow figured out what it is and already has access to your bank account.
No I won’t. All my passwords are something like
I0!2b6KJ!eA04WiJ&&MFToCQ7CN*4mvband each is used for only one thing because I’ve been using a password manager for over a decade.- Resonosity@lemmy.dbzer0.comEnglish22 hours
I switched to using a password manager last year that scrambles all of my passwords like how you describe, and hot damn is it nice, both in terms of security and convenience.
- 9 hours
Limiting password length is a red flag they are storing your password in plaintext. I’d be wary of using any service like that
- 20 hours
Most do. Source: I usually use passwords that long.
Maybe 1 in 10 don’t, and I find that annoying since 32 characters containing only lowercase real words and spaces has several times as much entropy as 8 characters of random mixed case letters, numbers, and symbols.
- 20 hours
I default to using 128 characters because that’s the max for the password generator I use. A surprising amount of accounts are OK with that, like more often than not. I have pared accounts down massively since using a password manager though, and use privacy respecting services when possible, so I may be self selecting here.
- 15 hours
It’s interesting to say more often websites are ok with that length. I do know that some websites truncate passwords so a long 128 character password may end up being a 16 character password and it all still works despite the password being that long.
- 14 hours
That’s why I always click the eye to see it if possible, and log in on another device with the password manager after changing/creating a password. I’ve only had that happen once or twice though.
- 10 hours
Even if the password box accepts the full string, some sites truncate it in the backend. A good test for this is to try logging in with your full password except for the last character. If that works, keep deleting characters until you can’t log in anymore, and then you’ll know how many characters it really supports.
Hopefully nobody still does this, though with the rise of vibecoding, who knows…
the vast majority of mine are +50 characters - you are just wrong. the services which strictly limit the length are rare and their security is suspect since they should be hashing your input anyway
- 21 hours
I mean it’s probably a good idea to have some kind of limit in place, because you really don’t want to deal with attackers trying to transfer megabytes worth of text in the password field and triggering an OOM on your end. But this limit should still be pretty high ofc.
for sure, but limiting it under 64 (the length of a sha256 hash) isn’t ideal at all
