Decentralized Authentication Across the Web

by anachrohack  (anachrohack@pm.me)

I recently finished the process of de-Googling my life, and one of the hardest aspects was all the accounts I had created with Gmail's Single-Sign-On (SSO).

I found myself stuck in Google's orbit because I had centralized my online identity within their authentication provider.  It got me to thinking: how can we attest to a single identity across the web using a decentralized scheme?  Can we break the stranglehold (((Big Tech))) has on our identities?  The answer: client TLS certificates and DNS!

Bluesky allows users to claim an @example.com username by setting a TXT record on their registrar with a particular code provided by Bluesky.  This associates the account with that particular domain name, allowing a handle like @user.example.com instead of @user.bsky.app.  What if we could do this without a centralized authority?  What if there was a cryptographic way to verify our identity?

TLS allows users to send a client certificate during the handshake process (more specifically, it allows the server to request or even require a client certificate).  If a client certificate is requested, modern web browsers will prompt the user to select a client certificate from their operating system's certificate store.

In Windows, you can create a self-signed certificate with:

C:\Users\UserName\> powershell Windows PowerShell Copyright (C) Microsoft Corporation. All rights reserved. Try the new cross-platform PowerShell https://aka.ms/pscore6 PS C:\Users\UserName> New-SelfSignedCertificate -Subject "CN=username@example.com" -CertStoreLocation "cert:\\CurrentUser\\My" -KeyUsage "DigitalSignature" -Type "Custom" -KeySpec "Signature" -KeyLength 2048 -KeyAlgorithm "RSA" -HashAlgorithm "SHA256" PSParentPath: Microsoft.PowerShell.Security\Certificate::CurrentUser\My Thumbprint Subject ---------- ------- D817FBFC19519AABB8345AC8A3DCB18912CF19B1 CN=username@example.com

This will be automatically saved under your personal folder in the certificate store.  You can get the thumbprint of your cert (which cannot be faked):

PS C:\Users\UserName> Get-ChildItem -Path "Cert:\\CurrentUser\\My" | Where-Object {$_.Subject -eq "CN=username@example.com"} | Select-Object Thumbprint Thumbprint ---------- D817FBFC19519AABB8345AC8A3DCB18912CF19B1

The user can then go to their domain registrar and create a TXT record:

_identification.username.example.com TXT D817FBFC19519AABB8345AC8A3DCB18912CF19B1

When they connect to a website which participates in this scheme, the website will accept all self-signed certificates.  At the application level, it will read the subject line of the certificate (CN=username@example.com) and send a DNS query for TXT records for the domain: _identification.username.example.com

If the thumbprint from the client certificate matches the thumbprint in the TXT record, the server can attest that this user is, in fact, username@example.com without having to have ever met this user or even store credentials on the server.  A user's identity is now portable across participating services!

This approach is not without risk:

• If the server's DNS resolution is compromised, a MITM attack is trivial.  This can be mitigated if the server uses DNSSEC.
• Domain squatters can impersonate people or companies whose domain names they own.
• The user must keep their key secure (though this is more secure than a user re-using passwords across sites!).  If a user's private key is compromised, they must delete the TXT record from their registrar, which can take precious minutes to propagate through DNS caches.

But these are the same concerns which face all identity providers, and have well documented mitigation techniques.  I hope that this can at least spawn discussion around similar ideas.  Decentralization is power!  If you want to discuss further, you can email me at the address above.