Passkeys: The beginning of the end of the password • Hacker News Board

Re: Passkeys: The beginning of the end of the password

#351

Post by dannyphantom » Wed, May 03, 2023, 9:22 PM UTC

jimmar wrote: post #294

The paragraph in the section, "What are passkeys?" tells me that they: are new, are easier, let me use biometrics, and are resistant to attacks. But, it doesn't tell me what passkeys actually are. Compare passkeys to traditional authentication factors. What's a password? A secret word or phrase that only you know. What are biometrics? Parts of your body that can help uniquely identify you, like your fingerprint or re…

I'm not sure how it's all that different from Windows Hello.

> Passkeys are easy to set up and let you securely sign in to your Google Account using your fingerprint, face, screen lock, or hardware security key. You can create a passkey on this device, or use another device.

When I press [Continue], Windows Security appears where I can then scan my fingerprint which I already use to sign on.

A single glide of my finger worked as expected and a 'Passkey created' screen appeared with [Done] being my only option to continue.

After a sign out, re-enter of my gmail and these are the next few steps: https://imgur.com/a/heLrUkb

It seems like it just integrates the built-in verification methods depending on what device you are on.

Re: Passkeys: The beginning of the end of the password

#352

Post by XorNot » Wed, May 03, 2023, 9:26 PM UTC

doodlesdev wrote: post #95

XorNot wrote: post #89

Earlier quoted context omitted.

Imagine for a moment that instead of all the time wasted on this, we just implemented a protocol amongst the browser makers which allowed a secure password prompt to be requested, and required strong-hashing before sending anything over the wire? Which would be easier to use and more effective.

If you hash before sending anything over the wire then the hash of your password is now your password, meaning that if it leaks it amounts to basically the same as your password leaking. Granted, applications may choose different hashing algorithms, provide their own clientside salts, etc. which would be really nice. To be fair, I believe more systems should be doing this nowadays, it's really weird to have to send y…

If a common browser protocol required the password to be salted with an application supplied value and then rehashed with the domain name it's served on, there'd be no way to phish a password.

The value the user's browser sends back can't be reversed, so any website prompting from the wrong domain would only ever see an incorrect hash, rather then the cleartext as it does now.

Re: Passkeys: The beginning of the end of the password

#353

Post by dcow » Wed, May 03, 2023, 9:28 PM UTC

compiler-guy wrote: post #317

dcow wrote: post #179

Earlier quoted context omitted.

The solution, for you, is a cloud synced passkey manager, possibly a custodial one. A password manager with strong passwords is weaker than a password manager with passkeys, because passkeys use asymmetric crypto and passwords+2fa involve exchanging a shared secret over an insecure channel at some point (yes I'm considering 1-sided TLS an "insecure" channel here). Trust the security experts when they say passkeys are…

> Trust the security experts when they say passkeys are more secure. I trust the security experts when they say passkeys resist various attacks better than current systems... > Now, solving the UX to make it match that of passwords plus managers today is the problem, agree. ... but poor UX makes it likely the users will end up doing things that are less secure, not adopting them at all, or messing things up themselve…

Understood completely. I was only trying to articulate that there are tangible security benefits to using passkeys over passwords and no/zero theoretical downsides. A 32byte random password is just an edDSA private key that's not private, after all, and the two can be managed the exact same way with none of the device-bound woes. That is, all assuming that platform vendors commit to providing the same affordances for passkeys as they do for passwords in terms of allowing users to delegate to 3rd parties to complete signing of the WebAuthN challenge.

I also believe that Apple/Google/Microsoft understand the importance of not having a "I lost my device all my stuff is toast" UX, which is why Apple requires iCloud keychain to enable passkeys. They are making a pretty strong statement that the UX they imagine working for the masses is not some rigid "no cloud no syncing not here not ever" stance. So I think they realize it has to be a solution that doesn't have that failure mode. They're okay with soft keys, which is at least a relief.

Re: Passkeys: The beginning of the end of the password

#354

Post by guessmyname » Wed, May 03, 2023, 9:34 PM UTC

blackhaz wrote: post #346

rdsnsca wrote: post #202

Earlier quoted context omitted.

Apple, Google and Microsoft are all supporting passkeys https://developer.apple.com/passkeys/ https://arstechnica.com/information-technology/2022/10/passk...

class ASAuthorizationSecurityKeyPublicKeyCredentialAssertionRequest Now I'm wondering what's the longest class name out there...

> Now I'm wondering what's the longest class name out there...

The longest class names I remember are in the Java Development Kit (JDK) version 1.6, under the Swing+Nimbus namespace:

  com
  └─sun
    └─java
      └─swing
        └─plaf
          └─nimbus
            ├─...
            ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneCloseButtonPainter.java
            ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneCloseButtonWindowNotFocusedState.java
            ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneIconifyButtonPainter.java
            ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneIconifyButtonWindowNotFocusedState.java
            ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter.java
            ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowMaximizedState.java
            ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState.java
            ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMenuButtonPainter.java
            ├─InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMenuButtonWindowNotFocusedState.java
            ├─InternalFrameInternalFrameTitlePanePainter.java
            ├─InternalFrameInternalFrameTitlePaneWindowFocusedState.java
            └─...

There were threads in 2012 about them:

• https://news.ycombinator.com/item?id=4549685

• https://news.ycombinator.com/item?id=4770861

Someone copied the code in this repository: https://github.com/zxiaofan/JDK/tree/master/JDK1.6-Java%20SE...

Re: Passkeys: The beginning of the end of the password

#355

Post by ssss11 » Wed, May 03, 2023, 9:35 PM UTC

If I choose the screen lock PIN example (instead of face scan or finger print) why/how is that more secure and less resistant to attack than a password?

It’s a 4 digit number. What am I missing behind the scenes that makes it more secure?

Re: Passkeys: The beginning of the end of the password

#356

Post by augusto-moura » Wed, May 03, 2023, 9:36 PM UTC

Dalewyn wrote: post #312

jimmar wrote: post #294

The paragraph in the section, "What are passkeys?" tells me that they: are new, are easier, let me use biometrics, and are resistant to attacks. But, it doesn't tell me what passkeys actually are. Compare passkeys to traditional authentication factors. What's a password? A secret word or phrase that only you know. What are biometrics? Parts of your body that can help uniquely identify you, like your fingerprint or re…

Passwords will never be supplanted unless the new challenger can satisfy all of the following: * Easy to understand. (A password is just a word/phrase/string of characters only you know.) * Easy to use. (Using a password only requires remembering and typing it in when prompted.) * Convenient. (Only your ability to remember and type required. No other tools or gadgets required.) * Simple. (All of the above.) If someth…

I'm not sure if it is passkeys or other mechanism, but I can easily open my bank account on my Android phone just by using biometrics. Instead of typing a pin or password I just do the biometrics and voilá, it opens like magic. That really made me appreciate passwordless apps.

On the other hand, I don't really know how would that work on desktops, should chrome use a Windows service for that? Would it use its own servers? Apple would probably do it themselves. And how about Linux? Would a cross platform option ever exist? Maybe 1password?

Re: Passkeys: The beginning of the end of the password

#357

Post by mk89 » Wed, May 03, 2023, 9:38 PM UTC

jimmar wrote: post #294

The paragraph in the section, "What are passkeys?" tells me that they: are new, are easier, let me use biometrics, and are resistant to attacks. But, it doesn't tell me what passkeys actually are. Compare passkeys to traditional authentication factors. What's a password? A secret word or phrase that only you know. What are biometrics? Parts of your body that can help uniquely identify you, like your fingerprint or re…

You need to click on the link that is in the post: https://blog.google/technology/safety-security/one-step-clos...

> Instead, your phone will store a FIDO credential called a passkey which is used to unlock your online account. The passkey makes signing in far more secure, as it’s based on public key cryptography and is only shown to your online account when you unlock your phone.

It looks like a token stored on your phone that will be used instead of your password to authenticate.

Apple did something similar: https://developer.apple.com/passkeys/ that is automatically sync-ed in iCloud Keychain, so on every apple device you own, you can use it.

More information here: https://fidoalliance.org/passkeys/ and this explains finally how it works FIDO in general: https://fidoalliance.org/how-fido-works/

So yeah it's sort of a token, but technically, it's a private key that is used to sign the challenge at login time.

EDIT: from what I understand, while this prevents from "stealing passwords" etc., there is still the risk that someone steals your private key (copy/paste your phone or ... well, steals stuff from iCloud Keychain) and tries to use that to sign the challenge. Did I get it right? Or what mechanism is in place to prevent it? It looks like this time we use biometrics first (to unlock the screen) and passkey later?

Re: Passkeys: The beginning of the end of the password

#358

Post by lxgr » Wed, May 03, 2023, 9:42 PM UTC

awaythrow98765 wrote: post #276

Ajedi32 wrote: post #111

Earlier quoted context omitted.

> Now one could allow backups of a passkey That's literally part of what makes a passkey a passkey (v.s. just a WebAuthn credential), so that's a given. > as insecure as a password No. Passkeys can't be phished, passwords can. Passkeys can't be cracked after a data breach. Passwords can. Passkeys can't be set to something easily guessable. Passwords can. Passkeys can't be written on a post-it note and taped to your m…

> No. Passkeys can't be phished, passwords can. Passkeys can't be cracked after a data breach. Passwords can. Passkeys can't be set to something easily guessable. Passwords can. Passkeys can't be written on a post-it note and taped to your monitor. Passwords can. Passkeys can't be reused across multiple sites. Passwords can. Passkeys don't need to be cracked after a data breach of your backup provider, they are just…

> Passkeys are accessible permanently on some devices unencrypted or decryptable in the filesystem, if part of e.g. a backup. Whereas passwords are usually only accessible temporarily.

I think you're mixing up server-side and client/sync-backend-side compromises here.

For the former (i.e. a compromise of hashed passwords and their corresponding salts), you'll need to rotate all passwords since the hashes can be brute-forced. For passkeys, all an attacker gets when compromising a service's database are public keys that can't be brute-forced and key handles that don't give an attacker anything without the corresponding authenticators.

For the latter, the situation is exactly the same for passkeys and passwords in a password manager, i.e. both are as secure as their on-device storage and encryption in transit and rest at a synchronization provider (if any).

Re: Passkeys: The beginning of the end of the password

#359

Post by dcow » Wed, May 03, 2023, 9:42 PM UTC

NikolaNovak wrote: post #345

Ignorant question: Are Passkeys, at some level of abstraction, permanently replacing "something you know" (password) with "something you have"? If I am in some kind of calamity (dropped my phone, got robbed, etc), and I come to a friendly person's house, it sounds to me like I simply would not be able to login to potentially critical services, no matter how much I know , because I don't have anything (the device that…

I like to explain it like this:

If you use a password manager today, then you're already essentially using something you have, because you need to be in possession of your login database to retrieve passwords, and nobody can remember that in their head.

Passkeys is a formalization of the idea that you should be using a password manager where all the passwords are random uncrackable 32 character strings, and if we add this constraint then we can crazy secure things like employ asymmetric crypto to prevent phishing and MITM attacks, so woO!.

You are right to be concerned about the whole device thing though. Apple addresses this by requiring that you use/enable iCloud keychain in order to use passkeys. The generalized solution to this is allowing 3rd parties to be your passkey provider, so that you can choose how your passkeys are stored (cloud synced vs device bound) and e.g. whether you want an implementation where you can unlock them with one strong something you know, something you are, something your have, or any combination thereof, the only limit being the features/options the different 3rd party products will offer, depending on their target market, etc.

Re: Passkeys: The beginning of the end of the password

#360

Post by lll-o-lll » Wed, May 03, 2023, 9:46 PM UTC

NikolaNovak wrote: post #345

Ignorant question: Are Passkeys, at some level of abstraction, permanently replacing "something you know" (password) with "something you have"? If I am in some kind of calamity (dropped my phone, got robbed, etc), and I come to a friendly person's house, it sounds to me like I simply would not be able to login to potentially critical services, no matter how much I know , because I don't have anything (the device that…

Yes, it replaces something you know with something you have and something you are. The hypothetical scenario you describe is a downside.

As to your other concerns. Registering a passkey from each of your devices should be a trivial exercise. If you want to play with this now, GitHub has good integration (you can keep your password, the passkeys you register are just alternative ways to access).

For your family, your concerns are not warranted because the “cloud backup” is part of the integration. With Apple, as an example, the passkeys are tied to your keychain, and changing devices/disaster recovery is relatively trivial. The passkeys are also accessible from all your Apple devices, so you don’t have to create separate ones.