EmechNet has deployed a major authentication and account-security upgrade for X, our account and channel service.

X now supports modern IRCv3 authentication, TLS certificate login, two-factor authentication, recovery codes, persistent login history, suspicious-login alerts, account freezing, forced logout, and stronger brute-force protection.

These features are available immediately and are documented through X’s built-in help system.

IRCv3 SASL support

X now supports three IRCv3 SASL mechanisms:

• PLAIN
• EXTERNAL
• SCRAM-SHA-256

SASL allows compatible IRC clients to authenticate to an X account automatically while connecting to EmechNet. This means users can be identified before joining channels, receiving registered-user modes, or encountering channel restrictions that require an authenticated account.

The EmechNet IRC server now advertises:

sasl=PLAIN,EXTERNAL,SCRAM-SHA-256

Use the following command for detailed instructions:

/msg X HELP SASL

SASL PLAIN

SASL PLAIN authenticates using your X username and password. Despite its name, it is only offered on TLS connections, so the authentication exchange is protected while travelling between your IRC client and EmechNet.

Users with TOTP enabled must supply their password and current authenticator or recovery code in this form:

password:code

For example, if an IRC client has separate SASL username and password settings:

Username: YourXAccount
Password: YourPassword:123456

A one-use recovery code can replace the six-digit authenticator code.

SASL EXTERNAL

SASL EXTERNAL authenticates using a TLS client certificate. Instead of sending a password, your IRC client proves that it possesses the private key associated with a certificate fingerprint registered to your X account.

To register the certificate used by your current secure connection:

/msg X@services.emechnet.org CERT CURRENT laptop

You may also register a SHA-256 fingerprint manually:

/msg X@services.emechnet.org CERT ADD <fingerprint> [label]

Available certificate commands include:

CERT CURRENT [label]
CERT ADD <fingerprint> [label]
CERT DEL <fingerprint>
CERT LIST

Each fingerprint can belong to only one X account, and an account may register up to ten certificates.

When TOTP is enabled, a registered certificate used through SASL EXTERNAL satisfies the account’s second-factor requirement. Users should protect the certificate’s private key as carefully as a password.

More information is available through:

/msg X HELP CERT

SCRAM-SHA-256

SCRAM-SHA-256 provides password-based authentication without transmitting the password itself. The client and X instead exchange cryptographic proofs demonstrating that both sides possess the correct authentication material.

X stores a dedicated SCRAM verifier rather than a recoverable password.

Existing accounts must successfully authenticate once using the traditional AUTH command or SASL PLAIN—or change their password—before SCRAM can be used. This is necessary because a SCRAM verifier cannot be reconstructed from the one-way password hash already stored for an account.

Accounts with TOTP enabled cannot currently use SCRAM-SHA-256. Standard SCRAM does not provide an interoperable field for a separate rotating authentication code. Those accounts should use:

• SASL PLAIN with password:code; or
• SASL EXTERNAL with a registered TLS certificate.

TOTP two-factor authentication

X supports time-based one-time passwords generated by common authenticator applications.

Begin setup over a secure connection:

/msg X@services.emechnet.org MFA SETUP

X will display an authenticator secret and an otpauth URI. Add the account to your authenticator application, then confirm it using a current six-digit code:

/msg X@services.emechnet.org MFA ENABLE <code>

Once enabled, normal X authentication requires:

/msg X@services.emechnet.org AUTH <account> <password> <code>

SASL PLAIN requires the code after the password:

password:code

The EmechNet web portal also enforces TOTP. Its login page now includes an optional authenticator or recovery-code field, which becomes mandatory for accounts that have MFA enabled.

To disable MFA:

/msg X@services.emechnet.org MFA DISABLE <current-code>

Full instructions are available through:

/msg X HELP MFA

Recovery codes

When MFA is enabled, X generates eight one-use recovery codes. These can be used when an authenticator application or device is unavailable.

Recovery codes are:

• Displayed only when initially generated or deliberately regenerated.
• Stored by X as cryptographic hashes.
• Valid for one authentication each.
• Removed automatically after use.
• Accepted by AUTH, SASL PLAIN and the web portal.

Store them somewhere secure and separate from the device containing your authenticator application.

To replace all existing recovery codes:

/msg X@services.emechnet.org RECOVERYCODES REGENERATE <current-code>

Regenerating codes immediately invalidates every older recovery code.

See:

/msg X HELP RECOVERYCODES

Login and session history

X now maintains a persistent security timeline covering successful, failed and suspicious authentication attempts.

To see recent authentication events:

/msg X LOGINHISTORY

An optional limit between 1 and 50 may be supplied:

/msg X LOGINHISTORY 30

Each entry includes:

• The date and time.
• The event type.
• Whether it succeeded or failed.
• Whether it was considered suspicious.
• The authentication mechanism.
• The connecting source.
• Relevant security details.

Traditional session history remains available through:

/msg X AUTHHISTORY

This displays the last ten X sessions, including their login time, nickname and hostname, disconnect time, and quit or session-revocation reason.

Currently authenticated IRC sessions can be viewed with:

/msg X SESSIONS

To revoke every other IRC session using your account:

/msg X LOGOUTALL

See:

/msg X HELP LOGINHISTORY
/msg X HELP AUTHHISTORY
/msg X HELP SESSIONS

Suspicious-login alerts

After an account has established a login baseline, X checks successful logins for an unfamiliar IP network.

A login from a new network is marked as suspicious and recorded in the account’s security history. X will also:

• Warn clients already authenticated to the account.
• Report the event to EmechNet operators.
• Send an alert to the account’s registered email address when mail delivery is available.

A suspicious alert does not automatically mean that the account has been compromised. Mobile connections, VPNs, travel, changing providers and privacy networks can all result in a new source network.

If you do not recognise a login:

1. Run LOGINHISTORY.
2. Run LOGOUTALL.
3. Change your X password.
4. Remove any unrecognised certificate fingerprints.
5. Contact EmechNet staff if the account should be frozen.

More information is available through:

/msg X HELP SECURITYALERTS

Account freezing

Services administrators can now freeze an X account during a suspected compromise or other security incident.

Freezing an account:

• Blocks password authentication.
• Blocks every SASL mechanism.
• Blocks certificate authentication.
• Revokes all active IRC X sessions.
• Revokes all active web-portal sessions.
• Records the administrator, reason and time in the security timeline.

Operator syntax:

/msg X FREEZE <account> ON <reason>

To restore authentication:

/msg X FREEZE <account> OFF <reason>

Unfreezing the account also clears its temporary account authentication lock so that the owner can authenticate again.

See:

/msg X HELP FREEZE

Forced logout

Services administrators can revoke every active IRC and web session for an account without freezing future logins:

/msg X FORCELOGOUT <account> [reason]

This is useful when sessions must be invalidated immediately but there is no reason to block the next legitimate login.

Every forced logout is recorded in the account security timeline and the operator audit log.

See:

/msg X HELP FORCELOGOUT

Brute-force protection

X applies persistent authentication limits by both account and connection source. These protections cover the traditional AUTH command and all supported SASL mechanisms.

The current limits are:

• Five failed attempts against an account within ten minutes.
• Twelve failed attempts from a source within ten minutes.
• A temporary 15-minute authentication lock after reaching a limit.

Authentication failures use deliberately generic responses. This prevents attackers from using error messages to determine whether an account exists, is frozen, or has a particular security feature enabled.

A successful authentication clears the associated failure counters.

Unlike memory-only rate limiting, these counters are stored persistently and therefore survive an X restart.

See:

/msg X HELP BRUTEFORCE

Complete help command list

The following X help topics explain the new security features:

/msg X HELP SASL
/msg X HELP CERT
/msg X HELP MFA
/msg X HELP RECOVERYCODES
/msg X HELP SESSIONS
/msg X HELP AUTHHISTORY
/msg X HELP LOGINHISTORY
/msg X HELP SECURITYALERTS
/msg X HELP FREEZE
/msg X HELP FORCELOGOUT
/msg X HELP BRUTEFORCE

These changes are included in XBot v4.11 and are now active across EmechNet.

Users are encouraged to enable TOTP, securely store their recovery codes, review their login history periodically, and consider certificate-based SASL EXTERNAL authentication for frequently used IRC clients.