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

File-Sharing under Linux, using Usershares – the Modernistic Way.

One concept which readers may already know, is that under Linux, we can set up a Samba-server, which makes the sharing-out of our home directories possible, and that if we fiddle with the ‘smb.conf’ configuration file thoroughly enough, it becomes possible to browse the available shares on a LAN, in a way semi-compatible with Windows computers that also reside on the same LAN.

Traditionally, this has always been a bit of a PITA, especially since the ‘/etc/samba/smb.conf’ configuration files have been finicky, and since each share practically needs to be configured individually, by a person with the ‘root’ password.

Well an alternative exists under Linux as well, which is the concept of ‘Usershares’. With this concept, each user who belongs to a specific group has the privilege, of designating a folder within his desktop manager, to share out, pointing-and-clicking. This is closer in ease-of-use, to how the process works under Windows. But, it needs to be set up correctly once, by the sysadmin, before it will work as often as simple users wish it to work.

I think that an existing Web-article on the subject, already explains well, what the settings in the ‘smb.conf’ file need to be, as well as what directories need to exist, in order for usershares to work. Except that the article I just linked to, refers to Fedora and SELinux systems and their norms. I happen to be based on Debian and KDE 4 or Plasma 5. And so I have a few observations to add:

Firstly, the following packages should be installed, under Debian also:


#apt-get install kdenetwork samba


Secondly, ‘/etc/samba/smb.conf’ needs to be edited like so:




Under Debian, the directory ‘/var/lib/samba/usershares’ already exists, If the relevant packages are installed. And its permission-bits have already been set as they should be set. Only, the feature is not configured in ‘smb.conf’ by default. And, the additional package named ‘kdenetwork-filesharing’ needs to be installed, in order for the tab to appear in Dolphin’s File-Properties box, that enables sharing from the GUI. Aside from that, enabled users need to be added to the ‘sambashare’ group, after which this membership only goes into effect, once the user in question has started a new session…

(Info Corrected 03/25/2018, 17h10,

Updated again 03/28/2018 … )

Continue reading File-Sharing under Linux, using Usershares – the Modernistic Way.

Freshly switched to KDE 4 or Plasma 5, and unable to Browse Network Shares using Dolphin?

I just installed Plasma 5 from the package-manager, on my tower-computer named ‘Plato’, only to find that for some time, I was unable to browse Windows File Shares – i.e. ‘SMB Shares’ – casually, just using the ‘Dolphin’ File Manager. Yet, I was able to mount these shares using ‘Smb4K’, making them visible in my local folders as though there.

Dolphin was showing me an essentially empty set of icons when displaying the Network.

As it turns out, we need to install a package named:


Which will give Dolphin the additional plug-ins it needs, to recognize ‘smb://’ URIs. If our Plasma 5 desktop manager was set up professionally, then the person doing so would know about such details. But when individuals set up KDE or Plasma for the first time, we need to learn such details first-hand.




As an added note, we might find that when we click on the Trash widget in our Panel, which I left just at the right-most end, we may get the error-message to the effect that ‘trash:/’ was a corrupted URL. Yet, from within Dolphin, the trash bin displays just fine.

In my case this was happening, because I did not have Dolphin set up as my default File Management application, in my Plasma 5 Settings, where instead I had an application selected which would have been appropriate to an LXDE desktop, and which does not recognize URIs that begin with ‘trash:/’. Switching this setting to make Dolphin my Default File Manager, fixed this problem.