Thought Leadership

The Journey to and then Beyond Passwordless Authentication

Written By
Jim Clark
Published On
Apr 14, 2020

In many ways, Beyond Identity has been decades in the making, from back when we started Netscape, the first browser through which most people accessed the Internet and the first platform through which most people entered a password. But the realization that it was now possible to effectively eliminate passwords as a method of authentication didn’t come until much more recently, when we were developing a more secure way for residents to access home automation software.

Netscape and the Invention of SSL (1995—1999)

When we built Netscape, we knew it was essential to enable secure transactions online. Our chief scientist, Taher Elgamal, along with Paul Kocher, developed a solution to this problem with the Secure Sockets Layer protocol, or SSL (the lock in the browser). This protocol is still in use today, in the form of TLS, for the same purpose – a testament to its design.

The same principles of asymmetric cryptography and certificates used to secure online transactions for the past 25 years are now at the heart of Beyond Identity’s passwordless identity management solution. But at the time, it would not have been possible to implement it to identify individuals. This is because the protocol relies on signed certificates issued by trusted certificate authorities (CAs), which were not scalable to the magnitude necessary to issue certificates to hundreds of millions or billions of individual users. Other issues at the time included device memory limitations and how individual consumers would securely store the crucial private key. Businesses used expensive hardware security modules (HSMs) for this purpose, but this was not an option for consumers. These issues would not be solved until the introduction and proliferation of secure enclaves in computing devices – the Trusted Platform Module (TPM) chips that were introduced in the past decade on a range of devices where the secure storage of biometric data was needed.

Securing Passwords (1999—2019)

We would not revisit the password issue until long after Netscape. In the meantime, various password workarounds emerged from a few schools of thought:

  1. Passwords need to be more complex.
    Proponents of this idea attempted to bolster security through enforcing strong password rules such as character minimums and requirements for special characters and numbers in passwords. These “high-entropy” passwords were harder for adversaries to guess and a bit more difficult for machines to crack. But the result was that nearly everyone used the same hard-to-guess password or a slight variation – so if hackers stole one password, it was likely usable across multiple sites.
     
  2. Passwords need to be stored somewhere more secure.
    Password databases are a virtual goldmine for hackers. To protect them, organizations realized that security measures need to be implemented to defend where the passwords are stored. Encryption and firewalls have become standard for all databases storing credentials, yet leaks still happen. Often. As long as the passwords are stored in password “safes” or back-end databases, bad actors will find a way to access them.
     
  3. Passwords are not secure enough on their own.
    This gave rise to multi-factor authentication – various second-factor codes often sent over insecure channels such as email, text, SMS, or apps.

None of these “solutions” fixed the root of the problem – which is that there is a shared secret stored somewhere on a server. The solution, of course, is to eliminate the password entirely.

Home Automation (2018—2019)

It wasn’t until 2018 that we decided to finally tackle the password issue, and it was almost inadvertent. While working on home automation technology, we needed to find a secure method for homeowners to verify their identity and then control their smart home devices. It was immediately clear that a password would not be secure enough given their entire home was at stake. A leak could lead to a stranger controlling the customer’s physical environment, affecting the lives of family members in a very immediate and frightening way. Oh, and who wants to enter a password to turn on the lights or change the thermostat? Exactly – nobody.

Verifying identity became a fundamental goal, and our engineers began working on a solution. One of our engineers, Nelson Melo, came up with the idea of using the same digital certificates and asymmetric cryptography from SSL/TLS to verify individual identities and secure logins. The idea was to essentially extend the chain of trust that existed between websites by one link to include the user who is accessing the server.

Barriers that stood in the way before – limited memory and the lack of a secure place on devices to store private keys – had both been solved. With the advent of strong biometric authentication for endpoints and an enclave to protect biometric data and private keys, we had what we needed. Finally, it seemed that we could enable users to access applications as securely as the TLS transactions that flowed between two websites, or between your browser and your favorite e-commerce site. It was at that point that we decided this technology was bigger than the home automation purpose for which it was originally designed. This solved a much bigger problem.

Beyond Identity (2019—Today)

Seeing the potential in eliminating passwords for the masses, we formed Beyond Identity. We built an elegantly simple solution using the same fundamental technology that has been trusted to secure trillions of dollars' worth of transactions on the web for 25 years (SSL/TLS, certificates). Our foundational idea: use “self-signed certificates” to replace the insecure password. With our solution, each end user becomes their own certificate authority, eliminating passwords and extending a chain of trust all the way to the user and their endpoint device.

But we didn’t stop there. As we continued to develop the technology further, we found many ways our certificate-based approach could be used to provide significant value beyond passwordless authentication. For example, with our solution, we can collect, digitally sign, and send information about the security posture of the endpoint device, at the time of the request, along with the signed certificate proving the end user's identity. This enables organizations to have unprecedented insight, and to make risk-based authentication and authorization decisions – leveraging the identity, the risk of the accessing device, and the value of the service being accessed. Unlike off-device authenticators, we produce a full-risk picture at each login for better auth decisions, and produce an immutable record for audit/compliance and security operations center (SOC) teams.

We also developed integrations with SSO providers, starting with Okta, Ping, and ForgeRock, so that companies could rapidly turn on our cloud-native solution for their workforces and leverage existing IAM infrastructure investments. It takes only a few configuration changes in the SSO to make us a “delegate identity provider” and enable secure, passwordless authentication and adaptive risk-based authorization. The solution also supports customer-facing applications with API/SDK-based integration.

Finally, the issues with building Internet security around passwords can be put to bed, and we can enter a new, much-overdue era of fundamentally secure authentication.

Get started with Device360 today

The Journey to and then Beyond Passwordless Authentication

Download

In many ways, Beyond Identity has been decades in the making, from back when we started Netscape, the first browser through which most people accessed the Internet and the first platform through which most people entered a password. But the realization that it was now possible to effectively eliminate passwords as a method of authentication didn’t come until much more recently, when we were developing a more secure way for residents to access home automation software.

Netscape and the Invention of SSL (1995—1999)

When we built Netscape, we knew it was essential to enable secure transactions online. Our chief scientist, Taher Elgamal, along with Paul Kocher, developed a solution to this problem with the Secure Sockets Layer protocol, or SSL (the lock in the browser). This protocol is still in use today, in the form of TLS, for the same purpose – a testament to its design.

The same principles of asymmetric cryptography and certificates used to secure online transactions for the past 25 years are now at the heart of Beyond Identity’s passwordless identity management solution. But at the time, it would not have been possible to implement it to identify individuals. This is because the protocol relies on signed certificates issued by trusted certificate authorities (CAs), which were not scalable to the magnitude necessary to issue certificates to hundreds of millions or billions of individual users. Other issues at the time included device memory limitations and how individual consumers would securely store the crucial private key. Businesses used expensive hardware security modules (HSMs) for this purpose, but this was not an option for consumers. These issues would not be solved until the introduction and proliferation of secure enclaves in computing devices – the Trusted Platform Module (TPM) chips that were introduced in the past decade on a range of devices where the secure storage of biometric data was needed.

Securing Passwords (1999—2019)

We would not revisit the password issue until long after Netscape. In the meantime, various password workarounds emerged from a few schools of thought:

  1. Passwords need to be more complex.
    Proponents of this idea attempted to bolster security through enforcing strong password rules such as character minimums and requirements for special characters and numbers in passwords. These “high-entropy” passwords were harder for adversaries to guess and a bit more difficult for machines to crack. But the result was that nearly everyone used the same hard-to-guess password or a slight variation – so if hackers stole one password, it was likely usable across multiple sites.
     
  2. Passwords need to be stored somewhere more secure.
    Password databases are a virtual goldmine for hackers. To protect them, organizations realized that security measures need to be implemented to defend where the passwords are stored. Encryption and firewalls have become standard for all databases storing credentials, yet leaks still happen. Often. As long as the passwords are stored in password “safes” or back-end databases, bad actors will find a way to access them.
     
  3. Passwords are not secure enough on their own.
    This gave rise to multi-factor authentication – various second-factor codes often sent over insecure channels such as email, text, SMS, or apps.

None of these “solutions” fixed the root of the problem – which is that there is a shared secret stored somewhere on a server. The solution, of course, is to eliminate the password entirely.

Home Automation (2018—2019)

It wasn’t until 2018 that we decided to finally tackle the password issue, and it was almost inadvertent. While working on home automation technology, we needed to find a secure method for homeowners to verify their identity and then control their smart home devices. It was immediately clear that a password would not be secure enough given their entire home was at stake. A leak could lead to a stranger controlling the customer’s physical environment, affecting the lives of family members in a very immediate and frightening way. Oh, and who wants to enter a password to turn on the lights or change the thermostat? Exactly – nobody.

Verifying identity became a fundamental goal, and our engineers began working on a solution. One of our engineers, Nelson Melo, came up with the idea of using the same digital certificates and asymmetric cryptography from SSL/TLS to verify individual identities and secure logins. The idea was to essentially extend the chain of trust that existed between websites by one link to include the user who is accessing the server.

Barriers that stood in the way before – limited memory and the lack of a secure place on devices to store private keys – had both been solved. With the advent of strong biometric authentication for endpoints and an enclave to protect biometric data and private keys, we had what we needed. Finally, it seemed that we could enable users to access applications as securely as the TLS transactions that flowed between two websites, or between your browser and your favorite e-commerce site. It was at that point that we decided this technology was bigger than the home automation purpose for which it was originally designed. This solved a much bigger problem.

Beyond Identity (2019—Today)

Seeing the potential in eliminating passwords for the masses, we formed Beyond Identity. We built an elegantly simple solution using the same fundamental technology that has been trusted to secure trillions of dollars' worth of transactions on the web for 25 years (SSL/TLS, certificates). Our foundational idea: use “self-signed certificates” to replace the insecure password. With our solution, each end user becomes their own certificate authority, eliminating passwords and extending a chain of trust all the way to the user and their endpoint device.

But we didn’t stop there. As we continued to develop the technology further, we found many ways our certificate-based approach could be used to provide significant value beyond passwordless authentication. For example, with our solution, we can collect, digitally sign, and send information about the security posture of the endpoint device, at the time of the request, along with the signed certificate proving the end user's identity. This enables organizations to have unprecedented insight, and to make risk-based authentication and authorization decisions – leveraging the identity, the risk of the accessing device, and the value of the service being accessed. Unlike off-device authenticators, we produce a full-risk picture at each login for better auth decisions, and produce an immutable record for audit/compliance and security operations center (SOC) teams.

We also developed integrations with SSO providers, starting with Okta, Ping, and ForgeRock, so that companies could rapidly turn on our cloud-native solution for their workforces and leverage existing IAM infrastructure investments. It takes only a few configuration changes in the SSO to make us a “delegate identity provider” and enable secure, passwordless authentication and adaptive risk-based authorization. The solution also supports customer-facing applications with API/SDK-based integration.

Finally, the issues with building Internet security around passwords can be put to bed, and we can enter a new, much-overdue era of fundamentally secure authentication.

The Journey to and then Beyond Passwordless Authentication

Phishing resistance in security solutions has become a necessity. Learn the differences between the solutions and what you need to be phishing resistant.

In many ways, Beyond Identity has been decades in the making, from back when we started Netscape, the first browser through which most people accessed the Internet and the first platform through which most people entered a password. But the realization that it was now possible to effectively eliminate passwords as a method of authentication didn’t come until much more recently, when we were developing a more secure way for residents to access home automation software.

Netscape and the Invention of SSL (1995—1999)

When we built Netscape, we knew it was essential to enable secure transactions online. Our chief scientist, Taher Elgamal, along with Paul Kocher, developed a solution to this problem with the Secure Sockets Layer protocol, or SSL (the lock in the browser). This protocol is still in use today, in the form of TLS, for the same purpose – a testament to its design.

The same principles of asymmetric cryptography and certificates used to secure online transactions for the past 25 years are now at the heart of Beyond Identity’s passwordless identity management solution. But at the time, it would not have been possible to implement it to identify individuals. This is because the protocol relies on signed certificates issued by trusted certificate authorities (CAs), which were not scalable to the magnitude necessary to issue certificates to hundreds of millions or billions of individual users. Other issues at the time included device memory limitations and how individual consumers would securely store the crucial private key. Businesses used expensive hardware security modules (HSMs) for this purpose, but this was not an option for consumers. These issues would not be solved until the introduction and proliferation of secure enclaves in computing devices – the Trusted Platform Module (TPM) chips that were introduced in the past decade on a range of devices where the secure storage of biometric data was needed.

Securing Passwords (1999—2019)

We would not revisit the password issue until long after Netscape. In the meantime, various password workarounds emerged from a few schools of thought:

  1. Passwords need to be more complex.
    Proponents of this idea attempted to bolster security through enforcing strong password rules such as character minimums and requirements for special characters and numbers in passwords. These “high-entropy” passwords were harder for adversaries to guess and a bit more difficult for machines to crack. But the result was that nearly everyone used the same hard-to-guess password or a slight variation – so if hackers stole one password, it was likely usable across multiple sites.
     
  2. Passwords need to be stored somewhere more secure.
    Password databases are a virtual goldmine for hackers. To protect them, organizations realized that security measures need to be implemented to defend where the passwords are stored. Encryption and firewalls have become standard for all databases storing credentials, yet leaks still happen. Often. As long as the passwords are stored in password “safes” or back-end databases, bad actors will find a way to access them.
     
  3. Passwords are not secure enough on their own.
    This gave rise to multi-factor authentication – various second-factor codes often sent over insecure channels such as email, text, SMS, or apps.

None of these “solutions” fixed the root of the problem – which is that there is a shared secret stored somewhere on a server. The solution, of course, is to eliminate the password entirely.

Home Automation (2018—2019)

It wasn’t until 2018 that we decided to finally tackle the password issue, and it was almost inadvertent. While working on home automation technology, we needed to find a secure method for homeowners to verify their identity and then control their smart home devices. It was immediately clear that a password would not be secure enough given their entire home was at stake. A leak could lead to a stranger controlling the customer’s physical environment, affecting the lives of family members in a very immediate and frightening way. Oh, and who wants to enter a password to turn on the lights or change the thermostat? Exactly – nobody.

Verifying identity became a fundamental goal, and our engineers began working on a solution. One of our engineers, Nelson Melo, came up with the idea of using the same digital certificates and asymmetric cryptography from SSL/TLS to verify individual identities and secure logins. The idea was to essentially extend the chain of trust that existed between websites by one link to include the user who is accessing the server.

Barriers that stood in the way before – limited memory and the lack of a secure place on devices to store private keys – had both been solved. With the advent of strong biometric authentication for endpoints and an enclave to protect biometric data and private keys, we had what we needed. Finally, it seemed that we could enable users to access applications as securely as the TLS transactions that flowed between two websites, or between your browser and your favorite e-commerce site. It was at that point that we decided this technology was bigger than the home automation purpose for which it was originally designed. This solved a much bigger problem.

Beyond Identity (2019—Today)

Seeing the potential in eliminating passwords for the masses, we formed Beyond Identity. We built an elegantly simple solution using the same fundamental technology that has been trusted to secure trillions of dollars' worth of transactions on the web for 25 years (SSL/TLS, certificates). Our foundational idea: use “self-signed certificates” to replace the insecure password. With our solution, each end user becomes their own certificate authority, eliminating passwords and extending a chain of trust all the way to the user and their endpoint device.

But we didn’t stop there. As we continued to develop the technology further, we found many ways our certificate-based approach could be used to provide significant value beyond passwordless authentication. For example, with our solution, we can collect, digitally sign, and send information about the security posture of the endpoint device, at the time of the request, along with the signed certificate proving the end user's identity. This enables organizations to have unprecedented insight, and to make risk-based authentication and authorization decisions – leveraging the identity, the risk of the accessing device, and the value of the service being accessed. Unlike off-device authenticators, we produce a full-risk picture at each login for better auth decisions, and produce an immutable record for audit/compliance and security operations center (SOC) teams.

We also developed integrations with SSO providers, starting with Okta, Ping, and ForgeRock, so that companies could rapidly turn on our cloud-native solution for their workforces and leverage existing IAM infrastructure investments. It takes only a few configuration changes in the SSO to make us a “delegate identity provider” and enable secure, passwordless authentication and adaptive risk-based authorization. The solution also supports customer-facing applications with API/SDK-based integration.

Finally, the issues with building Internet security around passwords can be put to bed, and we can enter a new, much-overdue era of fundamentally secure authentication.

The Journey to and then Beyond Passwordless Authentication

Phishing resistance in security solutions has become a necessity. Learn the differences between the solutions and what you need to be phishing resistant.

In many ways, Beyond Identity has been decades in the making, from back when we started Netscape, the first browser through which most people accessed the Internet and the first platform through which most people entered a password. But the realization that it was now possible to effectively eliminate passwords as a method of authentication didn’t come until much more recently, when we were developing a more secure way for residents to access home automation software.

Netscape and the Invention of SSL (1995—1999)

When we built Netscape, we knew it was essential to enable secure transactions online. Our chief scientist, Taher Elgamal, along with Paul Kocher, developed a solution to this problem with the Secure Sockets Layer protocol, or SSL (the lock in the browser). This protocol is still in use today, in the form of TLS, for the same purpose – a testament to its design.

The same principles of asymmetric cryptography and certificates used to secure online transactions for the past 25 years are now at the heart of Beyond Identity’s passwordless identity management solution. But at the time, it would not have been possible to implement it to identify individuals. This is because the protocol relies on signed certificates issued by trusted certificate authorities (CAs), which were not scalable to the magnitude necessary to issue certificates to hundreds of millions or billions of individual users. Other issues at the time included device memory limitations and how individual consumers would securely store the crucial private key. Businesses used expensive hardware security modules (HSMs) for this purpose, but this was not an option for consumers. These issues would not be solved until the introduction and proliferation of secure enclaves in computing devices – the Trusted Platform Module (TPM) chips that were introduced in the past decade on a range of devices where the secure storage of biometric data was needed.

Securing Passwords (1999—2019)

We would not revisit the password issue until long after Netscape. In the meantime, various password workarounds emerged from a few schools of thought:

  1. Passwords need to be more complex.
    Proponents of this idea attempted to bolster security through enforcing strong password rules such as character minimums and requirements for special characters and numbers in passwords. These “high-entropy” passwords were harder for adversaries to guess and a bit more difficult for machines to crack. But the result was that nearly everyone used the same hard-to-guess password or a slight variation – so if hackers stole one password, it was likely usable across multiple sites.
     
  2. Passwords need to be stored somewhere more secure.
    Password databases are a virtual goldmine for hackers. To protect them, organizations realized that security measures need to be implemented to defend where the passwords are stored. Encryption and firewalls have become standard for all databases storing credentials, yet leaks still happen. Often. As long as the passwords are stored in password “safes” or back-end databases, bad actors will find a way to access them.
     
  3. Passwords are not secure enough on their own.
    This gave rise to multi-factor authentication – various second-factor codes often sent over insecure channels such as email, text, SMS, or apps.

None of these “solutions” fixed the root of the problem – which is that there is a shared secret stored somewhere on a server. The solution, of course, is to eliminate the password entirely.

Home Automation (2018—2019)

It wasn’t until 2018 that we decided to finally tackle the password issue, and it was almost inadvertent. While working on home automation technology, we needed to find a secure method for homeowners to verify their identity and then control their smart home devices. It was immediately clear that a password would not be secure enough given their entire home was at stake. A leak could lead to a stranger controlling the customer’s physical environment, affecting the lives of family members in a very immediate and frightening way. Oh, and who wants to enter a password to turn on the lights or change the thermostat? Exactly – nobody.

Verifying identity became a fundamental goal, and our engineers began working on a solution. One of our engineers, Nelson Melo, came up with the idea of using the same digital certificates and asymmetric cryptography from SSL/TLS to verify individual identities and secure logins. The idea was to essentially extend the chain of trust that existed between websites by one link to include the user who is accessing the server.

Barriers that stood in the way before – limited memory and the lack of a secure place on devices to store private keys – had both been solved. With the advent of strong biometric authentication for endpoints and an enclave to protect biometric data and private keys, we had what we needed. Finally, it seemed that we could enable users to access applications as securely as the TLS transactions that flowed between two websites, or between your browser and your favorite e-commerce site. It was at that point that we decided this technology was bigger than the home automation purpose for which it was originally designed. This solved a much bigger problem.

Beyond Identity (2019—Today)

Seeing the potential in eliminating passwords for the masses, we formed Beyond Identity. We built an elegantly simple solution using the same fundamental technology that has been trusted to secure trillions of dollars' worth of transactions on the web for 25 years (SSL/TLS, certificates). Our foundational idea: use “self-signed certificates” to replace the insecure password. With our solution, each end user becomes their own certificate authority, eliminating passwords and extending a chain of trust all the way to the user and their endpoint device.

But we didn’t stop there. As we continued to develop the technology further, we found many ways our certificate-based approach could be used to provide significant value beyond passwordless authentication. For example, with our solution, we can collect, digitally sign, and send information about the security posture of the endpoint device, at the time of the request, along with the signed certificate proving the end user's identity. This enables organizations to have unprecedented insight, and to make risk-based authentication and authorization decisions – leveraging the identity, the risk of the accessing device, and the value of the service being accessed. Unlike off-device authenticators, we produce a full-risk picture at each login for better auth decisions, and produce an immutable record for audit/compliance and security operations center (SOC) teams.

We also developed integrations with SSO providers, starting with Okta, Ping, and ForgeRock, so that companies could rapidly turn on our cloud-native solution for their workforces and leverage existing IAM infrastructure investments. It takes only a few configuration changes in the SSO to make us a “delegate identity provider” and enable secure, passwordless authentication and adaptive risk-based authorization. The solution also supports customer-facing applications with API/SDK-based integration.

Finally, the issues with building Internet security around passwords can be put to bed, and we can enter a new, much-overdue era of fundamentally secure authentication.

Book

The Journey to and then Beyond Passwordless Authentication

Phishing resistance in security solutions has become a necessity. Learn the differences between the solutions and what you need to be phishing resistant.

Download the book

By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.