How Passwordless Access Works That Will Revolutionize Security: Stop Account Theft or Phishing

In a few years, “Password Day” will no longer exist, and we’ll finally be able to rest easy seeing that all those “1234567890” or “foo” still used today as passwords by most people no longer exist.

The password in its text form is dying: Too weak but above all too insecure, because it can be “copied” easily. Everyone who has fallen into this phishing trap knows this well: with fake emails, founders are redirected to “flirting” sites that look like the original sites but are not, and on these sites they are asked to enter the password and then save it and use it on other sites. Most people don’t use unique passwords, they always use the same password.

The arrival of two-factor authentication solutions has reduced risks today, but even these solutions are not entirely without drawbacks: not all sites provide two-factor access.

In recent weeks, Google, Apple and Microsoft, the companies that run today’s “consumer” web world, have reached an agreement on the interoperability of passwordless systems on the basis of a common and unified standard.

After introducing this concept at the previous edition of WWDC this year, Apple presented its implementation of this solution in the Standard Edition.

Those for Microsoft and Google will also arrive soon, however, there is currently no distribution date. Instead, we know for sure that Apple Passkeys will arrive with iOS 16 and macOS 13 Ventura, unleashing a global revolution that will radically change the Internet: No one will have to remember passwords anymore and most web related threats will be gone. miracle? No, the simple development of a web key to a technology that has always been used. Here’s how it works.

Passwordless authentication as seen by the user

A common standard, created by the FIDO Alliance and the result of more than ten years of work: It took a long time to make secure password-free access to sites and applications a common and interoperable standard. Each manufacturer will have its own specific application, associated with its own security systems, but there will be no restrictions of any kind: with an Android phone you can access a site via Safari on a Mac or a Microsoft account, and with an iPhone you can access Google without my number where there is any password .

We’ve provided a general demonstration of how it all works at WWDC 2022: just go to a site, enter your username and click the button to be authenticated. The same goes for apps or services that require registration: just type in your username and hit register to create the account without necessarily choosing a password.

Behind the scenes: why it works, how it works and why it’s safe

A passwordless authentication scheme is something that systems engineers in the Linux world (and not only) have been using for years: no matter how complex a password is, it can always be copied. If something in the password place is difficult to copy, or impossible, the system cannot be accessed. Today, in accessing servers via SSH, the Secure Shell is used, which is a master system consisting of a public key and a private key.

The private key is a very long string of characters that cannot be memorized and is the element that actually represents the access key to the system. This key is encrypted and does not leave the computer on which it was created, unless specifically chosen by the user.

The public key is another key, which is generated starting from the private key but as its name suggests, it can be distributed. Public key access is not a security concern at all, although the public key is also unique.

This pair of keys, without delving into the mathematical operations, has its own uniqueness: it is possible to encrypt a message using the public key and this message can be decrypted only with the private key that generated this specific public key.

Anyone with a public key can send an encrypted message Only those who own the corresponding private key that generated this public key can read it.

This work is today the basis of thousands of systems in the IT sector, and is also the basis of passwordless authentication that in this case is managed by the WebAuthn API that is now supported by all modern browsers.

Open the original file

When entering the authentication details without a password, the registration mechanism is as follows:

  1. A person opens a website or application and wants to register
  2. Press the “Register” button and enter your username and password
  3. The device from which it is launched, which can be a smartphone or a computer, generates a pair of keys, one public and one private, taking as elements in the domain of the site it is trying to access and the username
  4. The public key generated by the device is sent to the server that manages the authentication of the application or site which in turn stores it in the database, just as it has always done with passwords. We remind you that the public key is not a secret and can be distributed, so even if the site is broken and someone steals the public keys, they can’t do anything dangerous.
  5. The server returns the generated account message by encrypting it with the public key and the registering device receives it, decrypts it with the private key and stores the account in it.

Here’s a key point, and it’s somewhat differentiating between different apps for manufacturers: We know how it’s going to work for Apple because it was explained during WWDC, but we don’t know what Google or Microsoft will do.

Apple, in turn, will encrypt the public and private key pair using the Secure Enclave and will share it with different devices that adopt the same account via iCloud Keychain: this means that even if the user is signed into the iPhone, they will be able to. to reach it. Using a Mac or using Safari. Google should do something similar, being able to take advantage of smartphones while Microsoft will be able to rely on Windows Hello with cameras and Finderprint, but it will be a bit difficult to use this solution to reach other platforms. While QR can be scanned using a smartphone, the same process is less practical with a laptop.

The authentication flow is similar:

  1. Someone opens a website or app and wants to access it
  2. The client sends a message to the server saying “I am xxxxx” and I want to access this site.
  3. The server in turn verifies that user xxxxxx is in the system, takes his public key and encrypts a reply message which also includes a valid access token for a brief moment.
  4. The client must decrypt the message: it asks the user to access the secure area of ​​the device (FaceID, fingerprint, or other method) and searches from the domain for the key pair it has stored. If the public key matches, use the private key to see the message the server sent it.
  5. The client in turn returns the token that unlocks access to the server.

Here you can understand why phishing techniques do not work: a spinning server created to steal passwords will never have the public keys, and above all will not have the domain of the real server. The system crashes immediately.

Interoperability, the magic word

As Alex Simmons, who handles accounts at Microsoft, rightly pointed out, a system without a password works only if there is perfect interoperability between different systems. If the different solutions don’t talk to each other, users will continue to use the classic password, putting their security at risk.

This means that a person who opens a site from their work computer should be able to access it without a password even if the private key for that account is stored on the iPad or iCloud account. To solve the problem, a system has been designed that allows you to insert a third element within the chain: how the above authentication sequence is modified to manage interoperability.

  1. Someone opens a website or app and wants to access it
  2. Chrome on Windows sends a message to the server saying “I’m xxxxx” and I want to access this site.
  3. The server in turn verifies that user xxxxxx is in the system, takes his public key and encrypts a reply message which also includes a valid access token for a brief moment.
  4. The client must decrypt the message but Webauthn, the library, realizes that there is no key copy on this machine that would allow it to read the sent message. Then it asks the user if they want to authenticate with another device and displays a QR code.
  5. By framing the QR with the iPhone, it is he who manages the authentication and tells the server that it can unblock access because there is a correspondence.

Such a system will eliminate the password change and “forgot my password” buttons. The only thing the user can do is delete the copy of the private keys on the device, at which point they will no longer be able to access the site.

The system provides management of certain cases: What happens if you accidentally delete the copy of the keys that allow access to the social account? The application and site managers will provide a system that restarts: after entering your email or phone number, You will receive a link where the key pair can be recreated by saving it back to the device.

Access keys can also be shared to individual sites: Apple has demonstrated key-sharing via AirDrop, but similar to what is done by the Google Authenticator app via QR Code, it will be possible to export, copy and copy access keys on other devices obviously voluntarily.

When all this comes

A passwordless authentication system has been a reality for years, but now it’s finally time to bring it into the consumer world as well. This was not done before due to the need for three conditions: full software support, today there are devices capable of protecting keys with advanced biometric systems, today there is but above all the possibility of having full interoperability, and the April agreement between Apple, Google and Microsoft led to a push Clear.

Manufacturers will be very quick to do everything: Apple has announced this for iOS and macOS Ventura, but we think Google and Microsoft can get in at the same time, too. Android 13 can integrate, while Windows already integrates part of what is needed except for the interoperability part.

The only real barrier is the support from those who develop the apps: the developers, whether they are app or website developers, They will still have to make changes to incorporate it. As it often happens, it will be too simple on the iOS side because Apple has made sure, at least for apps, that adding Passkeys will only require minimal variation in code with the help of Xcode. Things are also moving on the web side: Devise, the authentication library we have on has a passwordless module which, however, will require some versions to gain interoperability. So it is likely that the solution will be integrated, at the web level, starting in 2023 on the largest platforms only to reach other platforms the following year.

Both Google and Microsoft should be quick to release what developers need to adapt the apps, and then you’ll have to see how many people will do it and in what time frame.

Leave a Comment