DEV Community: PassageNick

ELI5: How does a TPM work?

PassageNick — Mon, 12 Dec 2022 18:25:40 +0000

We all know that passwords leave a lot to be desired. They are a hassle for everyone. Fortunately, passwordless authentication is coming. Removing passwords from the authentication equation will be a welcome sight for users and software developers.

You may have heard about passkeys, a standards-based solution that leverages biometrics and other technologies to make passwords obsolete. Most of the time, passkeys will leverage some type of biometrics to authenticate you to a given website or mobile application.

_ You can read all about the standards used for passwordless authentication, how it works, and why it is a superior solution to passwords in other posts here on our blog._

The great part of the whole solution is that secret information never leaves your device. Your biometrics information and passkeys are stored safely and securely on your phone or computer, unable to be accidentally shared or otherwise revealed to bad actors. Even if you lose your phone and a sophisticated hacker or other hostile entity gets a hold of it, they will not be able to pry that information from the bowels of your phone.

How is that possible? Because that secret information is stored in a chip called a Trusted Platform Module (TPM).

What is a TPM?

A TPM is a very special chip, currently included in almost all new computers and phones, that is specifically designed to store your secrets, most notably passkeys and other private encryption artifacts. It is specifically designed to make it impossible to give up those secrets to anyone other than you.

TPMs use encryption, hashing, and other security measures to store and protect your secrets. The TPM chip itself is also specific to your computer or phone and is protected by an additional layer of hardware security. This layer of protection prevents attackers from accessing the sensitive information that is stored inside the TPM.

The TPM works in concert with the device’s operating system (Windows, iOS, OS X, Android, etc.) to do all kinds of cryptography-related things. However, what we are concerned with here is its ability to manage and protect private encryption keys—otherwise known as passkeys. When you ask for a passkey to be created, the TPM generates it, stores the secret, private key safely away without ever exposing it to anyone, and hands out the public key to the website or mobile application to use.

I have had a Dell laptop for several years running Windows 10, but when it came time to upgrade to Windows 11, it wouldn’t install. Why? Because Windows 11 requires the presence of a TPM, and my older laptop didn’t have it. Windows 11 needs the TPM to support Windows Hello and provide a much higher level of security for access to your computer.

How Does a TPM Keep Secrets?

The primary way TPMs work their magic is by isolating secrets away from everything and everyone, even the operating system. No entity ever sees the secrets stored by the TPM. This means that when a TPM is used to validate a signed data chunk, it can do so without revealing any secrets. The TPM will perform the necessary calculations to verify the signature, and then the results are sent back to the requesting application. Again, no secrets are ever revealed in any way, shape, or form.

I keep using qualifiers like “basically” and “considered” in front of “impossible” because no one can predict the future, and no specification should ever be considered perfect. While many smart people have worked for many years to make sure TPMs are impregnable, one can never be 100% sure that there isn’t a bug, nor can one be sure that some computing breakthrough makes all that hard work moot.

Second, TPMs are literally soldered directly to a specific motherboard and given a unique, unalterable identifier, thus ensuring that each one — along with the chip’s given configuration — is uniquely identifiable and every action produced by a specific TPM is traceable to that TPM. Thus, you can know what specific device has provided credentials, and you can be sure that said device hasn’t been compromised. This ensures the integrity of the entire process.

Third, the TPM is designed to defend against brute-force attacks. A brute force attack is a process of simply trying, over and over, every possible key in the hopes that one of them will succeed. A TPM will shut itself down and accept no more queries if too many requests are submitted in a given period. But don’t worry; there is an option for recovery after a specific time has passed.

On top of all that is the fact that the TPM standards and specifications have been around — and thus battle-tested — for over twenty years. Everything about a TPM, including the source code, is publicly available. As noted above, that doesn’t promise impregnability, but twenty years is a long time in the technology world.

Bottom Line

The bottom line is that a TPM is well-designed, well-tested, and well-proven. For all intents and purposes, it is impregnable, doing the job of protecting the secrets entrusted to it. Given the inevitability of a passwordless future, TPMs will certainly be an integral part of all devices requiring authentication services for years to come. As a result, users can rest assured that the passwordless authentication process is safe, secure, and hassle-free.

Seven Misunderstandings About Passkeys

PassageNick — Wed, 16 Nov 2022 20:33:56 +0000

Rightfully Resistant to Change

Password management is a thing that many people feel very strongly about. Many folks don’t like passwords and hope for a better way. But other folks have a solid system built around their password security and are rightfully very skeptical of systems that claim to improve on what they have. They have good reasons for liking their current setup and are hesitant to change what works for them. That’s wise.

Passkeys Enter the Picture

Thus many people are skeptical of passkeys, the new protocol from the FIDO Alliance that purports to drastically improve the safety, security, and user experience of logging in to websites and mobile applications.

Passkeys have been officially announced by Apple and put into developer builds for Chrome and Android by Google. Microsoft is preparing its version as well. The reason that these three companies are critical to adoption is that they represent the vast majority of devices, computers, browsers, and operating systems. If these three all agree on something, then there is probably something to it.

I Read the Comments

Since both Apple and Google have announced support for passkeys, there have been many articles describing passkeys, how they work, and how the tech giants will support them. Many have been informative, but a few have been, well, confusing.

It is said that you should never read the comments, but I have been. And to say there is some confusion, trepidation, and misconceptions about passkeys is a bit of an understatement.

I’ve written about why we need passkeys, how they work, and why they are a better solution than passwords. To continue that theme, I’m going to write about a few of the misconceptions I see out there about passkeys.

“Will there still be a password somewhere?”

People seem to think that there will still be a password backing things up somewhere in the system. Some say this because they hope it is true as a recovery method, but others are concerned that it is true, recognizing that it wouldn’t really improve the situation.

The WebAuthn protocol does not — and should not — require the use of passwords anywhere in the system. It should not because requiring a password would defeat the purpose and cause the system to continue to be “phishable” and thus no more secure than what we have today. There is no password backup because it isn’t necessary.

Now it may be that as websites and applications migrate to passwordless and passkey-based solutions, they may maintain password authentication. Still, it isn’t required, and it is expected that passwords will eventually go away completely.

“Is Bluetooth required to log in?”

Some articles mistakenly implied that a Bluetooth connection was required to complete a passkey login.

This is not true. While Bluetooth plays a role in securing the transfer of passkey-based authentication between the major tech company’s eco-systems, it is not required for the simple process of logging in. Your phone doesn’t have to be in Bluetooth range to log in on your computer. Your phone does have to be in range if you want to transfer passkeys to or from another device — and this is a security feature.

“I can register my device once, and it will log me in everywhere.”

Some folks have concluded that you can register your phone or computer with Apple, Microsoft, or Google, and it will work everywhere. This led to questions like “What happens when I go to a website that asks me for my password?” It would be nice if that would work that way. However, each website has to implement passwordless technology on its own, and you, as a user, will have to register an account with each site or mobile application just as you do today.

“If a bad guy gets my phone, will they have access to all of my accounts?”

Actually, if a bad actor gets your phone, it is pretty much impossible for them to get much of anything. First, they won’t have your biometric information and thus won’t even be able to unlock your phone. Second, all the secret passkey information is stored in a Trusted Platform Module, specifically designed to hold your passkey secrets in such a way that it is virtually impenetrable. (Okay, maybe the NSA or similar organizations might be able to get into it, but I can’t say for sure…)

So you can rest assured that your phone will not cough up your login information to even the most sophisticated hacker.

*“If I don’t have my phone, am I out of luck?”

People are concerned that if they don’t have their phone while at a friend’s house or a library computer, they won’t be able to log in.

The passkey protocol doesn’t address this situation, but most vendors will — and should — provide a second secure option for logging in. Usually, this is a “magic link” — a one-use, expiring link that logs you in — sent to your email address. Only you have access to your email, so the link will securely log you into any computer worldwide.

“If I lose my phone, am I out of luck?”

This is partially true. Sort of.

One of the benefits of passkeys is that they are promised to be shared across devices within the given ecosystem of each of the big tech companies. This means that if you lose your phone, your passkeys are securely stored (via end-to-end encryption) in the cloud. They can be restored when you get a new phone.

However, you can choose not to share your passkeys into the cloud, and if you do that and you only have one device, then yes, the passkeys will be lost, and you’ll have to re-register with every site you visit.

The normal use case here is that users decide to share their passkeys across their devices via the cloud (in a securely encrypted manner), and thus replacing a phone is not an issue.

“What if my biometrics are compromised?”

Some folks seem concerned that they can’t change their biometrics if they were to be compromised. (You can change your password, but you can’t change your fingerprint…)

These folks are right — you can’t change your biometrics. However, it is not clear what it means exactly for them to be compromised. Your biometrics data never leaves your phone. It is converted to a mathematical hash value and encrypted with a key stored in the TPM. Only your phone with your fingerprint can get the key and verify your fingerprint. Your biometric data can’t be stored and decrypted anywhere except on your phone.

Almost Too Good to be True?

I’m not going to say that passkeys are too good to be true, but I will say that they are a huge step forward in authentication security. If the threat surface of passwords is a vast lake, then the threat surface of passkeys is a small puddle after a short downpour. While no system should be considered impregnable, no one seems to be able to conceive of a way passkeys can be compromised short of quantum computing breaking current encryption schemes.

There are a few corner cases where they might not be acceptable to some people. For instance, biometrics are not protected by America’s Fourth Amendment, but a password is. Another thing to consider is that while Google/Apple/Microsoft won’t ever be able to read your credentials, there is concern that these companies will be able to track the places you register an account. This is why third-party companies like 1Password are looking at ways to provide the passkey storage and transfer service.

Bottom Line: For the overwhelming majority, passkeys are safe, convenient, and work great. While I understand the hesitancy to change things up, this is an instance when change is a win for everyone.

Why Passkeys are Better than Passwords

PassageNick — Mon, 17 Oct 2022 20:03:58 +0000

Maybe you’ve had the feeling — or maybe you’ve imagined it. The feeling of your stomach sinking to the bottom of your belly. That panic you feel the very second you realize that you just entered your login credentials into a fake website. Maybe you realized it right away. Or maybe you realized because you went back the next day and couldn’t log in. Maybe you realized it because your bank account has been cleaned out. However you realized — or imagined — it, it’s not a feeling you ever want to have.

But imagine not having to worry about that ever again.

That’s what passkeys and passwordless authentication can bring you.

Why Passkeys are Better

Every day we grow closer to a passwordless world. We here at Passage are doing what we can to make that happen for everyone. We all carry devices with us that can be used to easily declare who we are, normally via a fingerprint or face scan. All new laptops have fingerprint readers. Passkeys leverage these new technologies to drastically increase the security of your accounts. Apple has introduced passkeys into their eco-system, with Microsoft and Google releasing their versions very soon.

I’ve written about why we must move beyond passwords and how the whole passkey system works. In this post, I will discuss why passkeys are a vastly better solution than passwords. There are many reasons why passkeys are a superior solution, but it all boils down to two things.

Passkeys Share no Secret Information

This is the biggest reason passkeys are much more secure than passwords. With Passkeys, passwords are simply no longer a threat vector.

Passwords account for north of 80% of all security breaches. Passkeys mitigate this threat down to almost nothing. You can’t reuse your passkeys. You don’t have to remember them. They are generated and stored for you, so you don’t have to worry about creating and storing them yourself. You can’t be lured into giving them up because they are unique to a specific website and thus can’t be shared with a phishing website.

Sensitive data associated with each passkey never leaves your device. The information is stored on your phone on a special chip (a Trusted Platform Module) that even the NSA might not be able to crack. If you register with a website using a passwordless solution like Passage, that site gets nothing but a public key, which is useless for cracking open your account. While Apple lets you share your account with others via AirDrop, you couldn’t even share the actual private key with a phishing site if you wanted to.

Passkeys are a Much Better User Experience

Registering for an account on a website can be a hassle. Often you have to think up a password meeting various criteria designed to make it hard to guess. Frequently, users have to context switch away from your site to get a six-digit number from their phone or an email. Over 30% of all online shopping carts are abandoned because of the bother of registering for an account or because users don’t remember their passwords. Password Managers can help the situation, but they can be complicated to use for many. The whole experience needs improving.

Multi-factor authentication (MFA) can improve the security of a password-based system but does so at the cost of decreased user experience. MFA requires the user to switch contexts, usually by going to another application to grab a six-digit number. I know I’ve often fumbled to find my phone to get that one-time password.

Instead, passkey registration requires a biometric system validation — as simple as a fingerprint touch or a glance at a camera — and one-time device approval. After that, logging in is as simple as that biometric validation. Instead of typing complicated passwords and grabbing one-time password codes or checking emails, your users can log in in seconds or less.

Passkeys actually use MFA, requiring you to supply something you have (your device) and something you are (for example, your face or your fingerprint).

Passkeys are only getting better. Ultimately, you will be able to log in without even entering your password or phone number. Instead, the login input box will just know that your device has a Passkey for the given domain and will auto-prompt you.

Let’s Do This

I remember that great feeling when my bank’s mobile application allowed me to log in with my fingerprint instead of typing my complicated (and ultimately not secure, no matter how complex it was) password. It was a freeing moment for sure. You want that for your users when they come to your website or log in to your mobile application, don’t you? Heck, you want that for yourself every time.

In the end, passkeys appear virtually unexploitable and vastly more convenient. Why not give it a try right now?

Building an Angular App with Passwordless Authentication

PassageNick — Fri, 07 Oct 2022 20:02:49 +0000

We here at Passage are all about creating a passwordless world that makes our online lives a whole lot more secure. Angular developers can join that world and quickly integrate Passage’s solution into their applications. I’ll show you how.

Our solution uses the WebAuthn protocol to leverage the biometrics solutions built into their devices (e.g., FaceID, TouchID, Windows Hello, or Android’s fingerprint technology). We’ll create a simple Angular application that only allows authenticated viewers to see a dashboard. Unauthorized viewers will be out of luck.

If you are highly motivated, you can go through the whole demo with me, or if you want to cut to the quick, you can clone our example app from GitHub and jump to the header entitled “Add Passwordless Authentication with Passage.” Either way, you’ll soon see how easy this is for everyone, both for you developer types and your users.

Note: I’ll be assuming that you are pretty familiar with Angular, the Angular CLI, and how things generally work in Angular. If not, Angular.io is a great place to start.

Setup

To create an Angular application, you can run the following at the command line at a command prompt in the directory where you want your application to go:

ng new passage-app

Note: Create the app with the angular router and with regular
CSS Styling

That will create a nice, basic application for you in a subdirectory called passage-app.

So, to include Passage in your application, you are going to want to install it into your application workspace via npm:

npm i @passageidentity/passage-node

That will install our Passage web components, which will enable us to include them later.

Main App Setup

Before we get really rolling, let’s do a little styling. Open up the project’s main CSS file, styles.css, and add the following code to it:

body {
    font-family: sans-serif;
    background-color: #E5E5E5;
    margin: 0;
}

Next, open up the CSS file for the main component — app.component.css — and add this CSS code to it:

.mainContainer {
    background: white;
    box-shadow: 0px 4px 4px rgba(0, 0, 0, 0.25);
    border-radius: 20px;
    width: 600px;
    min-height: 310px;
    margin: 30px auto;
}
.footer {
    text-align: center;
    font-size: 18px;
}

That will get us started with the styling. We’ll be doing more of that here in a few steps.

The Main Component

Next, we’ll get the main component for our application set up. We’ll insert some HTML, set up the routes, and add some more CSS.

For the app-routing.module.ts file, make it look like this:

import { NgModule } from '@angular/core';
import { RouterModule, Routes } from '@angular/router';
import { HomeComponent } from 'src/app/home/home.component';
import { DashboardComponent } from 'src/app/dashboard/dashboard.component';

const routes: Routes = [
    {path: '', component: HomeComponent},
    {path: 'dashboard', component: DashboardComponent}
  ];

  @NgModule({
    imports: [RouterModule.forRoot(routes)],
    exports: [RouterModule]
  })
export class AppRoutingModule { }

This code will set two routes, one for the Home component and one for the Dashboard component.

Add the following to the app.component.css file:

.mainContainer {
    background: white;
    box-shadow: 0px 4px 4px rgba(0, 0, 0, 0.25);
    border-radius: 20px;
    width: 310px;
    min-height: 310px;
    margin: 30px auto;
}
.footer {
    text-align: center;
    font-size: 18px;
}

and for the app.component.html file, replace the default HTML (there’s a bunch of it) with this:

<banner></banner>
<div class="mainContainer">
    <router-outlet></router-outlet>
</div>
<div class="footer">
    Learn more with our <a href="https://docs.passage.id">Documentation</a> and <a href="https://github.com/passageidentity">Github</a>.      
</div>

That code will display the banner on top, a footer at the bottom, and will place the content chosen by the router in the middle.

Some Components

Next up, we’ll create three components. Run these three calls to the Angular CLI at the command line:

ng generate component home
ng generate component dashboard
ng generate component banner

Let’s set all this up now.

The Home Component

In the home.component.html file, add this HTML:

<passage-auth [appId]="appId"></passage-auth>

<passage-auth [appId]="appId"></passage-auth>

In the home.component.ts file, add the following code:

import { Component, OnInit } from '@angular/core';
import { environment } from 'src/environments/environment';

@Component({
  selector: 'app-home',
  templateUrl: './home.component.html',
  styleUrls: ['./home.component.css']
})
export class HomeComponent implements OnInit {

  public appId: string = environment.passageAppId;

  constructor() { }

  ngOnInit(): void {
  }
}

And in the home.component.css file:

.mainContainer {
    display: flex;
  }

  .spacer{
    flex-grow: 1;
  }

  .earlyAccessContainer{
    min-width: 325px;
    width: 35%;
    color: white;
    background-color: #27417E;
    border-top-left-radius: 30px;
    border-bottom-left-radius: 30px;
    display: flex;
    flex-direction: column;
  }

  .title {
    font-weight: 700;
    font-size: 48px;
    margin-top: 65px;
    padding-left: 45px;
    padding-right: 65px;
  }

  .bodyText{
    padding-left: 45px;
    padding-right: 45px;
    padding-bottom: 35px;
    font-size: 24px;
  }

  .authContainer{
    width: 65%;
    display: flex;
    flex-direction: column;
    justify-content: center;
    padding-left: 20px;
    padding-right: 20px;
  }

  /* for shorter 13" dekstop screens */
  @media screen and (max-height: 845px) {
    .title {
      font-size: 40px;
    }
    .bodyText{
      font-size: 20px;
    }
  }

  /* steps to mobile rules begin here */
  @media screen and (max-width: 870px) {

    .mainContainer{
      flex-direction: column;
      width: 100%;
    }

    .earlyAccessContainer{
      min-width: unset;
      width: 100%;
      min-height: 30%;
      border-top-left-radius: 30px;
      border-top-right-radius: 30px;
      border-bottom-left-radius: 0px;
      border-bottom-right-radius: 0px;
    }

    .title {
      font-size: 32px;
      margin-top: 30px;
      padding-left: 30px;
      padding-right: 30px;
    }
    .bodyText{
      font-size: 20px;
      padding-left: 30px;
      padding-right: 30px;
      padding-bottom: 15px;
    }

    .authContainer{
      width: 100%;
      height: 100%;
      flex-grow: 1;
      padding-top: 20px;
      padding-left: 0px;
      padding-right: 0px;
    }
  }

  @media screen and (max-width: 670px) {
    .title {
      font-size: 24px;
    }
    .bodyText{
      font-size: 16px;
    }
  }

  @media screen and (max-width: 460px) {
    .earlyAccessContainer{
      min-height: unset;
    }
  }

The Home component doesn’t do anything special — it just holds a single component. That component is a Passage-specific tag, namely <passage-auth>, which will display the Passage web component and do most of the work of registering and authenticating your users.

That tag also includes a reference to an appId which will uniquely identify your application to our servers and which we will create here in a bit. The home.component.ts file pulls the appID value out of the environment.ts file. We’ll set that part up later as well.

The Banner Component

The Banner component displays a nice header on the top of the page. There’s no functionality in the component, so it’s a bit easier to set up.

Set the banner.component.html file to look like this:

<div class="mainHeader">
    <a href="https://passage.id/"><div class="passageLogo"></div></a>
    <div class="headerText">Passage + Angular Example App</div>
    <div class="spacer"></div>
    <a href="https://passage.id/" class="link">Go to Passage</a>
</div>

and the banner.component.css as follows:

.mainHeader{
    padding: 20px 30px;
    display: flex;
    align-items: center;
    background-color: #282727;
    color: white;
}

.headerText {
    font-size: 24px;
    margin-left: 10px;
}

.passageLogo {
    background-image: url('https://storage.googleapis.com/passage-docs/passage-logo-dark.svg');
    background-repeat: no-repeat;
    width: 60px;
    height: 60px;
    cursor: pointer;
}

.spacer {
    flex-grow: 1;
}

.link {
    margin-left: 20px;
    color: white;
    text-decoration-color: white;
}

You can leave the banner.component.ts file alone.

The Dashboard Component

The Dashboard component is where all the “real” work will get done. It will display differently based on whether or not the user is authenticated. I’ll show you the code, and then I’ll discuss more about what it does after we get everything all set up.

The dashboard.component.ts file should include this code:

import { Component, OnInit, Input } from '@angular/core';
import { AuthService } from 'src/app/auth.service';

@Component({
  selector: 'dashboard',
  templateUrl: './dashboard.component.html',
  styleUrls: ['./dashboard.component.css']
})
export class DashboardComponent implements OnInit {
  title = 'dashboard';

  public username: String | undefined = '';
  public isLoading: Boolean = false;
  public isAuthenticated: Boolean = false;

  constructor(private authService: AuthService){}

  ngOnInit(){
    this.isLoading = true;
    this.authService.isLoggedIn().then((result) => {
      if (result) {
        this.isLoading = this.authService.isLoading;
        this.isAuthenticated = this.authService.isAuthenticated;
        this.username = this.authService.username;
      } else {
        this.isLoading = false;
        this.isAuthenticated = false;
        this.username = '';
      }
    })
}
}

Add this HTML to dashboard.component.html:

<div class="dashboard" *ngIf="!isLoading && isAuthenticated">
    <div class="title">
        Welcome!
    </div>
    <div class="message">
        You successfully signed in with Passage.
        <br/><br/>
        Your username is: <b>\{\{ username \}\}
        </b>
    </div>

</div>
<div class="dashboard" *ngIf="!isLoading && !isAuthenticated">
    <div class="title">
       Unauthorized 
    </div>
    <div class="message">
        You have not logged in and cannot view the dashboard.
        <br/><br/>
        <a href="/" className={styles.link}>Login to continue.</a> 
    </div>
</div>

and finally, in dashboard.component.css add this code:

.dashboard{
    padding: 30px 30px 20px;
}
.title {
    font-size: 24px;
    font-weight: 700;
    margin-bottom: 30px;
}
.message {
    overflow-wrap: anywhere;
}
.link {
    color: black;
    text-decoration-color: black;
}

An Authorization Service

At the heart of the application is an Authorization service. It is where your application checks the credentials presented.

Create the Authentication service at the command line:

ng generate service Auth

That creates a file called auth.service.ts. Change the code in that file to the following:

import { Injectable } from '@angular/core';
import { PassageUser, PassageUserInfo } from '@passageidentity/passage-elements/passage-user';

@Injectable({
  providedIn: 'root'
})
export class AuthService { 
  isAuthenticated: boolean = false;
  public username: string | undefined = '';
  public isLoading: boolean = true;
  constructor() {

}

  public async isLoggedIn(): Promise<boolean> {
    this.isLoading = true;
    return await new PassageUser().userInfo().then(userInfo => {
       if (userInfo !== undefined) {
        this.isLoading = false;
        this.isAuthenticated = true;
        this.username = userInfo.email ? userInfo.email : userInfo.phone;
       } else {
        this.isLoading = false;
        this.isAuthenticated = false;
        this.username = '';
       }
       return this.isAuthenticated;

  })
}

}

There. That ought to do it. That’s a lot of code, but building it yourself is more fun, right?

Add Passwordless Authentication with Passage

Okay, that part is finished. Now, we need to tell Passage what you are up to and connect Passage to our application.

The first step is to register with Passage. You can do that on this page.

Note that you’ll use our passwordless solution to register and log in!

Once you are in, click the big plus sign to create a new application. From there,

Name your application whatever you like.

Set the Domain to http://localhost:4200 (this is the default for your Angular application)

Set the Redirect URL to: /dashboard

and then select the “Angular” icon and press the “Create New Application” button.

This should set up your application, and you should see the Passage Console displaying something like this:

The Passage Dashboard for your Angular Application

In the “App Info” section on the left, you should have an Application ID (I’ve obfuscated mine in the graphic above). Copy that value, and then open up the environment.ts file in your application and add the following entry to the default values found there:

export const environment = {
  production: false,
  passageAppId: '<Put your AppID here>',
};

What this does is uniquely identify your application to Passage and allow us to work our authentication magic as well as keep stats for you about your application and your users.

Okay, if all is put together correctly, you should be able to go to the command line for your application and enter:

ng serve --open

And you should see something that looks like this:

If everything is working, you should now be able to enter an email address into the login screen, register your device via biometrics, and log in to see the /dashboard page. If you don’t log in and try to navigate to the /dashboard page, you won’t be able to see anything except a message telling you that you aren’t logged in.

So What is Going on Here?

Well, a lot is going on here, but most of it is built into the Passage Web Component element.

The Passage element does all the work of registering and logging in users. You don’t have to do anything past what you’ve already done. The default component is pretty plain-looking by default, but don’t worry — you can customize it to your heart’s content.

Passage authenticates users using the WebAuthn protocol as standardized by the FIDO Alliance. Once it authenticates a user, Passage returns a signed JSON Web Token to identify the user. The whole process is hidden from you, the developer, and your users. All they need to worry about is authenticating with a simple biometrics check.

What Does the Code Do?

As far as what the code is up to, we’ll look at two of the files in the application — auth.service.ts and dashboard.component.ts.

First is the Authentication service.

The AuthService class contains three variables — isAuthenticated, username, and isLoading. isAuthenticated is the key variable here because it is the one that will keep track of whether or not the user is logged in.

The class contains a single function called isLoggedIn() . This function uses the PassageUser class, which is included with the Passage code.

The class is imported via the following import statement:

import { PassageUser, PassageUserInfo } from '@passageidentity/passage-elements/passage-user';

So the code in isLoggedin() merely asks the PassageUser() function for it’s userInfo(). That returns a promise, and if the userInfo is defined, then we know a valid user is present. The variables are set appropriately, and the function returns true because isAuthenticated is true. If the userInfo isn’t found, then the opposite occurs.

This takes us to the Dashboard component. In the dashboard.component.ts file, the ngOnInit() method is called, and the AuthService class is used to set the variables for the class, tracking the status of the user. This is again a promise, so that the information can be properly retrieved and read by the HTML file asynchronously.

The dashboard.component.html file is used to display one of two views, depending on whether the user is authenticated. If the user is authenticated, the username is displayed.

Pretty straightforward, I think.

Just for fun, once you run through the registration and login process a few times with a few different email addresses, you can explore the Console and see the data accumulating for your application.

Finding Out More

There is more to Passage. I already mentioned how you can easily customize the look of the Passage element. In addition, you can collect and store additional information about your users if you like. You can also display a user’s profile with a single HTML element. And of course, we will be continually adding new and useful features.

You can see the <passage-profile> element at work in the 02-Login-With-Profile application that is part of our GitHub Angular example.

Learn More About Passage

So there you have it. If you have any questions at all or need more assistance, or just want to find out more about what we at Passage are up to, please email us at support@passage.id, fill out this form, or join our Discord. We are quite pleased to hear from folks.

How Does WebAuthn Work?

PassageNick — Tue, 20 Sep 2022 20:26:15 +0000

In my previous post, I discussed why passwords are problematic at best and a severe security threat at worst. However, you probably currently have a password-based authentication solution. Hopefully you have implemented some type of Multi-factor Authentication. You might even have implemented Brute Force Password Protection and Breached Password Detection. But in the end you realize that passwords are still a problem. Of course, after reading all that you were probably thinking “But what else is there?”

Well, thankfully, some very smart people have been working on this problem. They formed an organization, worked the problem, and came up with a delightfully effective solution.

The FIDO Alliance

In July of 2012, The Fast Identity Online Alliance – FIDO – was formed by PayPal, Lenovo, and other organizations interested in getting rid of the password. Soon enough, Google, Microsoft, and Apple got on board along with many other companies. (Passage is a member of the FIDO Alliance).

FIDO soon developed open and free specifications for doing passwordless authentication. The key specification is the WebAuthn standard approved by the World Wide Web Consortium (W3C). WebAuthn uses public key cryptography to allow browsers and web resources to authenticate using passwordless methods such as biometrics.

This solution is formally called “Multi-device FIDO Credentials,” but informally, they are called “Passkeys”. Passkeys are based on a FIDO-developed protocol called WebAuthn.

How WebAuthn Works

WebAuthn is quite clever. It leverages the power of public key cryptography to create a way for users to login to mobile and web applications without those applications having to store any secret information at all.

Normally, when one thinks of public key cryptography, one thinks of using it to send a secret message to a person who then decrypts it and reads it. Well, this can kind of work in reverse. If you send them a message encrypted with their public key, then they – and only they – are the only one who can decrypt because only they have the private key that corresponds to the given public key. Once they do, you can be highly confident that they are the entity that they say they are.

Currently, all the major browsers – Chrome, Firefox, Edge, and Safari – all support the WebAuthn specification. If your phone – iPhone or Android – has a fingerprint reader or facial scanner, it supports WebAuthn. Windows provides WebAuthn support via Windows Hello.

All of this translates to passwordless authentication quite nicely. WebAuthn typically goes like this:

You want to log in to a website, so you go to it.
The website asks for your unique identifier, usually your email address or phone number. They may also ask for a username.
The website gets the information, and realizes that it has never heard of you before.
The website says “Hey, send me a public key that is unique to me.”
You validate yourself on your device. This can be via biometrics, a PIN, or inserting something like your Yubikey.
Once validated, your device generates a unique public/private key specific associated only with that website.
You send the site your public key. The site stores that for later use. You save the private key on your device. Note that no secret information at all leaves your device.
At this point, the site doesn’t know for sure you actually are you – so, it may want to verify who you actually are, usually by sending a magic link to your email or phone number. Note that the application doesn’t have to do this because it’s not required via the protocol, but it will likely want to so it can communicate with you.
You click on the link in the message, and the website knows that you actually are the person on the other side of that identifier. Now you are verified by the site.
The next time you want to login, you go to the site and give your identifier (email, phone number..).
The site sends you a known chunk of data as a challenge
You device then signs this challenge with your private key and sends it back.
The site decrypts the data with your public key. If what you sent back matches what the site sent, they you are authenticated.

Now that’s a lot of steps and looks pretty complicated, but most of it happens behind the scenes and is done by the implementation of WebAuthn.

But more importantly, it’s really simple for your users. All they have to supply is a press on a fingerprint reader or a FaceID impression or some other “thing that you are”. The code does the rest. It works great, is very, very secure and happens quickly and easily. No fumbling around with passwords, no bringing up authenticator applications, no checking your email or texts, and no worries about compromise.

How Do Passkeys Fit In?

At it’s heart, a passkey is really just the private key that gets created for every place a user logs in. That passkey is securely stored on your phone within a “Trusted Platform Module” or TPM. A TPM is a special chip now included with most modern devices and computers. For example, it’s required to be present in order for Windows 11 to be installed. The TPM is excessively difficult to compromise, even if a nefarious actor gets possession of your phone.

The nice part about passkeys is that they can be shared amongst different devices, both within and (eventually) between ecosystems. Google, Microsoft, and Apple have figured out a way to securely save those passkeys within their eco–systems so you can even share them between devices. There is even a way to move from one platform to another.

For instance, if you are a totally-committed Apple person, you can log in to a site one time on your iPhone with a passkey, and then that passkey is automatically shared between all of your Apple devices.

If you are a “mixed” person and have a MacBook and an Android phone, you can transfer your login from your MacBook to your Android phone via a QR Code. The process is quite secure, and it uses Bluetooth LE to ensure that the device displaying the QR Code and the device reading the QR Code are in close proximity to each other.

In addition, your Android phone creates a new passkey during the process that is then shareable across the Google ecosystem. You can migrate your login to a Windows device using the same system.

The bonus here is that if you lose or upgrade your phone, all your passkeys are immediately available on your new device without any hassle.

So that is how it all works. But as before, this raises questions. “Is this more secure?” is probably one that comes up. And that will be covered in my next post.

A Path Beyond Passwords

PassageNick — Wed, 07 Sep 2022 17:36:02 +0000

Passwords have been around a long time. They are ubiquitous. But does anyone really like them?

Users don’t like them. Developers don’t like them. Companies spend millions of dollars every year working to prevent password compromises. Worse, many companies suffer password-compromised attacks from hackers, resulting in millions of dollars in losses and bad publicity. Over 80% of all security breaches are the result of a compromised password.

Despite the increasing sophistication of password-based systems, it's just hassle and risk and no fun wherever you turn.

But fortunately, there is a way forward. In this series of articles, I’ll talk about why passwords are problematic and then discuss what is being done to allow us to move past passwords into a passwordless – and vastly more secure – future.

A Short History of Passwords

Password technology has actually come a long way. I’ve been around long enough to remember when the only way people would protect things on the Internet was with Basic Authentication. Here’s how it worked according to Wikipedia:

In basic HTTP authentication, a request contains a header field in the form of Authorization: Basic <credentials>, where credentials is the Base64 encoding of ID and password joined by a single colon :.

Given that Base64 is an encoding and not encryption, you were basically sending the information in the clear for anyone to see. Using it with HTTPS can help, but in the end, Basic Authentication was, well, useless. Naturally, bad guys soon made Basic Authentication pointless.

So next, websites started implementing their own authentication, storing usernames and passwords in their database. This of course meant that any rogue employee could see your password, and that hacking the database meant access to every user’s password in plain text.

Then the good idea of hashing and salting passwords for storage came about. Hashing and salting provides a one-way, unique encoding of your password, allowing sites to store the result, repeat the process, and compare the results when you login. It works well, and the site doesn’t end up knowing your password.

With this, hackers started doing “phishing,” or tricking users into typing their credentials into convincing but fake websites.

The next step was multifactor authentication (MFA). You are likely familiar with this. It is the process of providing more information than a password – something you know and something you have – to the authenticating entity, typically a token – very often that six-digit number from an authentication application.

Currently, this is the de facto standard for authentication. MFA is effective at increasing the security of user accounts. However, phishing attacks have gotten more sophisticated, and even authentication processes involving MFA can be hacked.

In the end, even with our best efforts to make passwords safe and secure, passwords remain a significant attack vector for bad actors and a hassle for users, IT departments, and developers.

Hassle for Users

Our users – who, remember, are very often our customers – have to take an active and often challenging role in the whole password process. We put a lot of the burden for security on them, and they don’t always take it seriously. We end up trusting them to protect access to our resources.

Good password hygiene is difficult and tedious, and people very often don’t follow all the rules. Many reuse passwords across different websites. (Be honest, you have very probably done this, right?) Some use easy-to-figure-out password variations. Others even use passwords that are shockingly simple to guess like “password123” or “qwerty”. They don’t change their passwords from the default. They write them on sticky notes attached to their monitors. They let password-stealing malware get installed on their computers. The list goes on.

And as password management becomes more complex, users have to turn their attention away from where you want it. They end up having to go to a separate application, logging in there (if they can remember that password!) and then coming back to your site with their password. Or with MFA, they have to leave your website to retrieve a timed token from an authenticator application or a text. Either way, it’s a bother and an attention diverter.

And of course, all this creates friction for your users that can deter them from accessing a website. All of us have probably looked at a long list of esoteric password requirements and abandoned our attempt to register. Too strict, and users don’t like it. Too simple, and you risk compromise. And nobody wants to make things tough on customers.

Hassle for Developers

Authentication is always a concern for developers. While many choose to roll their own solutions, there is always the risk that their level of expertise is not up to the task of filling every crevice and corner case.

In addition, pre-packaged solutions exist for most frameworks. This type of solution is usually a safer bet, but developers always don’t know all of the implementation details, meaning they can’t be sure that a configuration change doesn’t create a security issue. And a password-based system, no matter how well implemented, still remains vulnerable to the risks outlined above.

Passwords Don’t Scale

We’ve talked about the vulnerabilities of passwords. Another important thing to note about passwords is that they really don’t scale. When your user base is small, the attack surface is small. But the more customers log into your site, the more likely it is that one of them will make a mistake and get phished. In addition, the more users you have, the more effective a password spraying attack becomes. Growth is good, but with increased growth comes increased risk.

A Necessary Evil (for now)

In the end, passwords don’t make anyone happy. The difficulty of proper password use, the surprising ease with which passwords, and even MFA, can be compromised, as well as the friction created by common authentication methods all make for a system that is ripe for disruption.

Someone ought to do something about this, don’t you think?. Good thing someone has.

Coming next: Goodbye Passwords, Hello Passkeys