I can omit the last few characters of my password on Ubuntu 14.04

We have Ubuntu 14.04.3 LTS on our lab PCs in my college. I have noticed a serious bug today.

I can skip the last few characters of my password and still log in smoothly. For example, if my password is a1b2c3d4e5f6g7h8, I can type a1b2c3d4e and still log in. Many other people have also noticed this bug.

Note that the password cannot be bypassed entirely - the maximum I have been able to skip is 7 characters. If I try to skip any more, the message "Invalid password, please try again" appears. Also note that any random permutation of a substring of the password does not work.

This also happens if I lock the screen manually and enter the password again. The same bug is present while using ssh and well, googling and searching Stack Overflow did not help.

My question is - how do I fix this bug, if I can fix it at all? Our sysadm won't be available before Monday, and this is really troubling me.

IMPORTANT: Note that none of the students' accounts are in the sudoers list, only sysadm has root access. Also, the following shows up when I ssh into my own account:

Welcome to Ubuntu 14.04.3 LTS (GNU/Linux 3.13.0-65-generic i686)

* Documentation:  https://help.ubuntu.com/

543 packages can be updated.
350 updates are security updates.

New release '16.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

UPDATE: It looks like the important issue is not the number of characters omitted at the end, but the fact that it is possible to login with the first eight or more characters of the password.

Solution 1:

If you don't have administrator access, there's not much you can do.

That said, this seems to be because of administrator incompetence. This sounds suspiciously similar to password encryption using the classic crypt(3) function. From man 3 crypt:

crypt()  is  the password encryption function.  It is based on the Data
Encryption Standard algorithm with  variations  intended  (among  other
things) to discourage use of hardware implementations of a key search.

key is a user's typed password.

salt is a two-character string chosen from the set [a-zA-Z0-9./].  This
string is used to perturb the algorithm in one of 4096 different ways.

By taking the lowest 7 bits of each of the first  eight  characters  of
the  key, a 56-bit key is obtained.  This 56-bit key is used to encrypt
repeatedly a constant  string  (usually  a  string  consisting  of  all
zeros).   The returned value points to the encrypted password, a series
of 13 printable ASCII characters (the first  two  characters  represent
the salt itself).  The return value points to static data whose content
is overwritten by each call.

Does that sound familiar?

No recent Ubuntu system uses this by default. Your administrator must have manually configured the password setup to use this. Or, they might be using external authentication (LDAP, or similar) and did not or could not configure that securely.

See also: Are passwords on modern Unix/Linux systems still limited to 8 characters?

Solution 2:

There was a time, in a previous millennium, when all Unixen encrypted their passwords this way. Discard everything beyond the eighth character, add salt, drop through a hash function and done.

The big question here is if the encrypted passwords are available to potential hackers. If they are, this is a big problem. If they are not, it really not a big deal. Eight characters passwords has a lot of possibilities. If you have to make an actual login attempt to check a potential password then breaking in is going to a take a long time. Also, the attempts will trigger alarms.

So, the big win here is shadow passwords. Still, people began to think that this was not good enough and every Unix variant implemented their own way of extending the maximum password length. These were no longer compatible.

For a while, if you wanted multiple machines with different Unix variants to use the same password, you had to use the old type of encryption.

It is quite possible that when these computer labs were first set up that was still the case. And this type of setup has inertia. New clients are set up to match the server. New servers are set up to match the clients.

Today, things are better. There are fewer Unix variants in use, and they cooperate better.

I am not competent enough to tell you how to fix this, but it is a task for the admin, not for you.