We have noticed a possibly disturbing phenomenon with passwords. My own password is 11 characters long, and I can seemingly add any string I want to the end of it and still be admitted. Also I can truncate it down to the first 8 characters and still be admitted. This is true for other faculty here and is true on both a newly installed 2.7 server and a 2.5 server that we use.
So it seems clear that the password hash is only looking at the first 8 characters of a password string. Give it a try with your own password, assuming they are 8 or more characters long.
Is this known to everyone? Is this how things should be or this an oversight? Maybe it doesn't matter if 8 characters is secure enough, but it was kind of a surprise to me.
Alex
Hi Alex,
Yes I believe that this is a known issue but maybe not very well known (and probably forgotten by people who knew about it including me). I believe Jason Aubrey was going to fix this awhile ago but obviously it did not get fixed.
Arnie
In fixing this, there are a couple of considerations:
- If this is changed, then upgrading to the new encryption will require all passwords to be reset, as it should be impossible to change encryption from one type to another for existing data.
The solution is probably to include a flag somewhere indicating which encryption is used for a particular password (or collection of passwords). My first thought was to put this in the config files, so that it can be overridden on a course-by-course basis (via course.conf). Then I wondered if it made more sense to add a column to the password table indicating what type of password it was, which would allow new users in a course to use md5, while old ones continued to use crypt. - Should we be salting passwords?
Con: currently WeBWorK class lists are pretty portable (including the default .dist ones). This would make it hard (possibly impossible) to move a class list from one server to another and preserve passwords.
Pro: salted passwords are much harder to decrypt. There are md5 lookup tables on the web. If someone obtained an unsalted md5 encrypted password, they would have a good chance of being able to reconstruct the plain text password (at least for relatively short passwords).
Danny
The passwords are handled through the perl
crypt() function, which probably calls the underlying system's crypt library. Historically, unix passwords only used the first 8 characters, and that may still be included in the system code.
From the perl documentation (emphasis mine):
Traditionally the result is a string of 13 bytes: two first bytes of the salt, followed by 11 bytes from the set "[./0-9A-Za-z]", and only the first eight bytes of PLAINTEXT mattered. But alternative hashing schemes (like MD5), higher level security schemes (like C2), and implementations on non-Unix platforms may produce different strings.
so it may be system dependent. But yes, this is the expected behavior, in general.
Davide
Hi,
We already use md5_hex in .../Authen/Moodle.pm
Authen/Moodle.pm:use Digest::MD5 qw/md5_hex/;
Authen/Moodle.pm: my $possibleMD5Password = md5_hex($possibleClearPassword);
Also in Upload.pm
Upload.pm:use Digest::MD5 qw(md5_hex);
Upload.pm: my $hash = md5_hex($uuid, $secret);
Should we use that (or something similar) in place of crypt?
Arnie