liveuser password / autologin problem

[jenaniston]

This is on an 8 GB Fedora 13 KDE Live USB (in EOL but this does have many files on it, custom desktop plasma workspace, etc.)

Instead of the usual auto login to the live desktop I boot to the Fedora KDE-type login screen (same as an install version)
the user name "liveuser" is already pre-entered and the space for a password below that . . .

how can I find out what password this now has ?

I can change the user to "root" and login without any password, but this is not the liveuser desktop with files etc. - and a switch user from root isn't allowed either.

So in general, just where is the password stored that I can get to it ?
(as root in runlevel 3 or anything)
I have tried as the password for "liveuser" session various ideas such as root, liveuser, and no password.
I'll try any ideas anybuddy else has.

[jpollard]

Same place as all login passwords. /etc/shadow

Once you get booted, login as root and change it.

[jenaniston]

Originally Posted by jpollard

Same place as all login passwords. /etc/shadow

Once you get booted, login as root and change it.

root@localhost ~]# cd /etc
[root@localhost etc]# ls
...
 shadow    
 shadow-
...
[root@localhost etc]# less shadow
...
liveuser::14734:0:99999:7:::
(END) 
>q
[root@localhost etc]#

Thanks . . . Can /etc/shadow be rendered into a human readable form ? (I used less to read it in terminal - KWrite gave same result)

[jpollard]

That is the human readable form. It is just an ascii file with 8 fields (like the /etc/passwd file). login name, password, last password change, days until change is allowed, days before change required, days before expiration warning, expiration date, and a reserved field.

That should be the empty password. As long as kdm allows empty passwords (none) then it should allow you to login.

Note: I have run across situations that seemed to not count "enter" as the end of the password. In these conditions I have been able to use the "login" button instead.

If you can login as root, one thing you could do is just edit the file - duplicate the line with root, change the first field (login) to "liveuser" and delete the old entry.

[jenaniston]

Originally Posted by jpollard

That is the human readable form. . . .
. . . you could do is just edit the file - duplicate the line with root, change the first field (login) to "liveuser" and delete the old entry.

Well yeah - sorta human readable, but not actually what the human written password is.

But what a clever idea about copying those passwords by changing the field to match the liveuser password as the same as the root password -
Thanks . . . I will try that all later (as I just made a 1 GB live usb Fedora 16 KDE Alpha to experiment with !)

Thanks again for the responses.

[jpollard]

That is an old UNIX trick for logging into a users account without knowing the password. You change the record, login and do your stuff, then put the original back.

The encrypted password is done with a one-way hash+salt. This makes it very difficult to extract (and steal) the actual password even if the cracker manages to get the encrypted password.

Mind, the password is still only as good as the user that creates it. Most cracking programs still brute force the encryption by trying all possibilities and then compare the result with the encrypted password. This is why dictionary attacks work so well.

One of the oldest UNIX hacks I was informally told about happened at the NIST. They operated a PDP-10 system as well as several UNIX systems. The PDP-10 stored the passwords in plaintext in the accounting records (formatted using sixbit characters...). The apparent password leak were done by decoding the passwords used on the PDP-10, and then using them on the UNIX systems where they frequently worked.

I was told this was the likely way when I demonstrated cracking the Universities accounting system when they forgot to restrict the accounting records to a professor who worked for Bureau of Standards (as NIST was called at the time).

Storing passwords in plaintext is not a good idea.