7 ms·

How is this more secure? They say "with a fingerprint, a face scan or a screen lock PIN", but basically all phones let you fall back to PINs if you dont want to

How is this more secure? They say "with a fingerprint, a face scan or a screen lock PIN", but basically all phones let you fall back to PINs if you dont want to do face or fingerprints. Pins are flat out not secure - typically just 4 digits. Yeah its probably better than 80% of people having "password123", but it seems strictly worse than a password + password manager? Or at least just having proper 2FA.

ferminaut 3y ago
it's more secure on the back end. The DB will store a hashed unique pass phrase that isnt shared with anyone else. You enter a pin, the web server sees a public key that only your side has the private key to.
surteen 3y ago
Because it's a PIN protecting a certificate stored on the device. Even if you know the PIN but don't have access to the device, you can't use it.
- toomuchtodo 3y ago
  And the pin is the same functionality as activating a hardware authenticator like a Yubikey.
  - stouset 3y ago
    … which have historically yielded credentials at any touch, without a need for a PIN, fingerprint, or face scan.
VoodooJuJu 3y ago
>with a fingerprint, a face scan or a screen lock PIN I agree - not secure. And just a daily reminder that biometrics are usernames, they are not passwords. You can change a password, a lock, a key, you cannot change biometrics, and thus they should not be used for guarding sensitive info. The only use-case for biometrics is deanonymization, sold to you under the auspices of security, primarily used for corporate surveillance.
- wepple 3y ago
  > The only use-case for biometrics is deanonymization, sold to you under the auspices of security, primarily used for corporate surveillance. Please provide evidence that biometric data has ever been extracted from a major platform (IE Apple/enclave). Absence of evidence != evidence of absence, I know, but you’re selling it as the only use case so surely you have proof.
  - johndough 3y ago
    > Please provide evidence that biometric data has ever been extracted from a major platform Why extract it from a platform when it can be extracted easily from the person? Imagine your password was written on every surface you touched (fingerprint) or is prominently displayed on your social media accounts (face).
    - fireflash38 3y ago
      And then extrapolate to how those biometric factors could be changed outside of your control -- car accident requires facial reconstruction. Or a fire burns your fingerprints.
      - jeroenhd 3y ago
        I cut myself on a cheese slicer once and had to use PIN for unlocking my phone for a week or two while the cut healed. Annoying, but that's what the fallback PIN was for I guess.
        dwaite 3y ago
        Actually, the PIN isn't a fallback - the biometric is just a more convenient option once the PIN is "cached". The biometric doesn't exist until you enter your PIN on restart, which is what unlocks the filesystem (including the biometric profile). You'll also see that you can change your biometric with just your PIN, but you cannot use your biometric to change your PIN.
    - 3y ago
neilalexander 3y ago
> How is this more secure? The three factors of authentication are: 1. Something you have 2. Something you know 3. Something you are Passkeys are typically 1+2 or 1+3 — you'd need to have physical access to the device either way.
wepple 3y ago
Password + password manager can be trivially phished. PIN can’t, because even if you somehow phished a user you can’t use it. I don’t know what “proper 2FA” means but the gold standard today is U2F, and it has failed to be mass adopted due to requirement to purchase and maintain another device.
- aidenn0 3y ago
  FWIW, my password manager has prevented me from being phished because it wouldn't auto-fill the password.
segmondy 3y ago
This is more secure, passwords can't be stolen from the site. Sure, let's go with the assumption that your phone can be stolen. It would be only your phone. If a site has 100 million users, an attacker could steal 100 million passwords. With this approach, the attacker would have to steal 100 million phones. No matter what password manager you use, with a password length of 100 characters. The entire password list (encrypted) can be stolen.
- aidenn0 3y ago
  This keeps you from ever sending the password to the site (similar to e.g. SRP). Most sites already don't store the password. If you have a sufficiently strong password (i.e. very long, randomly generated, stored in a password manager), it is likely not computationally easier to recover the password from a hash than it is from a public-key. The only improvement here is that you don't have to trust that the site is following best-practices for storing passwords, as you never send them the password. [edit] It also prevents phishing attacks for those using some form of entering a password other than autofill from the password-manager.
bkettle 3y ago
A PIN entered onto a physical device like a smartphone can be rate limited (see iPhone progressively increasing PIN timeouts). If you try to rate limit password entry to an online service, you make it trivially easy for an attacker to lock out a real user. Thus, even short PINs can provide strong security since the attacker gets, e.g., at most 10 tries to guess it out of 100k possibilities for a 6-digit PIN.
petedoyle 3y ago
This has been bothering me, a lot. Google talks [1] about how Passkey replication is e2e encrypted between devices, but AFAICT they're just using a pin + key derivation. A six digit pin is like 20 bits of entropy before a KDF. [2] Has anyone seen any docs that might help characterize how much entropy the keys have for e2e encryption (Android/iOS)? I must be missing something, because I can't see how Google would call something e2e encrypted if the keys only have like 30-35 bits of "effective" entropy after a KDF. But that seems like it's the case?? [1] "From the user's point of view, this means that when using a passkey for the first time on the new device, they will be asked for an existing device's screen lock in order to restore the end-to-end encryption keys" [1] https://security.googleblog.com/2022/10/SecurityofPasskeysintheGooglePasswordManager.html https://security.googleblog.com/2022/10/SecurityofPasskeysin... [2] https://www.omnicalculator.com/other/password-entropy?c=SGD&v=trigger:1,lett_low:0,lett_upp:0,special:0,custom:32,custom1pool:0,custom1length:0,custom2pool:0,custom2length:0,custom3pool:0,custom3length:0,num:6 https://www.omnicalculator.com/other/password-entropy?c=SGD&...
- sebk 3y ago
  Talking about Apple here because it's what I'm more familiar with, and their security whitepapers are more widely available. The PIN and key derivation wraps the actual encryption key that's stored locally in the device or secure enclave, not the actual secrets that are stored in the provider's cloud. The actual wrapping keys are random 256 bit AES-GCM keys. This approach works because the secure enclave provides measures against bruteforcing and tampering. There is some controversy that I can't find an explanation for in any whitepaper, specifically here: https://support.apple.com/en-us/HT202303 https://support.apple.com/en-us/HT202303 where it reads "(...) this data remains secure even in the case of a data breach in the cloud. If you lose access to your account, only you can recover this data, using your device passcode or password, recovery contact, or recovery key." because that implies off-device use of the PIN, so those measures are lost. There's no further explanation that I could find about that. Some previous discussion about that particular point here: https://news.ycombinator.com/item?id=33897793&p=2#33900540 https://news.ycombinator.com/item?id=33897793&p=2#33900540
  - 3y ago
NoMoreNicksLeft 3y ago
You're forgetting Oyler's Law of Passwords: Humanity will be forced to try each wrong approach to passwords, one at a time and trial-and-error, for all eternity. Slightly off-topic: If a website will not let me register and complains that my password is too long, they're still storing that in the underlying database as a properly-salted (modern algo) hash, right?
deleted 3y ago
[deleted]
bhk 3y ago
Being tied to a device, it defeats the most serious threats of phishing and weak passwords, for which attacks can be mounted on a global scale. 2FA via SMS is still vulnerable. 2FA with an app like Google Authenticator or VIPAccess is more secure because it is tied to a device.
- ilyt 3y ago
  The devices are far from being security bastion.
- jjav 3y ago
  > more secure because it is tied to a device Tied to a phone (as opposed to some security-specific device like a Yubikey) is a terrible idea. It ties your authentication to something that is often lost or damages, but more importantly, something that is controlled by a third party (apple or google) and requires an expensive monthly subscription to yet another third party (your cellphone company). TOTP is not tied to a device which is why it's a beautiful solution. You can store it where you wish under the controls you wish and back it up as you wish. You are fully in control, dependent on nobody.
dwaite 3y ago
> it seems strictly worse than a password + password manager Your password manager is likely the exact same thing. The underlying implementation of this is typically a system or third party password manager which added a public key-based credential type for sites. For an Android phone, this is Google Password Manager by default. For iOS, it is iCloud Keychain. Third parties like Dashlane and 1Password have indicated support for passkeys. I would have thought your interpretation would be that this was strictly better. Even if the credential database leaks for a site, the attacker can't do anything with it - all they have is a public key, specific to that one site. > Or at least just having proper 2FA. If I use my android phone to log into a website, I have done 2FA. I have physical possession of my phone, and have used a gesture, PIN or biometric to confirm who I am. The difference is in the password case, the website has no idea that I did that - all they saw is the password. With a passkey, it is possible that a site would recognize that I did a stronger, multi-factor authentication. This may have varying strengths as a physical factor - say, provisioned database of credentials onto a device using MFA vs a FIPS-certified security key fob, but I would still argue it is "proper" 2FA.

ferminaut 3y ago

it's more secure on the back end. The DB will store a hashed unique pass phrase that isnt shared with anyone else. You enter a pin, the web server sees a public key that only your side has the private key to.

surteen 3y ago

Because it's a PIN protecting a certificate stored on the device. Even if you know the PIN but don't have access to the device, you can't use it.

toomuchtodo 3y ago
And the pin is the same functionality as activating a hardware authenticator like a Yubikey.
- stouset 3y ago
  … which have historically yielded credentials at any touch, without a need for a PIN, fingerprint, or face scan.

VoodooJuJu 3y ago

>with a fingerprint, a face scan or a screen lock PIN I agree - not secure. And just a daily reminder that biometrics are usernames, they are not passwords. You can change a password, a lock, a key, you cannot change biometrics, and thus they should not be used for guarding sensitive info. The only use-case for biometrics is deanonymization, sold to you under the auspices of security, primarily used for corporate surveillance.

wepple 3y ago
> The only use-case for biometrics is deanonymization, sold to you under the auspices of security, primarily used for corporate surveillance. Please provide evidence that biometric data has ever been extracted from a major platform (IE Apple/enclave). Absence of evidence != evidence of absence, I know, but you’re selling it as the only use case so surely you have proof.
- johndough 3y ago
  > Please provide evidence that biometric data has ever been extracted from a major platform Why extract it from a platform when it can be extracted easily from the person? Imagine your password was written on every surface you touched (fingerprint) or is prominently displayed on your social media accounts (face).
  - fireflash38 3y ago
    And then extrapolate to how those biometric factors could be changed outside of your control -- car accident requires facial reconstruction. Or a fire burns your fingerprints.
    - jeroenhd 3y ago
      I cut myself on a cheese slicer once and had to use PIN for unlocking my phone for a week or two while the cut healed. Annoying, but that's what the fallback PIN was for I guess.
      - dwaite 3y ago
        Actually, the PIN isn't a fallback - the biometric is just a more convenient option once the PIN is "cached". The biometric doesn't exist until you enter your PIN on restart, which is what unlocks the filesystem (including the biometric profile). You'll also see that you can change your biometric with just your PIN, but you cannot use your biometric to change your PIN.
  - 3y ago

neilalexander 3y ago

> How is this more secure? The three factors of authentication are: 1. Something you have 2. Something you know 3. Something you are Passkeys are typically 1+2 or 1+3 — you'd need to have physical access to the device either way.

wepple 3y ago

Password + password manager can be trivially phished. PIN can’t, because even if you somehow phished a user you can’t use it. I don’t know what “proper 2FA” means but the gold standard today is U2F, and it has failed to be mass adopted due to requirement to purchase and maintain another device.

aidenn0 3y ago
FWIW, my password manager has prevented me from being phished because it wouldn't auto-fill the password.

segmondy 3y ago

This is more secure, passwords can't be stolen from the site. Sure, let's go with the assumption that your phone can be stolen. It would be only your phone. If a site has 100 million users, an attacker could steal 100 million passwords. With this approach, the attacker would have to steal 100 million phones. No matter what password manager you use, with a password length of 100 characters. The entire password list (encrypted) can be stolen.

aidenn0 3y ago
This keeps you from ever sending the password to the site (similar to e.g. SRP). Most sites already don't store the password. If you have a sufficiently strong password (i.e. very long, randomly generated, stored in a password manager), it is likely not computationally easier to recover the password from a hash than it is from a public-key. The only improvement here is that you don't have to trust that the site is following best-practices for storing passwords, as you never send them the password. [edit] It also prevents phishing attacks for those using some form of entering a password other than autofill from the password-manager.

bkettle 3y ago

A PIN entered onto a physical device like a smartphone can be rate limited (see iPhone progressively increasing PIN timeouts). If you try to rate limit password entry to an online service, you make it trivially easy for an attacker to lock out a real user. Thus, even short PINs can provide strong security since the attacker gets, e.g., at most 10 tries to guess it out of 100k possibilities for a 6-digit PIN.

petedoyle 3y ago

This has been bothering me, a lot. Google talks [1] about how Passkey replication is e2e encrypted between devices, but AFAICT they're just using a pin + key derivation. A six digit pin is like 20 bits of entropy before a KDF. [2] Has anyone seen any docs that might help characterize how much entropy the keys have for e2e encryption (Android/iOS)? I must be missing something, because I can't see how Google would call something e2e encrypted if the keys only have like 30-35 bits of "effective" entropy after a KDF. But that seems like it's the case?? [1] "From the user's point of view, this means that when using a passkey for the first time on the new device, they will be asked for an existing device's screen lock in order to restore the end-to-end encryption keys" [1] https://security.googleblog.com/2022/10/SecurityofPasskeysintheGooglePasswordManager.html https://security.googleblog.com/2022/10/SecurityofPasskeysin... [2] https://www.omnicalculator.com/other/password-entropy?c=SGD&v=trigger:1,lett_low:0,lett_upp:0,special:0,custom:32,custom1pool:0,custom1length:0,custom2pool:0,custom2length:0,custom3pool:0,custom3length:0,num:6 https://www.omnicalculator.com/other/password-entropy?c=SGD&...

sebk 3y ago
Talking about Apple here because it's what I'm more familiar with, and their security whitepapers are more widely available. The PIN and key derivation wraps the actual encryption key that's stored locally in the device or secure enclave, not the actual secrets that are stored in the provider's cloud. The actual wrapping keys are random 256 bit AES-GCM keys. This approach works because the secure enclave provides measures against bruteforcing and tampering. There is some controversy that I can't find an explanation for in any whitepaper, specifically here: https://support.apple.com/en-us/HT202303 https://support.apple.com/en-us/HT202303 where it reads "(...) this data remains secure even in the case of a data breach in the cloud. If you lose access to your account, only you can recover this data, using your device passcode or password, recovery contact, or recovery key." because that implies off-device use of the PIN, so those measures are lost. There's no further explanation that I could find about that. Some previous discussion about that particular point here: https://news.ycombinator.com/item?id=33897793&p=2#33900540 https://news.ycombinator.com/item?id=33897793&p=2#33900540
- 3y ago

NoMoreNicksLeft 3y ago

You're forgetting Oyler's Law of Passwords: Humanity will be forced to try each wrong approach to passwords, one at a time and trial-and-error, for all eternity. Slightly off-topic: If a website will not let me register and complains that my password is too long, they're still storing that in the underlying database as a properly-salted (modern algo) hash, right?

deleted 3y ago

[deleted]

bhk 3y ago

Being tied to a device, it defeats the most serious threats of phishing and weak passwords, for which attacks can be mounted on a global scale. 2FA via SMS is still vulnerable. 2FA with an app like Google Authenticator or VIPAccess is more secure because it is tied to a device.

ilyt 3y ago
The devices are far from being security bastion.
jjav 3y ago
> more secure because it is tied to a device Tied to a phone (as opposed to some security-specific device like a Yubikey) is a terrible idea. It ties your authentication to something that is often lost or damages, but more importantly, something that is controlled by a third party (apple or google) and requires an expensive monthly subscription to yet another third party (your cellphone company). TOTP is not tied to a device which is why it's a beautiful solution. You can store it where you wish under the controls you wish and back it up as you wish. You are fully in control, dependent on nobody.

dwaite 3y ago

> it seems strictly worse than a password + password manager Your password manager is likely the exact same thing. The underlying implementation of this is typically a system or third party password manager which added a public key-based credential type for sites. For an Android phone, this is Google Password Manager by default. For iOS, it is iCloud Keychain. Third parties like Dashlane and 1Password have indicated support for passkeys. I would have thought your interpretation would be that this was strictly better. Even if the credential database leaks for a site, the attacker can't do anything with it - all they have is a public key, specific to that one site. > Or at least just having proper 2FA. If I use my android phone to log into a website, I have done 2FA. I have physical possession of my phone, and have used a gesture, PIN or biometric to confirm who I am. The difference is in the password case, the website has no idea that I did that - all they saw is the password. With a passkey, it is possible that a site would recognize that I did a stronger, multi-factor authentication. This may have varying strengths as a physical factor - say, provisioned database of credentials onto a device using MFA vs a FIPS-certified security key fob, but I would still argue it is "proper" 2FA.