experchange > slackware

root (11-08-18, 09:18 PM)
One of my machines doesn't ask for a password at login. There
is a password set by passwd, and the /etc/shadow file shows
a password. The inittab file contains these lines:
# These are the standard console login getties in multiuser mode:
c1:12345:respawn:/sbin/agetty 38400 tty1 linux --noclear
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

Logging in directly with the keyboard attached to the
machine (not ssh in) I get a prompt immediately after
entering root as the user. I have tried a number
of things short of re-installing the whole system.

Any suggestions about what might cause this?

Thanks.
Eef Hartman (11-08-18, 10:13 PM)
root <NoEMail> wrote:
> Logging in directly with the keyboard attached to the
> machine (not ssh in) I get a prompt immediately after
> entering root as the user. I have tried a number


Normally you shouldn't login directly as root, but you still should
get a prompt for a password IF root has got one.

> Any suggestions about what might cause this?


Show us the whole line for root from the /etc/shadow file.
From the man page:
> The password field may be empty, in which case no passwords
> are required to authenticate as the specified login name.

but normally the line should have (at least) the first 3 fields filled
with: root as the first (user name), the encrypted passwd (preceded by
an indicator WHICH type of encryption is used:
> ID | Method
> -----------------------------------------
> 1 | MD5
> 2a | Blowfish (not in mainline glibc;
> added in some Linux distributions)
> 5 | SHA-256 (since glibc 2.7)
> 6 | SHA-512 (since glibc 2.7)

These indicators are preceded and followed by a $) as second field and
the date last changed (in days since 1970) as the third.
And there should be at least 6 : chars in the rest of the line (so 5
more fields). They all may be empty, though.
root (11-08-18, 10:19 PM)
Eef Hartman <E.J.M.Hartman> wrote:
> root <NoEMail> wrote:
> Normally you shouldn't login directly as root, but you still should
> get a prompt for a password IF root has got one.
> Show us the whole line for root from the /etc/shadow file.


From /etc/shadow:
root:$5$Pi4/P/3TyY$3VMxhsS0HpQYL24fBjJqL3cVN22qs/D3gtoUsqnUkH5:17818:0:::::
Lew Pitcher (11-08-18, 10:33 PM)
Eef Hartman wrote:

> root <NoEMail> wrote:
> Normally you shouldn't login directly as root, but you still should
> get a prompt for a password IF root has got one.
> Show us the whole line for root from the /etc/shadow file.


And, the line for root from /etc/passwd
From the passwd(5) man page:
If the password field is a lower-case "x", then the encrypted password is
actually stored in the shadow(5) file instead; there must be a
corresponding line in the /etc/shadow file, or else the user account is
invalid.
[snip]
Eef Hartman (11-08-18, 10:46 PM)
root <NoEMail> wrote:
> From /etc/shadow:
> root:$5$Pi4/P/3TyY$3VMxhsS0HpQYL24fBjJqL3cVN22qs/D3gtoUsqnUkH5:17818:0:::::


That looks perfectly ok, encryption, salt and password present.

So as Lew already suggested: make sure the 2nd field in /etc/passwd
for root is NOT empty (but filled with an x).
From the man page for the /etc/passwd file:
> The encrypted password field may be blank, in which case no
> password is required to authenticate as the specified login name.


This field is a leftover from the days before the shadow file was
introduced and the (encrypted) password was stored directly IN the
/etc/passwd file. The x means: look for this field in /etc/shadow:
> If the password field is a lower-case ???x???, then the encrypted
> password is actually stored in the shadow(5) file instead;
> there must be a corresponding line in the /etc/shadow file,
> or else the user account is invalid.


You _do_ have the corresponding file (and line in it) so make sure
login will be actually looking for it in there.
root (11-08-18, 10:58 PM)
Eef Hartman <E.J.M.Hartman> wrote:
> root <NoEMail> wrote:
> That looks perfectly ok, encryption, salt and password present.
> So as Lew already suggested: make sure the 2nd field in /etc/passwd
> This field is a leftover from the days before the shadow file was
> introduced and the (encrypted) password was stored directly IN the
> /etc/passwd file. The x means: look for this field in /etc/shadow:


Yes, that was it. The /etc/passwd had a null second field.

Thanks.
root (11-08-18, 10:59 PM)
Lew Pitcher <lew.pitcher> wrote:
> Eef Hartman wrote:
> And, the line for root from /etc/passwd
> From the passwd(5) man page:
> If the password field is a lower-case "x", then the encrypted password is
> actually stored in the shadow(5) file instead; there must be a
> corresponding line in the /etc/shadow file, or else the user account is
> invalid.
> [snip]


/etc/passwd file had a null second entry. Thanks
Henrik Carlqvist (11-08-18, 11:32 PM)
On Thu, 08 Nov 2018 20:58:37 +0000, root wrote:
> Yes, that was it. The /etc/passwd had a null second field.


Good problem was solved! If you are only slightly paranoid you might now
want to change your root password unless you somehow altered the
encrypted password string in /etc/shadow before publishing it.

Even though the password is stored with a one-way encryption it is still
possible with brute force to test passwords against the encrypted string
until a working password is found. If someone does that they will have
the root password to your system unless you change the password before
the time it takes the brute force algorith to find the password.

As was noted in this thread and has been said before, it is also best
practice not to log in directly as root but to do your everyday work as a
normal user and only su in a shell when you need to do administrative
tasks.

regards Henrik
Eef Hartman (11-09-18, 12:12 AM)
root <NoEMail> wrote:
> Yes, that was it. The /etc/passwd had a null second field.


Now you should, if you haven't done this before, create a "normal
user". Always working as root is very much discouraged, it's too easy
to really scr*w up your system as root. Especially in GUI mode.
Eef Hartman (11-09-18, 12:18 AM)
Henrik Carlqvist <Henrik.Carlqvist> wrote:
> Even though the password is stored with a one-way encryption it is still
> possible with brute force to test passwords against the encrypted string
> until a working password is found.


But not easy with a sha256 one (it started with $5$).

It _was_ possible with DES and even with MD5, that's why those
encryptions normally aren't used anymore. But even with those you
would need something close to a super-computer (or a massive parallel
one). If the password has been chosen right, of course.

But then again, changing the root password won't hurt.

To the OP: you can change it very easily with the command:
passwd root
(logged in as root, of course).
Rich (11-09-18, 05:43 AM)
Eef Hartman <E.J.M.Hartman> wrote:
> Henrik Carlqvist <Henrik.Carlqvist> wrote:
>> Even though the password is stored with a one-way encryption it is still
>> possible with brute force to test passwords against the encrypted string
>> until a working password is found.

> But not easy with a sha256 one (it started with $5$).


Yeah, looks like he's safe (by accident).



A 4 GPU rig.

Hashtype: sha256crypt, SHA256(Unix)
Speed.Dev.#*.....: 1119.1 kH/s

(Using bc):
(95^8)/1119100/60/60/24/365
187

187 years to brute force all 95 printable ascii characters for an 8
character password.

> It _was_ possible with DES and even with MD5, that's why those
> encryptions normally aren't used anymore. But even with those you
> would need something close to a super-computer (or a massive parallel
> one). If the password has been chosen right, of course.


Well, yes, but "super-computer (or a massive parallel one)" today just
means "GPU rig" (from the same url as above):

Hashtype: descrypt, DES(Unix), Traditional DES
Speed.Dev.#*.....: 2693.9 MH/s

(95^8)/2693900000/60/60/24
28

Twenty eight days to brute force an 8 char. crypt() password.

Hashtype: md5crypt, MD5(Unix), FreeBSD MD5, Cisco-IOS MD5
Speed.Dev.#*.....: 30373.0 kH/s

(95^8)/30373000/60/60/24/365
6

Six years for md5crypt (mostly secure, but not as good as sha256crypt).

And adding more GPU's increases the performance, so the final speed is
really dependent upon "how much money ya got to spend?"
jjge (11-09-18, 08:53 AM)
On 11/8/18 10:32 PM, Henrik Carlqvist wrote:
> On Thu, 08 Nov 2018 20:58:37 +0000, root wrote:
> Good problem was solved! If you are only slightly paranoid you might now
> want to change your root password unless you somehow altered the
> encrypted password string in /etc/shadow before publishing it.
> Even though the password is stored with a one-way encryption it is still
> possible with brute force to test passwords against the encrypted string
> until a working password is found. If someone does that they will have
> the root password to your system unless you change the password before
> the time it takes the brute force algorith to find the password.


Worse yet, a dictionary attack remains possible, and feasible.
[..]
Richard Kettlewell (11-09-18, 11:12 AM)
Rich <rich> writes:
[...]
> Six years for md5crypt (mostly secure, but not as good as sha256crypt).
> And adding more GPU's increases the performance, so the final speed is
> really dependent upon "how much money ya got to spend?"


Yes; but for small number of passwords, the attacker doesn’t spend it on
buying equipment, they spend it on renting GPU instances on AWS (or
similar). IMO the best measure of password strength at the moment is the
dollar value required to crack it using a cloud computing service,
rather than the elapsed time on any given piece of equipment.
Rich (11-09-18, 06:00 PM)
jjge <jjge> wrote:
> On 11/8/18 10:32 PM, Henrik Carlqvist wrote:
> Worse yet, a dictionary attack remains possible, and feasible.


Well, this statement in the grandparent:

"with brute force to test passwords against the encrypted string
until a working password is found"

Is the definition of a "dictionary attack".
jjge (11-09-18, 07:25 PM)
On 11/9/18 5:00 PM, Rich wrote:
> jjge <jjge> wrote:
> Well, this statement in the grandparent:
> "with brute force to test passwords against the encrypted string
> until a working password is found"
> Is the definition of a "dictionary attack".


Not entirely. It also involves a dictionary, or several dictionaries,
which considerably reduces the search space. That is what makes a
dictionary attack feasible (say a few hundred of million tries, against
the supposed zillions for a real brute force attack)

Similar Threads