users-admin sets up maximum 8 character password

[Ivan Zorin]

I use "Intrepid" beta with latest updates and I've found out accidentally, that if in GNOME login screen or in gnome-terminal (for su command) or at tty[1-6] screens enough to input only 8 chars of correct password - in that case authorization will be successful. For example, if I have password for my account, which contains 25 symbols, then if I input only 8 first symbols of my password at GNOME login screen, login will be successful. The same occurs in gnome-terminal for su command - to get super user's privileges, enough input only 8 chars.
Besides, I check it at "Hardy" - here everything ok - it's necessary to input full password correctly for pass authorization.
I don't sure, but maybe only I have this problem. So, it's be very intresting, if someone else check this and reports about it.

Some information:
$ lsb_release -rd
Description: Ubuntu 8.10$ apt-cache policy gnome-terminal
gnome-terminal:
  Installed: 2.24.0-0ubuntu2
  Candidate: 2.24.0-0ubuntu2
  Version table:
 *** 2.24.0-0ubuntu2 0
        500 http://gb.archive.ubuntu.com intrepid/main Packages
        100 /var/lib/dpkg/status

Release: 8.10
$ apt-cache policy gnome-terminal
gnome-terminal:
  Installed: 2.24.0-0ubuntu2
  Candidate: 2.24.0-0ubuntu2
  Version table:
 *** 2.24.0-0ubuntu2 0
        500 http://gb.archive.ubuntu.com intrepid/main Packages
        100 /var/lib/dpkg/status

[Ivan Zorin (iaz)]

To try reproduce this bug, follow next steps:
1. run users-admin utility;
2. press "Unlock" button and type your password;
3. press "Add User" button;
4. type in username's field "example" and in password's field "verylongpassword"
5. select in Profile's field "Administrator"
6. in advanced settings select in Main group's field "users"
7. press OK button and log out
8. at gdm screen type "example" as login and "verylong" as password
9. after that authorization should be successful

BTW, adding user via adduser utility (from terminal) requests full input of password.

Some notice - looks like users-admin utility adding hash for only first 8 chars of password in /etc/shadow.
So, to fix this issue I've replaced hash for my user account in /etc/shadow - I've copied this hash from hardy's /etc/shadow - there is everything ok.

Also, I've found out, that file /etc/pam.d/common-password can contains "max=N" string, where N - number of significant chars of password; but in intrepid, as in hardy, there is no such string.

Please, someone, just try to reproduce this and add some feedback here; I just would like to know does anybody else have this issue.

[Jamie Strandboge (jdstrand)]

gnome-system-tools is not. Confirmed that adding a user with "verylongpassword" allows login with "verylong"

adduser is not affected.

[Jamie Strandboge (jdstrand)]

Last comment should have read:
gnome-system-tools/system-tools-backend is affected. Confirmed that adding a user with "verylongpassword" allows login with "verylong".

[Martin Pitt (pitti)]

I guess the reason is that g-s-t still uses 3des/md5 passwords, while adduser now defaults to using sha256 passwords.

[Kees Cook (kees)]

system-tools-backends is scanning PAM configs specifically for the word "md5". Since we switched to "sha512", it falls back to 3DES. See bug 51551 for more details.

[James Westby (james-w)]

Hi,

Here is a suggested patch for Intrepid.

It makes system-tools-backends use md5 if the system uses a sha
for passwords. While not ideal it is at least better than 3DES.

For Jaunty we need to improve this somehow so that sha512 is used.

Thanks,

James

[Kees Cook (kees)]

Published: http://www.ubuntu.com/usn/usn-663-1

[Milan Bouchet-Valat (nalimilan)]

James, any news on that front? Should the fix go upstream? Should it be improved?

[James Westby (james-w)]

Hi Milan,

This would be good to take upstream at minimum. Moving
away from a binary MD5/3DES choice would be better. Moving
to PAM would be better still, as you get this for free and there
is no danger of it getting out of date again and causing a similar
issue.

Thanks,

James

[Milan Bouchet-Valat (nalimilan)]

I don't really understand how it's working currently. Is Ubuntu using SHA? If so, is liboobs writing MD5 passwords to /etc/shadow?

We should at least support SHA as well as MD5. I plan to make a release before Karmic so that a few bugfixes go into it. Do you think you could improve the patch before that?

Using PAM is of course much cleaner and logical, but we need to find a way to send the clear password to the backends, and that won't be done before Karmic. An intermediate fix would be Kees's patch [1] to use chpasswd, but upstreaming it is difficult since we have to be sure chpasswd is present, or use the stb for that. So maybe it would be worth fixing the problem once for all using PAM, instead of spending time on temporary fixes.

We have a ready-to-use perl code if we want to use PAM in the stb at [2]. But before that we need to send the clear password...

1: http://launchpadlibrarian.net/19941588/liboobs_2.22.0-1ubuntu1.debdiff (bug 51551)
2: http://nik.pelov.name/files/Authen/PAM/FAQ.html#2__can_i_change_a_password_non_interactively

[Kees Cook (kees)]

On Wed, Sep 02, 2009 at 05:56:58PM -0000, Milan Bouchet-Valat wrote:
> I don't really understand how it's working currently. Is Ubuntu using
> SHA? If so, is liboobs writing MD5 passwords to /etc/shadow?

The current patches in Ubuntu use chpasswd to determine the hashing (i.e.
it is not something stb should have knowledge of).

But, as you say, that requires a patched chpasswd, so it's totally
unacceptable for upstreaming. :(

[James Westby (james-w)]

On Wed Sep 02 17:56:58 UTC 2009 Milan Bouchet-Valat wrote:
> I don't really understand how it's working currently. Is Ubuntu using
> SHA? If so, is liboobs writing MD5 passwords to /etc/shadow?

That's what the patch in this bug does. Kees implemented a better
solution for us which gave us encryption of the same strength as
default.

Writing MD5 is better than 3DES, but should still be avoided.

> We should at least support SHA as well as MD5. I plan to make a release
> before Karmic so that a few bugfixes go into it. Do you think you could
> improve the patch before that?

Well, the patch is fine as far as it goes. The main thing to add would
be SHA support.

I would like to see the default be for the strongest that stb knows
about, so that when the switch is made next time the unkown scheme
translates to SHA512 being used, rather than 3DES again.

> Using PAM is of course much cleaner and logical, but we need to find a
> way to send the clear password to the backends, and that won't be done
> before Karmic. An intermediate fix would be Kees's patch [1] to use
> chpasswd, but upstreaming it is difficult since we have to be sure
> chpasswd is present, or use the stb for that. So maybe it would be worth
> fixing the problem once for all using PAM, instead of spending time on
> temporary fixes.

I think that would be good, but as you say it's not straightforward.

Creating the pipe and passing the password over isn't too much work. I
think it will require changing the D-Bus interface though.

Thanks,

James