SASL and CertFP: Modern Authentication on IRC

For the first twenty years of IRC, authentication worked like this: you connected to the server, picked a nickname, then sent a private message to a bot named NickServ containing your password in plaintext. If someone was sniffing the connection — and on pre-TLS IRC, anyone between you and the server could be — they got your password. This was the state of the art until approximately 2010.

The Authentication Problem

IRC was designed in 1988. Authentication was not a priority. The original protocol had no concept of accounts, passwords, or identity verification. Your nickname was your identity, and anyone could use any nickname that wasn't currently taken. The USER command sent a username and realname to the server, but these were self-reported and unverified.

As IRC grew, the lack of authentication became a real problem. Channel takeovers, impersonation, and abuse were rampant. The solution — NickServ and similar services — was a hack: a privileged bot that maintained a database of registered nicknames and passwords, and could forcibly rename or disconnect users who failed to identify.

NickServ worked. But it had three fundamental flaws:

1. Timing window: You connected, got your nickname, then had a grace period to authenticate. During that window, you appeared as an unidentified user. Channels with registered-only mode (+R) would refuse you entry until you identified.
2. Plaintext passwords: The IDENTIFY command sent your password as a regular PRIVMSG. Without TLS, it was visible to anyone on the network path. Even with TLS to the server, the password was processed as a regular message.
3. Race conditions: On some networks, you could lose your nickname to a connecting user during a brief netsplit, then have to fight to reclaim it even though you had the password.

The NickServ Era and Its Flaws

NickServ operated as a pseudo-user — technically a service, but from the protocol's perspective, it looked like just another user. You authenticated by sending it a private message:

/MSG NickServ IDENTIFY mypassword
# or on some networks:
/MSG NickServ IDENTIFY mynick mypassword

The server had no special awareness of this interaction. It was just a PRIVMSG being routed like any other. The NickServ service parsed the message, checked the password against its database, and if valid, set a user mode (typically +r) on your connection to mark you as identified.

This created a particularly nasty attack vector. If someone registered the nickname "NickServ" on a server where services weren't connected (say, during a netsplit), they could impersonate the service and harvest passwords. Most clients eventually added checks to verify that NickServ was actually a network service, but the fundamental architecture was fragile.

SASL on IRC: How It Works

SASL — Simple Authentication and Security Layer — is a framework for adding authentication to connection-based protocols. It was originally defined in RFC 2222 (1997), updated in RFC 4422 (2006), and adapted for IRC through the IRCv3 sasl capability.

The key improvement: SASL authentication happens during connection registration, before you're fully connected to the network. This eliminates the timing window. You authenticate as part of the handshake, and by the time you're visible to other users, you're already identified.

The flow looks like this:

Client: CAP REQ :sasl
Server: CAP ACK :sasl
Client: AUTHENTICATE PLAIN
Server: AUTHENTICATE +
Client: AUTHENTICATE dXNlcm5hbWUAdXNlcm5hbWUAcGFzc3dvcmQ=
Server: 903 :SASL authentication successful
Client: CAP END

The CAP commands are part of IRCv3's capability negotiation system. The client requests the sasl capability, the server acknowledges it, and they proceed with the SASL exchange. The AUTHENTICATE command carries the actual credentials, encoded in Base64.

For SASL PLAIN, the Base64-encoded string contains authzidauthcidpassword where authzid is typically empty or the same as authcid (the account name). This is still a password-based mechanism, but it happens at the protocol level rather than through a PRIVMSG to a service bot.

SASL Mechanisms: PLAIN, EXTERNAL, SCRAM

SASL PLAIN is the most widely supported mechanism. It sends the username and password in Base64 encoding (not encryption — just encoding). This is secure only when used over TLS. Without TLS, the Base64 is trivially decoded. Every major IRC network that supports SASL supports PLAIN.

SASL EXTERNAL uses the client's TLS certificate for authentication. No password is transmitted at all. The server extracts the certificate fingerprint from the TLS handshake and matches it against registered fingerprints. This is the most secure SASL mechanism available on IRC and the one you should use if possible.

Client: CAP REQ :sasl
Server: CAP ACK :sasl
Client: AUTHENTICATE EXTERNAL
Server: AUTHENTICATE +
Client: AUTHENTICATE +
Server: 903 :SASL authentication successful

The second AUTHENTICATE + from the client means "I have no additional data — use my TLS certificate." The server already has the certificate from the TLS handshake.

SASL SCRAM-SHA-256 is a challenge-response mechanism that never sends the password over the wire, even in encoded form. The server and client prove to each other that they know the password through a series of cryptographic exchanges. Support is less common but growing — Ergo (formerly Oragono) and some Atheme configurations support it.

CertFP: Authentication by Certificate

CertFP (Certificate Fingerprint) is the process of generating a TLS client certificate, connecting to IRC with it, and registering the certificate's fingerprint with your account. The steps:

1. Generate a self-signed certificate:

openssl req -x509 -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1   -days 3650 -nodes -out irc.pem -keyout irc.pem   -subj "/CN=myircnick"

This creates a combined certificate and private key file valid for 10 years. The CN (Common Name) doesn't matter for IRC authentication — only the fingerprint is used.

2. Get the fingerprint:

openssl x509 -in irc.pem -noout -fingerprint -sha512 | tr -d ':'
# Output: SHA512 Fingerprint=ABC123...
# Some networks use SHA-256 instead:
openssl x509 -in irc.pem -noout -fingerprint -sha256 | tr -d ':'

3. Register with NickServ:

/MSG NickServ CERT ADD

This registers the fingerprint of whatever certificate you're currently connected with. From that point on, connecting with that certificate is sufficient for identification.

Client Configuration Examples

WeeChat with SASL EXTERNAL:

/set irc.server.libera.ssl on
/set irc.server.libera.ssl_cert %h/irc.pem
/set irc.server.libera.sasl_mechanism external
/set irc.server.libera.sasl_username myaccount

Irssi with SASL PLAIN:

/network add -sasl_mechanism plain -sasl_username myaccount -sasl_password mypassword Libera
/server add -auto -tls -network Libera irc.libera.chat 6697

HexChat with CertFP:

Place your irc.pem in the HexChat config directory (typically ~/.config/hexchat/certs/) and rename it to match the network name. HexChat will use it automatically when connecting with TLS.

The shift from NickServ IDENTIFY to SASL took roughly a decade. Freenode (later Libera.Chat) was an early adopter. By 2020, most active networks supported SASL. It's not perfect — SASL PLAIN over TLS still depends on users choosing good passwords — but it's categorically better than the PRIVMSG-your-password-to-a-bot approach that IRC used for its first two decades.