SASL Authentication Built-In - mIRC Discussion Forums

Hello,

Are there any plans to include a built-in SASL functionality? We had been directing people to use the SASL script that was created years ago for this purpose, but it's clunky and finicky. As a solution, we've been recommending that our users switch to AdiIRC or HexChat as desktop alternatives in order to use the SASL Auth feature easily -- most elect to switch clients rather than fight with the script.

This would probably have to go hand in hand with providing better network and password management per-network for identifying to various nick authentication services, since the current 'perform' function is rather outdated in comparison to pretty much every other client -- even the non-GUI clients many of my opers use have these things built into them.

At any rate, we'd like to know if there are plans to build this in or if it's a matter of use the old SASL script add-on because there is no intention of doing so.

Thanks!

I can write a very short, quality SASL script, that transparently utilizes information from mIRC's server management UI. (Thanks to the new On PARSELINE event). I will need to see a set of SASL client/server interactions to emulate from, though.

I also think a collection of SASL auth interactions posted here would give Khaled a better understanding of all the different scenarios to code for.

I don't think this is an issue of not having a robust script (in fact, I rolled my own which is less than a hundred lines; and that includes some very specific stuff that I just put in there for teh lulz), but for integrating it better into the Client application itself (since others do so, and many servers support it as standard feature).
Plus, it requires changing the CAP request, which is pretty much the first thing that goes out, and requires on LOGON or perhaps on PARSELINE to do so.

SASL authentication should be as "easy" as

Ask for the servers capabilities to see if they even support it (CAP LS, before USER/NICK)
- In case the server does not support CAP, ignore
- In case the CAP LS response includes SASL, continue with authentication by requesting it (CAP REQ :sasl, optionally including other capabilities such as multi-prefix)
- In case it doesn't, end the capabilities dance (CAP END)
Once the server acknowleges the sasl request (CAP ACK), start the authentication with a given/preferred method (AUTHENTICATE)
The server should then accept the authentication by replying with a +, not sure what it returns otherwise
After that, send the encrypted payload (AUTHENTICATE). Note that this should be chunked to 400 characters, for (hopefully) obvious reasons.
If we're still here, end the capabilities dance (CAP END)

Used to have some documentation somewhere, but I can't find it atm...so here's a log of my script:

Code:

-> irc.domain.tld CAP LS
-> irc.domain.tld USER bhaal 0 * :BhaaL
-> irc.domain.tld NICK BhaaL
<- :irc.domain.tld NOTICE * :*** Looking up your hostname...
<- :irc.domain.tld NOTICE * :*** Found your hostname
<- :irc.domain.tld CAP * LS :userhost-in-names multi-prefix away-notify account-notify sasl tls
-> irc.domain.tld CAP REQ :multi-prefix sasl
<- PING :D59F9447
-> irc.domain.tld PONG :D59F9447
<- :irc.domain.tld CAP BhaaL ACK :multi-prefix sasl 
-> irc.domain.tld AUTHENTICATE PLAIN
<- AUTHENTICATE +
-> irc.domain.tld AUTHENTICATE <auth digest/hash/whatever>
<- :irc.domain.tld 900 BhaaL BhaaL!bhaal@home.tld BhaaL :You are now logged in as BhaaL.
<- :irc.domain.tld 903 BhaaL :SASL authentication successful
-> irc.domain.tld CAP END
<- :irc.domain.tld 001 BhaaL :Welcome to the IRC Network BhaaL!bhaal@home.tld
<- :irc.domain.tld 002 BhaaL :Your host is irc.domain.tld, running version UnrealIRCd-4.0.6

My script just overrides on LOGIN, then raw CAP and raw AUTHENTICATE to do the job (plus some numerics for fun)

At last!

http://hawkee.com/snippet/17983/

Code:

; r_shitty_sasl.mrc                           http://hawkee.com/snippet/17983/
; ----------------------------------------------------------------------------
;  SUPER SHITTY SASL Script by Raccoon 2017-Feb-14 for mIRC 6.10 or greater.
;  FIRST RELEASE. SUPER SHITTY. VALENTINE'S DAY EDITION. 2/14/2017 -- ENJOY!
; ----------------------------------------------------------------------------
;
; Q. Can I have other SASL scripts loaded?
; A. NO! No, no no. Uninstall all other SASL scripts!
;
; Q. How do I work it?
; A. Just edit your Server settings, plugging your
;    nickname:password into the Password field.
;
; /------------------------------------------------------------\  ==========
; | Edit Server                                          [ X ] |  ATTENTION!
; | +--------------------------------------------------------+ |  ==========
; | |                                                        | |
; | |  Description:  [ chat.freenode.net               ]     | |   PUT YOUR
; | |                                                        | |
; | |   IRC Server:  [ chat.freenode.net               ]     | |   NICKNAME
; | |                                                        | |
; | |        Ports:  [ +6697,+7000,+7070               ]     | |     AND
; | |                                                        | |
; | |        Group:  [ Freenode                   ]          | |   PASSWORD
; | |                                                        | |
; | |  -> Password:  [ Raccoon:MySeKrItPaSsWoRd   ] <-------------- HERE!! <-
; | |                                                        | |
; | |     *------------*  *------------*  *------------*     | |   SEPARATED
; | |     |     OK     |  |   Cancel   |  |    Help    |     | |
; | |     *------------*  *------------*  *------------*     | |    WITH A 
; | +-rac----------------------------------------------------+ |
; \------------------------------------------------------------/   COLON ':'
;
; This script will utilize your nickname:password information that
; is supplied by the PASS command to initiate the SASL handshake.
; The PASS command will still be sent, and acts as a fallback.
;
; This script is SUPER SHITTY because it gives no shits about the proper
; back-and-forth exchange of CAP negotiation.  It just fires off commands.
; It works almost all the time. Your results may vary. No warranty.
;
; If you have any questions, ask for help in ##mIRC on freenode. -- Raccoon
;
; Advice: Always connect to IRC via encrypted SSL port. eg: +6697 (not 6667)
;
; ----------------------------------------------------------------------------

On ^*:LOGON:*: {
  if ($version < 7.42) {
    debug -ip $iif($debug,$v1,on) SHITTY_SASL
} }

ALIAS SHITTY_SASL {
  if ($regex($1-,/^-> \S+ PASS (\S+?):(\S+)$/)) {
    noop $SUPER_SHITTY_SASL_AUTH($regml(1),$regml(2))
    debug $iif($window($debug),$v1,off)
  }
  return $1-
}

On $*:PARSELINE:out:/^PASS (\S+):(\S+)$/: { 
  noop $SUPER_SHITTY_SASL_AUTH($regml(1),$regml(2))
}

ALIAS -l SUPER_SHITTY_SASL_AUTH {
  var %u = $1, %p = $2
  .raw CAP REQ :sasl
  .raw AUTHENTICATE PLAIN
  bset -t &auth 1 %u $+ $lf $+ %u $+ $lf $+ %p
  breplace &auth 10 00
  noop $encode(&auth,mb)
  .raw AUTHENTICATE $bvar(&auth,1-).text
  .raw CAP END
} ; by Raccoon 2017

; Footnote.  This script is intentionally the shittiest way to implement SASL.
; HOWEVER! It is the smallest SASL script, and works with all versions of mIRC v6.1+ (2003).
; So, eat it. The cake is real. -- Raccoon

; End of script.

Added a minor change. Shuts off /debug upon first server reply.
Also changed instances of $v1 to $debug ($v1 did not exist in 6.10).
Also silenced /debug commands with '.debug'.
http://hawkee.com/snippet/17983/

Code:

; 2/15/2017 http://hawkee.com/snippet/17983/
On ^*:LOGON:*: {
  if ($version < 7.42) {
    .debug -ip $iif($debug,$debug,on) SHITTY_SASL
} }

ALIAS SHITTY_SASL {
  if ($regex($1-,/^-> \S+ PASS (\S+?):(\S+)$/)) {
    noop $SUPER_SHITTY_SASL_AUTH($regml(1),$regml(2))
    .debug $iif($window($debug),$debug,off)
  }
  if ($1 == <-) { .debug $iif($window($debug),$debug,off) }
  return $1-
}

On $*:PARSELINE:out:/^PASS (\S+):(\S+)$/: {
  ; versions >= 7.42 (2015)
  noop $SUPER_SHITTY_SASL_AUTH($regml(1),$regml(2))
}

ALIAS -l SUPER_SHITTY_SASL_AUTH {
  var %u = $1, %p = $2
  .raw CAP REQ :sasl
  .raw AUTHENTICATE PLAIN
  bset -t &auth 1 %u $+ $lf $+ %u $+ $lf $+ %p
  breplace &auth 10 00
  noop $encode(&auth,mb)
  .raw AUTHENTICATE $bvar(&auth,1-).text
  .raw CAP END
} ; by Raccoon 2017

Originally Posted By: BhaaL

I don't think this is an issue of not having a robust script (in fact, I rolled my own which is less than a hundred lines; and that includes some very specific stuff that I just put in there for teh lulz), but for integrating it better into the Client application itself (since others do so, and many servers support it as standard feature).

That's what I was going for. mIRC is one of the very few clients these days that does not support SASL without an add-on, and it's also one of the few that doesn't have built-in authentication fields for users to easily auto-identify to services available on a network.

My network offers SASL, and we have it implemented so users can get around CIDR bans placed on problem hosts. We also provide SSLFP authentication, which is handled better in other clients as well, but it's a bit frustrating that it is simpler to walk a person through creating a certificate and using it with mIRC than it is getting them set up with SASL.

Thanks to all of you for the updated script options. I'll be pointing people here for self-help along with the old script, since we've stopped supporting mIRC on our network for these and a few other issues.

I assume you haven't seen that mIRC will in fact support SASL natively from the next version going forward, as per the beta available right now..

Originally Posted By: daemhan

We also provide SSLFP authentication, which is handled better in other clients as well, but it's a bit frustrating that it is simpler to walk a person through creating a certificate and using it with mIRC than it is getting them set up with SASL.

That would be an interresting next step here; to support the creation of a "client identity" (in form of a client certificate) which can be used when connecting to SSL-enabled servers - for the potential of being used for CERTFP/SSLFP authentication later on if the services support it.

Quote:

creation of a "client identity" (in form of a client certificate)

I was actually working on this for the next beta :-) ie. automatic creation and use of SSL client certificate file on startup if one does not exist. It will be created using RSA,sha256,2048 bit and C=US,O=Personal,CN=localhost. There will also be two new $sslcertsha1 and $sslcertsha256 identifiers that return the fingerprint of the currently loaded SSL client certificate file for use with /nickserv cert add.

Sounds great, looking forward to that!
Not sure about making everyone a US-citizen in that cert tho.

Quote:

Not sure about making everyone a US-citizen in that cert tho.

I could make mIRC ask Windows for your geographical location and use that in the certificate. However, this information would then be available to IRC servers that you connect to using SSL. That said, auto-generating a private certficate does raise some privacy issues. Using a private certificate that is uniquely identifiable means that you can be tracked across networks, even if you change your nickname, IP address, use a VPN, and so on. Adding your actual country code to the certificate erodes that privacy that little bit more. On the other hand, it helps with authenticating your connection for different types of services.

Update: on second thought, from a privacy perspective, it may not be a good idea to install a client certificate automatically. I found a discussion about this on Mozilla - click the two links at the bottom of the page for more information. However, I can add a "generate client certificate" button to the SSL dialog in mIRC that enables users to create client certificates easily if they need them.

Originally Posted By: Khaled

However, I can add a "generate client certificate" button to the SSL dialog in mIRC that enables users to create client certificates easily if they need them.

I've considered suggesting this as well, but decided to leave it out.
Those who want certificate authentication are probably smart enough to find the button, and those who don't want/care are unlikely to use it for service authentication either way.

Originally Posted By: Khaled

Update: on second thought, from a privacy perspective, it may not be a good idea to install a client certificate automatically. I found a discussion about this on Mozilla - click the two links at the bottom of the page for more information. However, I can add a "generate client certificate" button to the SSL dialog in mIRC that enables users to create client certificates easily if they need them.

Automatically creating a certificate for user in my opinion is definitely bad route to go. "generate client certificate" button to the SSL dialog is definitely better.

On same note the client certificate should not be presented to server without express autorization from user.

Also as far as privacy/tracking goes the cert could (should?) be representing rather the nickname than user, thus allowing me to use cert1 for network1 and cert2 for network2 and not sending out any cert for networ3 if I have not specified one for use in Server/Network settings for given network.

Least from personal standpoint if I'm limited with one personal certificate thus forcing me to uniquely identifying myself to every IRC Server I happen to connect I would rather do without the personal cert.

So, as of mIRC 7.48, we now have built-in SASL support. Awesome! But due to how it is implemented, its not possible to use it in the case of an IRC server that requires a password to connect, because the way its implemented is a "one or the other" way.

I for example run a few servers of which one is a server where I have some users connect with a server password that is of the format "username:password". These credentials are not the same as their NickServ/account credentials. Because of the lack of an additional field where they can specify an additional "username:password" for their account, I can't make these users use the new built-in functionality and so still have to make them use the Perform-settings to identify to their account that way.

It would be great if there was an additional field for account credentials in the future.