[syllablehq]

It makes me so sad that it's 2023 and we haven't fixed passwords. There's no need for any of this. Your email account (+ multi-factor as desired) will always be the weak link, so just reduce everything to that. Get rid of passwords.

Create a new standard that falls back to passwords to work with legacy systems, but going forward will enable a password keepers to just authenticate you with a generated random password saved encrypted to your cookies that the user never even has to see. Then reset it as needed through your email (+ multi-factor as desired) as needed.

User-visible passwords should die. Technologists should to get un-stuck from living in the current password paradigm. I've been wanting to make this rant a blog post but haven't gotten around to it - esp because I know it's been written about a million times already.

[Longhanks]

I absolutely despise everything in this comment. I have a user name and I know the associated password, let me in. Leave me alone with your proprietary authenticators that will lock me out the moment I lose my phone or Google/MS just _decide_ they feel like locking me out.

GitHub force-disabling password authentication for git push has actively made me contribute less to GitHub-hosted projects. And when I really feel it, I just create a full access authentication token anyway and copy the contents to the device. Great. This is the 90‘s "password on a sticky note at the desk" all over again, just even more cumbersome and even less secure. Great job, everyone.

And no, passkeys/webauthn/vendor lock in #1864 won’t fix this.

[f1shy]

I really do bot understand the policy of github. Before I could have a 40 char password in my head. Now it MUST be somewhere in my disc. I was totally surprised as I learned is the only way to login. Seems a 50 year old idea

[Wool2662]

And yet the likelihood of you telling someone or typing the contents of this file somewhere you shouldn't is much lower. It's more phishing resistant and is much less likely to be in some leaked password database, that's what GitHub cares about. Targeted attacks on single people don't even move the needle.

Phishing and password stuffing attacks are like 95% of 'hacking' attempts.

And frankly it is very likely that your 40 character password landed in your shell history at least once.

[predictabl3]

GH also prefixes them and undoubtedly scans for and invalidates them.

I don't think I ever cringe as much as HN threads with people clamoring for backwards steps for security.

[kasdi]

Might want to check out 1Password CLI which can eliminate the need to store access tokens on disk.

[syllablehq]

I understand where you're coming from, and if you really want to have a username and password - yes, you should be let in. You should always be able to manually authenticate if you really want to. But I'm arguing that's it's time to automate and hide that process from the user experience. (multi-factor auth is another topic... let's put that aside for now..)

But the reality is that memorizable passwords simply does not scale in any world where we have to authenticate with so many services. It's time to shift paradigms. When you take a step back, it's clear that we're trying to shim a new password keeper system into an old password input field paradigm, and it makes no sense and it's holding us back.

Agreed that no one should be forcing a proprietary authenticator service on anyone. On the contrary, to avoid that, we need an open standard that is cross-compatible between proprietary services.

The open standard should make it easy for any browser, password keeper, multi-factor auth system etc to speak the same language and "just work" instead of hacking around with auto-filling password input fields for no reason. We're so stuck in an old way of thinking that we can't see that the password input field is vestigial and is only making everyone's experience worse.

[alternatex]

First time I'm seeing anyone suggest that MFA and biometrics are less secure than a password.

Also you have to consider that companies like Google, Apple, Microsoft, are making decisions based on what's good for most users, not a single user.

[f1shy]

I think they make decisions based on what is best for business (which may include locking you as much as possible in their platform) Very unsure that the named companies really do things for users good.

[WorldMaker]

For better and worse that is basically what Passkeys are trying to do. Using public key cryptography is a little more complicated than (symmetrically) encrypted cookies, but not by much. (And is overall harder to easily exfiltrate so works for more threat models.)

[syllablehq]

Interesting, I hadn't followed this in a while, and it does sound like this is getting closer to an open standard...

But it sounds like the discussion of it gets mixed up with other muck including biometric, 2-factor, proprietary tools, TOTP auth etc.

Seems we need a first step that ONLY focuses on abstracting the password away and still letting email be a natural reset.

Seems to me that the standard should simply allow someone to delegate their "passkey keeper" of choice to be the authentication engine that tracks tokens. It can be up to the user (up to their passkey tool) to decide everything else. But set up a system that let's us log in without a password, and without a proprietary auth system like google or facebook etc.

https://arstechnica.com/information-technology/2022/05/how-a...

[predictabl3]

Sorry, you just want passkeys. Just look into it more. "My password is auto saved in a cookie with 'fallback' to email" is a complete, complete non-starter.

I'd literally get dozens of emails a day. Absolutely not. Passkeys are the solution. Literally everyone whining and complaining and imagining up ideas in this thread ... It's webauthn and passkeys and can we stop wasting our keystrokes over it.

[WorldMaker]

Arguably that "first step" was BrowserID/Mozilla Persona which "failed" for interesting reasons, including the team was retasked by Mozilla for the failed Firefox OS and Persona never got good "engagement" on the wild internet and there was never a larger coalition around it as a standard.

For better and worse, the needs for biometric/2-factor/TOTP were the "trojan horse" to build better web auth standards that were cross-platform/cross-browser "coalition worthy". FIDO's WebAuthn has accomplished a lot that BrowserID failed to manage. The "mixed up other muck" is the reason that Passkeys even exist in the first place and the hope that they can accomplish what Mozilla once failed to do. Passkeys is just a "brand name" for using WebAuthn to try to kill passwords; all the other muck was already there before the brand name.

> Seems to me that the standard should simply allow someone to delegate their "passkey keeper" of choice to be the authentication engine that tracks tokens. It can be up to the user (up to their passkey tool) to decide everything else. But set up a system that let's us log in without a password, and without a proprietary auth system like google or facebook etc.

This is where the technology is going, it's just unfortunately never as easy as you would think "simply allow" to ever be. Passkeys aren't a proprietary auth system: they are built on WebAuthn standards, anyone can implement them (and many are). (WebAuthn itself isn't prone to some of the same centralizing effects of OpenID Connect either, Google and Facebook's logins being also built on "standards". WebAuthn is the standards that lit up cross-platform/cross-vendor multi-factor on the web in the first place. Passkeys just replace/drop factors.)

It should be up to users to pick the "passkey manager" they want to use. These are already many of the same choices users have for "password managers". (Apple iCloud Keychain, Android Password Manager, Windows Credential Manager, 1Password, BitWarden, Mozilla Firefox Sync, and more already support Passkeys and more implementations are expected to come.) On iOS (and iPadOS and macOS) the UIs for selecting your preferred "passkey manager" mirror and look almost exactly like the UIs for selecting your preferred "password manager". Those UIs were slow to arrive, as Apple rushed to get any Passkey support out the door as soon as they could, so a lot of people got the wrong impression in the early days of Passkeys, but those UIs exist now in most recent iOS versions. It's expected similar UIs will show up for Android and Windows (and various browsers) sooner or later.

There are also standards in progress for better key sharing between "passkey managers". Microsoft has been part of the champions group for that effort (stuck in the middle between iOS and Android more often than not for a lot of average users), but tools like 1Password and BitWarden would also be hopeful for greater compatibility for "import/export/share/sync" of keys between providers. I know a lot of people don't think passkeys will be ready for their preferred use cases until such standards are further along. In the meantime though, you can try to choose a personal lowest-common-denominator platform. (The iCloud Control Panel on Windows has limited Passkeys support for Chrome-based browsers if you need cross-platform reach from Apple's ecosystem, right now, for instance. Also, there is a WebAuthn backed QR Code-flow based Bluetooth LTE-based standard for delegating keys to devices like phones.)

It also is up to the user and their "passkey manager" a lot of the details of passkeys: key sync, key recovery, key types, multi-factor requirements. All of those currently vary across implementations, and there are ways we can likely expect them to always vary on details. (Apple's choices are based on what they were already doing with iCloud Keychain; those differ from Microsoft and Google's approaches, including a larger focus on E2E encryption. Apple disagrees with Microsoft and Google on "key attestation" that certifies specific keys come from specific hardware enclaves, which can be used to verify that certain biometrics and multi-factor options were already applied to the key before usage and also corporate "requirements" like device management, but also have privacy implications and recovery complications.)

Picking a "passkey manager" is a little more complicated than picking a password manager because there are more standards that need to be interoperated with, and many APIs are always going to be platform-specific and sometimes browser-specific (whereas worst case password managers can often route around things and at least fallback to nearly universal copy and paste APIs or keyboard "typing" automation). But "passkey managers" in the end should feel very similar to password managers for end users, including that most average users are likely to just use whatever the default is in their phone OS of choice (so most eyes are on Apple and Google to get these early transition days right).