Challenge-Response Authentication

What users expect these days, is that a session with a server is secured via ‘High Encryption’, so that both the user’s password and his data are truly secure. However sometimes, the server may not have an SSL / TLS certificate, or for some other reason, high encryption may not be available. And in such cases, the need has arisen for the client to prove that it knows the password, without a potential eavesdropper being made aware of it, even if the eavesdropper can capture the entire negotiation.

In such cases, really, the only alternative is challenge-response authentication. I suppose that clear-text password authentication can also be selected on some platforms, but obviously, clear-text solutions are always insecure.

The way challenge-response authentication works in general is, that both the client and the server, have the password or a password-equivalent stored, and that the server next sends a small piece of data to the client, which constitutes ‘the challenge’. This piece of data can most-conveniently be derived from the date and time, so that it never repeats itself, but must be chosen by the server. It is not secret. ( :1 )

What the client is then expected to do, is merely to append this challenge to the password, and to hash the result. The same process is applied by the server, but only the client communicates the result back to the server, the latter of which verifies that the result from the client matches, with what the server obtained internally, when the server also appended the same challenge, to the same password, and hashed the results.

This approach can be so basic, that it can even be implemented in JavaScript! Yet, it should in principle be just as strong, as the password itself (which is not really so strong).

There are a few differences in specific implementations. For example, it may be that the actual password is not stored on the server, but that only the hash-code of the password is stored. Well in that case, after prompting the user for the password, the client must also hash it once, to obtain the equivalent of what’s stored on the server, the client must then append the challenge to it, and the client must hash the result a second time.

(Updated 04/01/2018, 14h00 … )

Continue reading Challenge-Response Authentication

Opus En Ligne

( Last edited on 11/25/2016. )

On the Island Of Montreal, bus and subway fares have been handled for many years via a contact-less smart-card, called our “Opus Card”. Most residents “recharge” their fares at designated commercial establishments, but those so inclined may instead buy a USB-connected reader for this card, which also has contacts, which the privately-used readers use to recharge them.

I am one passenger, who chooses to pay their fares this way at home, by plugging the USB-cable of the card-reader into my remaining Windows 7 computer named ‘Mithral’, and by going to a Web-site, where we can provide payment information.

Until last month, the way in which this system worked was:

  • We install a device-driver for the actual card reader – which is chosen for us by the designated site.
  • We kept our Java installation up-to-date.
  • The site charges our payment method, validated on their side.
  • The Web-site deployed and launched a Java application with each use, that connected to the card reader and wrote changes to the data on the card.

At least in theory it was possible to say, that this system was based on an open standard, that being Java.

But as of this month, the transit authority has switched to a different system. We still need the actual USB driver for the card reader. But now we must also download what they call their ‘SmartCardPlugin’, which is given to us from the site as an .MSI File in the case of Windows users. This plug-in actually forms the bridge, between their Web-application and the recognized card reader.

While this system seems to work quite well, based on my first use today, I would say it represents bad programming aesthetics. Even though the actual software-components were provided by Xerox, this system does not install a PKCS#11 security device, nor anything approaching a CAC card reader, with PKI. Instead, this service is based on an .EXE File, and leaves its hook in our browser, which in the case of Firefox, we can find under Tools -> Options -> Applications.

What this means is that the site will display an Web-object, that needs to be ‘opened’ by a specific application, associated by the Web-browser.

The most positive aspect to how this works seems to be, that indeed, it provides compatibility with Firefox, Chrome, IE etc..

But instead of providing strong security, this method is only as secure as the SSL connection to the site.

It may be interesting to note, that even when this system was based on Java, none of the officials ever promised that it would work under Linux, so I see no loss there.

Some users have complained, in that this system fails to meet their expectations, in one day combining the payment service as a smart-phone, NFC service. I have to concur with this hope. I also find it a bit clumsy right now, to have to plug in my Opus Card into a USB port, and to open a site which asks me for my payment credentials – ‘the old-fashioned way’.

But OTOH, I do not see much of a practical loss, compared with how it used to work. And one reason the officials may be doing it this way, could be a negative prognosis for the future of Java itself.

It just so happens that I prefer proven standards.


Continue reading Opus En Ligne