No this isn’t about MFA. The PIN doesn’t replace the password. The password is still there. You just don’t make it up anymore and would struggle to remember what it actually is now. The password in this solution is an encryption key that gets stored in your “secure alcove”. The PIN or passcode or biometric grants access to that key. That key is what then plays a role in replacing password entry used to access systems. The PIN is useless to anyone without your secure alcove. Your secure alcove might be a hardware chip (TPM/T2), firmware inside a CPU, or it might be data stored in your iCloud account. it’s just an evolution of fairly old technology (asymmetric encryption, e.g. SSL certs) that’s been used in Enterprises for years. They are so complex, they are probably never going to be guessed in a dictionary attack. They can’t be stolen from most systems you use because the systems don’t have a copy of the key which is private to whichever secure alcove you put it in. It’s the same kind of thing that protects data in transit with secure websites.
It's not immediately clear how falling back to a device PIN would be more secure than a properly configured password, however.
The reason it’s more secure is because there are multiple factors - the device (something you have), and the PIN (something you know) or biometric - face, or finger (something you are). No one is suggesting we replace passwords with PINs, they’re saying a device AND a PIN - or some other factor.
Is that true? I don't know if you will need to enroll a new device before using it. But either way, this is a dramatic improvement over passwords because it will prevent them from ever being transmitted. Like Kerberos or public-key SSH, no secret will be transmitted between server and client.
Among other benefits, that means that there will be no compromises due to shared/reused passwords exposed by compromised sites. We see customers fall victim to that every week.
Everything else is tying your activities directly to you.
Don’t like where this is going.
Yeah... no. I sympathize with your distaste for tracking, but you need to learn a lot more if you're going to have a meaningful opinion. As I said above, device PINs (while they have issues as well) are NOT the same as passwords.
For all intents and purposes, PIN works just like a password. You enter a code and you gain access. The process and result are the same, whether a credit card, a device, a login, etc.
To eliminate. passwords, they must invade your privacy in order to authenticate. Already, the two-factor authentication, while more secure, is a way to track your logins to you using your phone number - or email address, which is also increasingly being verified by your phone number.
Unless you are an engineer or mathematician with a strong
background in crypto and knowledge of current security technologies
(which you are obviously not) you should avoid making sweeping
statements about topics you don't understand.
PIN means different things in different contexts. The PIN referred to here is, in the local context of your device only, a password, but in the context of a web site or other internet-connected resource, it is absolutely NOT a password, and it works NOTHING AT ALL like a password. The result may be partially the same, but the process is entirely different.
I have already explained one of the most important ways this setup differs from using passwords (no secret known to server or transmitted at all). If you don't understand that concept completely, that's the first thing you should read about. Maybe start with https://en.wikipedia.org/wiki/Public-key_cryptography and see where that takes you. Check out Zero-Knowledge Proofs too.
Your contention that 2FA is for tracking is also wrong. It *can* be true for the most common 2FA schemes in wide use today (as you noted) but it's not an inherent property of 2FA. Better options exist, and FIDO2 will make those options more accessible.
No this isn’t about MFA. The PIN doesn’t replace the password. The password is still there. You just don’t make it up anymore and would struggle to remember what it actually is now. The password in this solution is an encryption key that gets stored in your “secure alcove”. The PIN or passcode or biometric grants access to that key. That key is what then plays a role in replacing password entry used to access systems. The PIN is useless to anyone without your secure alcove. Your secure alcove might be a hardware chip (TPM/T2), firmware inside a CPU, or it might be data stored in your iCloud account. it’s just an evolution of fairly old technology (asymmetric encryption, e.g. SSL certs) that’s been used in Enterprises for years. They are so complex, they are probably never going to be guessed in a dictionary attack. They can’t be stolen from most systems you use because the systems don’t have a copy of the key which is private to whichever secure alcove you put it in. It’s the same kind of thing that protects data in transit with secure websites.
That's... not a terrible attempt, though you meant to say "secure enclave", which is Apple's term for hardware features of the Ax, T1/2, and M1 only (along with future iterations), not anything in icloud.
You are missing some important details. For example, credentials for accessing individual entities (web sites, say) don't live in the enclave. Instead a master key resides there, which is used to decrypt actual keys living outside the enclave. (And I'm leaving out stuff too, like recovery keys, etc.)
It's not immediately clear how falling back to a device PIN would be more secure than a properly configured password, however.
The reason it’s more secure is because there are multiple factors - the device (something you have), and the PIN (something you know) or biometric - face, or finger (something you are). No one is suggesting we replace passwords with PINs, they’re saying a device AND a PIN - or some other factor.
Is that true? I don't know if you will need to enroll a new device before using it. But either way, this is a dramatic improvement over passwords because it will prevent them from ever being transmitted. Like Kerberos or public-key SSH, no secret will be transmitted between server and client.
Among other benefits, that means that there will be no compromises due to shared/reused passwords exposed by compromised sites. We see customers fall victim to that every week.
Everything else is tying your activities directly to you.
Don’t like where this is going.
Yeah... no. I sympathize with your distaste for tracking, but you need to learn a lot more if you're going to have a meaningful opinion. As I said above, device PINs (while they have issues as well) are NOT the same as passwords.
For all intents and purposes, PIN works just like a password. You enter a code and you gain access. The process and result are the same, whether a credit card, a device, a login, etc.
To eliminate. passwords, they must invade your privacy in order to authenticate. Already, the two-factor authentication, while more secure, is a way to track your logins to you using your phone number - or email address, which is also increasingly being verified by your phone number.
It's not necessary to invade privacy, it depends on the implementation. Once a service is using key authentication, it can be verified client-side. SSH key authentication doesn't pass through a 3rd party server-side process. The 3rd party authentication services use servers so they are cross-platform. Business authentication is used across email, web, calendars, device login, VPN and multiple devices so it's just easier to use a cloud service. But the cloud part can be used to sync keys to the devices and do authentication locally.
The authentication process only has to work like this: - user signs up to a service and it creates a public/private key pair, private is stored locally (behind biometrics), service stores public key - the private keys can be encrypted to a cloud service for syncing multiple devices - when a login request is made, the server sends a message encrypted with the public key that can only be decrypted by the private one and the device can send the result back, no 3rd party involved and no password
This eliminates password database hacking and phishing attacks.
When another device needs to use the service, it can sync the encrypted private key from the cloud or it can request another key to be setup, possibly by email. Every device can get its own key.
There will be open source implementations of key authentication that work locally and used by companies directly.
The main thing that holds back new services is getting a simple implementation that works everywhere, in every development language. Standard passwords will probably always exist locally because even with biometrics on devices, the password is used to enable biometrics but they shouldn't be used online any more. There should be a push to phase out passwords online by having a compliance standard that checks whether a service stores passwords or uses keys.
If you have one key to rule them all and it is compromised you are done.
And yet, that's now it is. Because there is literally no other reasonable way to do things. For regular individuals, at least.
There are edge cases that are potentially plausible, like keeping multiple master keys, or sharing key parts with other parties for extremely sensitive keys. They have little relevance to most people.
The fact is, in 2022 (or 2016 for that matter) operating without a password manager is crazy and irresponsible. Using something like FIDO is an upgrade from either having a pwmgr or not, not that you're likely to be able to ditch your pwmgr any time soon.
Comments
The authentication process only has to work like this:
- user signs up to a service and it creates a public/private key pair, private is stored locally (behind biometrics), service stores public key
- the private keys can be encrypted to a cloud service for syncing multiple devices
- when a login request is made, the server sends a message encrypted with the public key that can only be decrypted by the private one and the device can send the result back, no 3rd party involved and no password
This eliminates password database hacking and phishing attacks.
When another device needs to use the service, it can sync the encrypted private key from the cloud or it can request another key to be setup, possibly by email. Every device can get its own key.
There will be open source implementations of key authentication that work locally and used by companies directly.
The main thing that holds back new services is getting a simple implementation that works everywhere, in every development language. Standard passwords will probably always exist locally because even with biometrics on devices, the password is used to enable biometrics but they shouldn't be used online any more. There should be a push to phase out passwords online by having a compliance standard that checks whether a service stores passwords or uses keys.
If you have one key to rule them all and it is compromised you are done.