Re: password hash in shadow file
On 13/03/18 09:47 AM, to...@tuxteam.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Mar 13, 2018 at 05:25:18PM +0100, Sven Hartge wrote: Adam Weremczuk wrote: I think it was me invoking "passwd" as root and aborting (ctrl+D) without making any changes. Would that be enough to update the shadow file? No. You can't reverse a hash and to generate a new hash the code needs the password for the user in plain. Well, to be fair, the change to SHA-1 is because you can "reverse" MD5 all too easily (where reverse just means that you find something which hashes to a given hash, which hasn't to resemble your original password all too much). Usually you want this something to have some properties to be useful. But I don't think your operating system is going to do that behind your back ;-) Not if it's Linux, anyway... -- cgi...@surfnaked.ca (Charlie Gibbs)
Re: password hash in shadow file
On 14/03/18 09:20, to...@tuxteam.de wrote: > On Tue, Mar 13, 2018 at 07:36:19PM +0100, Sven Hartge wrote: > >> But on that note: I wonder of one could create a PAM module which will >> do just that on successful login. Once you *know* you have the right >> password (and the PAM system has that knowledge including the plain text >> password the user entered) just rehash it and update /etc/shadow. > >> This will gradually upgrade all hashes once a user uses an account. > > That would be downright sneaky :-) That's quite common for web apps, isn't it? Not with PAM though, presumably. Richard signature.asc Description: OpenPGP digital signature
Re: password hash in shadow file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Mar 13, 2018 at 07:36:19PM +0100, Sven Hartge wrote: > to...@tuxteam.de wrote: [...] > > Well, to be fair, the change to SHA-1 is because you can "reverse" MD5 > > all too easily > > Yes, basically. > > > But I don't think your operating system is going to do that behind > > your back ;-) > > It would be quite obvious when just starting "passwd" takes several days > while it cracks your MD5 hash to replace it with a stronger one ;) And possibly eat through a disk or two (or are rainbow tables superfluous with current GPUs? I don't know). All that to choose quite probably a *different* password which happens to hash to the same MD5. Login no more possible, but now secure :) > But on that note: I wonder of one could create a PAM module which will > do just that on successful login. Once you *know* you have the right > password (and the PAM system has that knowledge including the plain text > password the user entered) just rehash it and update /etc/shadow. > > This will gradually upgrade all hashes once a user uses an account. That would be downright sneaky :-) Cheers - -- t -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlqoMoMACgkQBcgs9XrR2kb5/ACfQEmIaxjx3bVzcA60VHbqI/UD RbIAnifsG3fys+yUrfGLZ8PojwkZBwG1 =Xy4V -END PGP SIGNATURE-
Re: password hash in shadow file
to...@tuxteam.de wrote: > On Tue, Mar 13, 2018 at 05:25:18PM +0100, Sven Hartge wrote: >> Adam Weremczuk wrote: >>> I think it was me invoking "passwd" as root and aborting (ctrl+D) >>> without making any changes. Would that be enough to update the >>> shadow file? >> No. >> >> You can't reverse a hash and to generate a new hash the code needs >> the password for the user in plain. > Well, to be fair, the change to SHA-1 is because you can "reverse" MD5 > all too easily Yes, basically. > But I don't think your operating system is going to do that behind > your back ;-) It would be quite obvious when just starting "passwd" takes several days while it cracks your MD5 hash to replace it with a stronger one ;) But on that note: I wonder of one could create a PAM module which will do just that on successful login. Once you *know* you have the right password (and the PAM system has that knowledge including the plain text password the user entered) just rehash it and update /etc/shadow. This will gradually upgrade all hashes once a user uses an account. S° -- Sigmentation fault. Core dumped.
Re: password hash in shadow file
On Tue 13 Mar 2018 at 15:18:35 (+), Adam Weremczuk wrote: > Hi all, > > I've just spotted that on one of my old wheezy servers root entry in > /etc/shadow was updated just over 3 weeks ago. Take a look at the end of a file and see if a new user/system account has been added recently when you installed a package. Examples: clamav logcheck avahi ntop and even debian-security-support. If that doesn't turn up anything, just scan for the highest number in the 3rd field. Then type (where 16933 is your number): $ date -d "1970-01-01 +16933 days" Thu May 12 00:00:00 CDT 2016 $ and that ought to match the last-modified timestamp. (That example is for debian-security-support going onto one of my wheezy systems.) > The root password is still the same and the lastchanged count is > much higher than 3 weeks. > > The difference I've noticed is the hashed password string being much longer. > > It's now prefixed with $6$ (SHA-512 algorithm) comparing with $1$ > (MD5) before the change. Should we assume that you have evidence of the root entry with an MD5 indication but the same number in the 3rd entry as you have now? > My first suspect was a security patch but the system was not updated > around that time. > > Has anybody seen this before and could explain? No. Lacking a backup of shadow with an MD5 indication, all I can say is that the same process must have been carried out here on all my systems, and whatever that process was, it happened before 12 Sep 2016. Doesn't seem likely. That's the last time this backup wheezy system was booted up, and shadow shows file last modification 21 April 2014 birth of root password 3 April 2014 shadow root entry: root:$6$…:16163:0:9:7::: shadow last entry: apt-cacher-ng:*:16182:0:9:7::: Cheers, David.
Re: password hash in shadow file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Mar 13, 2018 at 05:25:18PM +0100, Sven Hartge wrote: > Adam Weremczuk wrote: > > > I think it was me invoking "passwd" as root and aborting (ctrl+D) > > without making any changes. Would that be enough to update the shadow > > file? > > No. > > You can't reverse a hash and to generate a new hash the code needs the > password for the user in plain. Well, to be fair, the change to SHA-1 is because you can "reverse" MD5 all too easily (where reverse just means that you find something which hashes to a given hash, which hasn't to resemble your original password all too much). Usually you want this something to have some properties to be useful. But I don't think your operating system is going to do that behind your back ;-) Cheers - -- t -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlqoALIACgkQBcgs9XrR2kYGwwCfR0bt4g4nomrycYho2rA23L6d BlUAn2c3RW8xuj751aC6LxJt+0T9udPT =SGi/ -END PGP SIGNATURE-
Re: password hash in shadow file
Quite possibly I changed it to the same password. Not sure now as it was almost a month ago but can't find any better explanation. Of course hashes are meant to be irreversible. I guess I'm trying to catch my own shadow ;) On 13/03/18 16:19, to...@tuxteam.de wrote: Still strange. Are you sure that you stopped "passwd" early enough? Had you entered the password already? Twice?
Re: password hash in shadow file
Adam Weremczuk wrote: > I think it was me invoking "passwd" as root and aborting (ctrl+D) > without making any changes. Would that be enough to update the shadow > file? No. You can't reverse a hash and to generate a new hash the code needs the password for the user in plain. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: password hash in shadow file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Mar 13, 2018 at 04:01:52PM +, Adam Weremczuk wrote: > I think it was me invoking "passwd" as root and aborting (ctrl+D) > without making any changes. > Would that be enough to update the shadow file? Hm. That depends on which point you invoked abort at, but naively I'd say "no". Note that the system doesn't "know" your password, only its hash -- so if it succeeded in storing the SHA-1 of your password (you say it didn't change, did you?) without you telling it, then it would have to crack your MD5 password hash. Still strange. Are you sure that you stopped "passwd" early enough? Had you entered the password already? Twice? Cheers - -- t -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlqn+f4ACgkQBcgs9XrR2kYu2ACePqhJ8m5QgIqwleJBpHFPo0Ng x6sAnRpH4q2J9UqbT7aypggmxFLaIhjH =qwpf -END PGP SIGNATURE-
Re: password hash in shadow file
I think it was me invoking "passwd" as root and aborting (ctrl+D) without making any changes. Would that be enough to update the shadow file? On 13/03/18 15:47, to...@tuxteam.de wrote: What I don't understand is how the system changed the hashing method without getting you involved. You don't remember having had to enter the root password? That would be strange. Cheers
Re: password hash in shadow file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Mar 13, 2018 at 03:18:35PM +, Adam Weremczuk wrote: > Hi all, > > I've just spotted that on one of my old wheezy servers root entry in > /etc/shadow was updated just over 3 weeks ago. > > The root password is still the same and the lastchanged count is > much higher than 3 weeks. > > The difference I've noticed is the hashed password string being much longer. > > It's now prefixed with $6$ (SHA-512 algorithm) comparing with $1$ > (MD5) before the change. Of course, moving off MD5 makes some sense. It's not burning a hole in your system's security in this case [1], but MD5 is a bit old these days. > My first suspect was a security patch but the system was not updated > around that time. > > Has anybody seen this before and could explain? What I don't understand is how the system changed the hashing method without getting you involved. You don't remember having had to enter the root password? That would be strange. Cheers [1] /etc/shadow isn't world-readable, so if you have someone on your system capable of reading it, you're already in hot water; and if you have copies of /etc/shadow around there, well... you encrypt your system backups, do you? The only credible threat model remaining is that someone(TM) accesses your hard disk "from the side", e.g. booting a rescue system or taking to the screwdriver. - -- t -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlqn8p4ACgkQBcgs9XrR2kb5DgCfSBtg2Ew8O/eHhXKV4iMEit5e 8esAniqGwtu0lYjdRGUSlAhnTwgM08Q/ =rLBv -END PGP SIGNATURE-
