LNURL-Auth: A new way to auth without passwords and third parties
Note: There is a Thai translation of this article here.
Authentication is the process of verifying your identity when accessing online services. There are two main types of authentication: using passwords and using social logins like Facebook and Google. Passwords provide more privacy but can be inconvenient to remember. Social logins are easier to use but require you to share personal information with the service.
LNURL-auth is a new type of authentication that aims to provide both privacy and simplicity. It is designed to offer equal or greater security compared to other methods. With LNURL-auth, you can prove your identity without having to share personal information or remember complex passwords.
Weaknesses of using Passwords
There are three weaknesses in using password authentication as follows:
- There is a possibility that the services do not store the password securely. This can make our passwords leak.
- Passwords can be intercepted on unsecured channels.
- Remembering multiple passwords is a hassle. People tend to use the same password on many websites, leading to higher risks of the two weaknesses mentioned above.
With password authentication, two parties know the password, the user and the system, so the security of the password must be the cooperation of both parties. The user must be aware of eavesdropping in various ways, such as man-in-the-middle and phishing attacks. On the other side, there must be a way to prevent password leakage in the system. But there is no way the users can know if their passwords are stored securely until their passwords leak, which would be too late.
With such a risk, we may have been told to set a different password on every site so that password leakage in one site does not affect us on the other sites. This made password authentication cumbersome and an alternative way of authentication using social login became popular because users do not need to remember additional passwords. However, using social login compromises privacy. The website knows our personal information from Facebook and Facebook also knows which website we use.
Therefore, from the weaknesses of password authentication, if we can prove to the websites that we have a valid secret without telling the secret, it will improve security because the secret is stored only in the user’s device and never transmitted to the internet, reducing chances of eavesdropping automatically.
Proving secret availability without exposing the secret
In cryptography, there is an algorithm that solves this problem called digital signature. Each person creates a public-private key pair. The public key acts like a username to represent your identity, while the private key acts like a password to prove yourself. Instead of telling the password to the website directly, the website generates some random data. Users have to bring their private key to sign that data, and then send both the signature and the public key back to the system. The system verifies the signature with the public key and the random data. If the signature is valid, authentication succeeds.
It can be seen that the private key is stored solely on the user’s device. It is never transmitted on the internet. The system never sees it and does not need to keep it either. This mechanism improves security for both the user and the server side.
Security vulnerability of Digital Signature authentication
At first glance, digital signature authentication may seem to be more secure than password authentication, but there is one potential security vulnerability. Like passwords, If we use the same password on multiple websites, someone may take the password from one site to log in to the other sites. Digital signature authentication is also the case. Assuming that two sites are supporting digital signature authentication: Site A and Site B. Instead of Site A generating random data by themselves, they may ask Site B to generate random data for them. If we use the same public-private key pair on both sites, signing random data generated from Site B and sending the signature to Site A allows Site A to utilize Site B on our behalf.
So it is a best practice to use different key pairs for each website. Although Site A can request random data from Site B and authenticate to Site B, they will not see any of our information anyway because we use a different key pair for logging in to Site B. In addition to security, we also improve privacy because we are the only one who knows what public key we use to log in to each website.
LNURL-Auth: Simplifying Digital Signature for end-users
Although we might be unable to remember all the key pairs we used on each website and calculate digital signatures in our heads, we can develop tools to make digital signature authentication easier. However, only the digital signature algorithm alone cannot make authentication tools simple enough for end-users to use. If the digital signature algorithm can be wrapped in a protocol that many websites agree to, authentication tools can provide a simple interface for the users, hiding all the complexity in the background. Users may not even be aware that they are using a digital signature algorithm if the protocol is detailed enough.
LNURL is a set of protocols for commanding the Bitcoin Lightning wallet application using encoded URLs. One of the protocols is the digital signature authentication command, functioning as described earlier. Here we will call it LNURL-auth. Why does it have to be a Bitcoin wallet application? Because these applications can generate key pairs and digital signatures. With these functionalities already in place, adding an authentication functionality is not a big deal at all.
LNURL-Auth from the user’s perspective
Let’s try using the LNURL-auth protocol so that we know what the user’s experience looks like. First things first, we have to install the Bitcoin Lightning wallet application on our mobile phones. There are a lot of Bitcoin Lightning wallet applications supporting LNURL-auth to choose from, but here we will use Phoenix as an example (https://phoenix.acinq.co/).
After installing Phoenix, we will be presented with two options. We can choose “Create new wallet” to create a new master private key or “Restore my wallet” to restore the master private key backup. The master private key will be used to generate different key pairs depending on the websites later on.
If you choose the “Create new wallet” option, there is a way to back up the master private key in case the phone is broken. But we are not going to demonstrate here. Now, we will try logging in to a website that supports LNURL-auth. Open https://lightninglogin.live/ and click “Login with Lightning” in the center of the screen.
You can see that a QR code image is displayed in the center of the screen, and the image contains a clickable link to open the Bitcoin Lightning wallet application. You can either click the image to open the wallet application directly or scan the QR code from another device.
Once the wallet application receives the command, either with the direct link or by scanning the QR code, a pop-up window will appear asking whether you want to log in to the displayed site. Press “Sign-in” to continue.
After authentication succeeds on the wallet application, head back to the web page. The page will automatically refresh every short period. If it does not auto-refresh, you can do it manually. The new page will be displayed, showing the public key. It means that you have authenticated successfully with that public key.
As you can see, the process of logging in with LNURL-auth from the user’s point of view is not difficult at all. It looks similar to social login, but rather than the website directing the user to the Facebook application, it opens the Phoenix application instead. You can try logging in multiple times. Logging in to the same website will get the same public key.
LNURL-Auth from a technical perspective
With the simplicity on the user’s side, let’s take a look at what happened behind the scenes. LNURL-auth has two major flows:
- URL generation: occurs on the server
- Logging in: occurs on the wallet application that supports LNURL-auth
URL generation
The first flow is about generating an authentication URL that encodes the challenge data and the URL that the wallet application uses to send the signature. Before generating the auth link, the server must have an endpoint that can receive the public key and the signature to authenticate a user. We will call it “callback URL”.
- When a challenge is requested, the system generates random 32-byte data, ties it to the session of the person requesting the challenge, and stores it in a cache.
- The system combines the callback URL with random data using query parameter
k1along with the query parametertag=loginto let the wallet application know that this is an auth link. For example,https://site.com/login?tag=login&k1=daad56b93a6a...74f8 - The system encodes the callback URL from step 2 in bech32 format and prepends with
lightning:to let the OS know that this link can be opened in Bitcoin Lightning wallet applications. For example,lightning:LNURL1DP68GURN8GHJ7MRFVA58GMNFDENKCM... - The Lightning URL from step 3 can be used directly as a deep link, or it can be converted to a QR code to be scannable from other devices.
Logging in
Before logging in, the wallet application must be set up to have a master private key stored on the device.
- When the wallet application receives the Lightning URL, either by deep link or QR code scanning, it will decode the Lightning URL and obtain the callback URL. If it finds that the callback URL has a query parameter
tag=login, it will perform the authentication to the callback URL. - The wallet app derives a key pair corresponding to the domain in the callback URL from the master private key, and signs with the random data from the query parameter
k1. - The wallet app combines the callback URL from step 1 with the signature and the public key from step 2 and then requests that URL. For example,
https://site.com/login?tag=login&k1=daad...74f8&key=02ae...bf3e&sig=3044...1601. If the server responds with a success status, the authentication succeeds.
Comparing LNURL-Auth to other authentication methods
LNURL-auth is like a combination of the advantages of password and social login. We obtain privacy similar to using passwords because we do not need any third party to prove our identity. We also obtain ease of use similar to social login because we do not need to remember different passwords on multiple websites.
In addition to these two advantages, we also improve our security because private keys are stored only on the user’s device. Even though the signature may be intercepted during authentication, that signature can only be used once. It is different from using password authentication where no matter how many times you log in, the same secret is always sent over the internet. Users are also protected from phishing attacks since the wallet application uses different key pairs for different websites. If an attacker generates a fake LNURL, it has to be a different domain name from the authentic website and therefore a different key pair will be used.
However, the high privacy of this method of authentication makes signing up to the website for the first time might not as convenient as using the social login because websites cannot retrieve basic information of the user such as name, email address, and profile picture from anywhere. But if future protocols are developed that allow wallet applications to send basic information to websites, it should help make first-time registration even easier.
Sample code
Thank you for reading this article until the end. For anyone who wants to learn more, there is a sample code implementing this protocol on both the server and the application side here: https://github.com/sunboyy/lnurlauth-demo. It is written in Go. Details of usage can be found in the README.md file. Please open issues or pull requests if you encounter problems or want to help improve the project. Thank you!