WA_USE_INSECURE

WA_USE_INSECURE_COOKIE

Platforms

All 16.5 and later

Abstract

Boolean value determining whether LISTSERV favors login cookies containing plain-text passwords or not. (Default is 0, i.e., "not").

Example

z/VM:

Unix:

WA_USE_INSECURE_COOKIE=1

export WA_USE_INSECURE_COOKIE

Windows:

WA_USE_INSECURE_COOKIE=1

Details

Prior to LISTSERV 16.5, WA login cookies contained an unencrypted e-mail address; a masked but unencrypted password (which, should the cookie be opened by accident, would appear to be garbage, but still was not encrypted); and an array of flags indicating whether the user is a list owner, admin, moderator, and the RUNMODE of the server.

LISTSERV 16.5 and later implements a secure WA login cookie feature. Going from an insecure to a secure WALOGIN cookie is completely transparent to the user, and should be used by all LISTSERV installations. As it is the default in 16.5 and later, nothing needs to be done to configure it.

The feature is controlled by the WA_USE_INSECURE_COOKIE configuration variable. The variable is set like any other LISTSERV configuration variable, and LISTSERV publishes it in SYSTEM.WWWTPL for WA to see and act on.

With WA_USE_INSECURE_COOKIE=1, WA is instructed to favor cookies containing the plain-text password and, being also aware of that, LISTSERV does not bother to generate secure one-time passwords, and it all basically works as before.

With WA_USE_INSECURE_COOKIE=0 (the default), things get more interesting.

The first time through, WA will login using its plain-text password cookie. The design decision was not to bother the user with a login prompt when the password is already available and has already been sent over the net. So, as usual WA does:

17 Apr 2018 12:59:34 From [ANONYMOUS]: X-LOGIN joe@example.com 10.123.231.30 PW=[redacted]

Next, LISTSERV automatically generates a one-time secure password and volunteers it to WA for future use. WA does not have to use it, but it will because WA_USE_INSECURE_COOKIE=0.

17 Nov 2013 12:59:34 To [ANONYMOUS]: ***OK*** PFA2F8FA92A1E2A4810 [redacted]

As before, the one-time password is redacted, but it looks something like this if you run in debugging mode:

XnkXjHxDmn+bJEYXTTVJBg

WA now sees the one-time password and overwrites it into the WALOGIN cookie, still in plain text, but this password has two special properties. First, XnkXjHxDmn+bJEYXTTVJBg is not the user’s online bank password, or any other password the user might be using in an "overloaded" manner. The second special property of this password is that it can be used only once, and only from the same IP address.

So let’s say that a hacker got his hands on this password via an XSS attack. He can try the password all he wants, but from a different IP address it simply won't work. He has to hack your computer in order to use the password – and (in most cases) he only has 15 minutes at the most. In 15 minutes your ticket will expire and you will use the one-time password to obtain a new ticket, which will invalidate the one-time password forever.

The next time WA needs to log in, it will use the one-time password as follows:

17 Nov 2013 14:17:57 From [ANONYMOUS]: X-LOGIN joe@example.com ONETIME 212.247.27.231 PW=[redacted]
17 Nov 2013 14:17:57 To [ANONYMOUS]: ***OK*** OPF36ABF742466929D97 [redacted]

The ONETIME option simply states that the supplied password is a one-time password and should not be attempted as a real password (so as not to lock people out if using LDAP for password validation). LISTSERV returns a new one-time password to replace the one that just expired. The cookie is updated. Note that the ticket starts with O, indicating a ticket obtained from a one-time password.

The one-time passwords are stored as a user configuration variable called *ONETIME*. You can query its existence but not see its contents.

17 Nov 2013 14:34:11 From LISTSERV@LISTSERV.EXAMPLE.COM: x-logck x getcfg: *
* ***OK***
* *ONETIME*=[redacted]

As previously noted, one-time passwords are tied to the IP address they are issued to. A user can have up to 5 active one-time passwords, for either the same or different IP addresses, and they all exist independently of each other. So, if you use both IE and Chrome, they can each have their own one-time password that keeps being replaced. And your laptop or phone can have its own too, up to the maximum of 5.

If tying one-time passwords to IP addresses is problematic for you, which it is bound to be if you have a lot of subscribers from every possible type of organization, you can set WWW_ONETIME_PW_ROAMING=1 to create one-time passwords that are not bound to any IP address and are thus less secure, but still not the user’s online banking password. Note that if you later revert to WWW_ONETIME_PW_ROAMING=0, the unbounded passwords will stop working – the configuration option trumps the wildcard in the password record.

Finally, LISTSERV login tickets are now generated cryptographically, by the operating system's internal cryptographic functions.

Default Value