experchange > programmer

blt_g29avo (12-05-18, 04:41 PM)
Its been a while since I've used these API functions so I'm probably a bit
behind the times, but does anyone know how to get the encrypted user password
on a modern Linux and OS/X system? This test program:

#include <stdio.h>
#include <unistd.h>
#include <pwd.h>

int main()
{
struct passwd *pwd;
pwd = getpwuid(getuid());
printf("%s\n",pwd->pw_passwd);
return 0;
}

just returns 'x' on linux and '******' on OSX. Obviously it doesn't read the
shadow password file on linux or the plist file on OSX. Anyone know what I
need to do in order to get the hash in C?

Thanks
Lew Pitcher (12-05-18, 05:05 PM)
blt_g29avo wrote:

[..]
> just returns 'x' on linux and '******' on OSX. Obviously it doesn't read
> the shadow password file on linux or the plist file on OSX. Anyone know
> what I need to do in order to get the hash in C?


I can't talk to OSX, but the process on a Linux system looks something like
getpwuid()
if pw_passwd is ""
then
# no password was assigned
else
if pw_passwd is "x"
then
# use shadow password
getspnam(pw_name)
# hashed password is sp_pwdp
else
# hashed password is pw_passwd
fi
fi

Note that pw_passwd can have one of three values:
empty, meaning that this user has no password and no shadow password
"x", meaning that this user has a shadow password, and
anything else, meaning that this user has a passwd password only

HTH
Scott Lurndal (12-05-18, 05:08 PM)
blt_g29avo writes:
[..]
>shadow password file on linux or the plist file on OSX. Anyone know what I
>need to do in order to get the hash in C?
>Thanks


$ man -k shadow
ndspent [getspnam] (3) - get shadow password file entry
fgetspent [getspnam] (3) - get shadow password file entry
fgetspent_r [getspnam] (3) - get shadow password file entry
getspent [getspnam] (3) - get shadow password file entry
getspent_r [getspnam] (3) - get shadow password file entry
getspnam (3) - get shadow password file entry
getspnam [shadow] (3) - encrypted password file routines

Note that you must be root to read the shadow file.
Lew Pitcher (12-05-18, 05:12 PM)
Lew Pitcher wrote:

[..]
> empty, meaning that this user has no password and no shadow password
> "x", meaning that this user has a shadow password, and
> anything else, meaning that this user has a passwd password only


Note also that the sp_pwdp can have one of many values
From shadow(5)
Refer to crypt(3) for details on how this string is interpreted.

If the password field contains some string that is not a valid
result of crypt(3), for instance ! or *, the user will not be able
to use a unix password to log in (but the user may log in the
system by other means).

This field may be empty, in which case no passwords are required to
authenticate as the specified login name. However, some
applications which read the /etc/shadow file may decide not to
permit any access at all if the password field is empty.

A password field which starts with a exclamation mark means that
the password is locked. The remaining characters on the line
represent the password field before the password was locked.

HTH
Rainer Weikusat (12-05-18, 05:27 PM)
blt_g29avo writes:
[..]
> return 0;
> }
> just returns 'x' on linux and '******' on OSX.


On Linux, you'll probably need to access the shadow password file
(/etc/shadow).

-----
#include <stdio.h>
#include <unistd.h>
#include <pwd.h>
#include <shadow.h>

int main()
{
struct passwd *pwd;
struct spwd *spwd;

pwd = getpwuid(getuid());
spwd = getspnam(pwd->pw_name);
printf("%s\n",spwd->sp_pwdp);
return 0;
}
------

If this is compiled and the exectuable owned by root and the setuid bit
is enabled, it'll print the encrypted password of the user invoking it.
(=> getspent(3)).
blt_s6t8mf (12-05-18, 05:43 PM)
On Wed, 05 Dec 2018 10:05:45 -0500
Lew Pitcher <lew.pitcher> wrote:
[..]
> empty, meaning that this user has no password and no shadow password
> "x", meaning that this user has a shadow password, and
> anything else, meaning that this user has a passwd password only


Thanks.
Jorgen Grahn (12-06-18, 01:40 AM)
On Wed, 2018-12-05, blt_g29avo wrote:
> Its been a while since I've used these API functions so I'm probably a bit
> behind the times, but does anyone know how to get the encrypted user password
> on a modern Linux and OS/X system?


Just because I'm curious: why do you want to do this? I always
figured very few programs needed to read this data, and that they had
been written already.

/Jorgen
Joe Pfeiffer (12-06-18, 04:02 AM)
blt_g29avo writes:

[..]
> just returns 'x' on linux and '******' on OSX. Obviously it doesn't read the
> shadow password file on linux or the plist file on OSX. Anyone know what I
> need to do in order to get the hash in C?


This is one of those questions for which my immediate response is to ask
what you're really trying to do. If you're wanting to do an
old-fashioned user authentication by comparing the hashed password from
a user against the one stored on disk, I suggest you look into pluggable
authentication modules.

blt_Ze612z (12-06-18, 01:00 PM)
On 5 Dec 2018 23:40:27 GMT
Jorgen Grahn <grahn+nntp> wrote:
>On Wed, 2018-12-05, blt_g29avo wrote:
>Just because I'm curious: why do you want to do this? I always
>figured very few programs needed to read this data, and that they had
>been written already.


Why do people always ask this question?
blt_mr (12-06-18, 01:02 PM)
On Wed, 05 Dec 2018 19:02:55 -0700
Joe Pfeiffer <pfeiffer> wrote:
>blt_g29avo writes:
>This is one of those questions for which my immediate response is to ask
>what you're really trying to do. If you're wanting to do an


*sigh*

>old-fashioned user authentication by comparing the hashed password from
>a user against the one stored on disk, I suggest you look into pluggable
>authentication modules.
>


Not much use on OS/X or BSD. This needs to be as portable and as simple as
possible. I'm not interested in adding complexity for its own sake.
Kenny McCormack (12-06-18, 03:14 PM)
In article <puavfg$1pc9$1>,
<blt_Ze612z> wrote:
>On 5 Dec 2018 23:40:27 GMT
>Jorgen Grahn <grahn+nntp> wrote:
>Why do people always ask this question?


1) Because this is Usenet and it's what they do.

2) It is both natural and very rude to want to know what the real, underlying
problem is - i.e., what problem are we really trying to solve?

3) I run into this frequently in my threads; I just learn to ignore it.
I suggest you do likewise.

P.S. Note that this is a behavioral variant of the so-called "X-Y problem".
blt_9hQ3@bsay_rijiyslyzr8ff.net (12-06-18, 03:44 PM)
On Thu, 6 Dec 2018 13:14:17 -0000 (UTC)
gazelle (Kenny McCormack) wrote:
>In article <puavfgpc9>,
> <blt_Ze612z> wrote:
>1) Because this is Usenet and it's what they do.


True.

>2) It is both natural and very rude to want to know what the real, underlying
> problem is - i.e., what problem are we really trying to solve?


The thing that irritates me is that they never answer the actual question. Its
as if they'll decide whether my reason for needing it is good enough for them
to make the effort to answer. You know what - if you don't want to answer then
just don't bother. Simple.

>P.S. Note that this is a behavioral variant of the so-called "X-Y problem".


Not heard of that. Quite interesting.
Jorgen Grahn (12-06-18, 05:22 PM)
On Thu, 2018-12-06, blt_Ze612z wrote:
> On 5 Dec 2018 23:40:27 GMT
> Jorgen Grahn <grahn+nntp> wrote:
> Why do people always ask this question?


In this case, to learn something. It wasn't a malicious question (even
though "just because I'm curious" is often code for "just because I
want to make fun of someone").

/Jorgen
Scott Lurndal (12-06-18, 05:25 PM)
Jorgen Grahn <grahn+nntp> writes:
>On Thu, 2018-12-06, blt_Ze612z wrote:
>In this case, to learn something. It wasn't a malicious question (even
>though "just because I'm curious" is often code for "just because I
>want to make fun of someone").


In other cases, to offer alternative suggestions (e.g. pam). I'd look
leary on anyone asking how to obtain the shadow password, as there are
very, very, very few legitimate reasons so-to-do.
Kaz Kylheku (12-06-18, 05:44 PM)
On 2018-12-06, blt_Ze612z <blt_Ze612z> wrote:
> On 5 Dec 2018 23:40:27 GMT
> Jorgen Grahn <grahn+nntp> wrote:
> Why do people always ask this question?


Because people insist that they must solve problem X, when really
what their boss assigned to them was to solve problem Y, toward
which X is one of multiple possible stepping stones.

Programs should not be reading the shadow file. Doing so requires root
privileges, which most programs should not need.

If the goal is to authenticate passwords, some appropriate API should
be used rather than access to shadow files. It's not 1979 any more.

Raw access to shadow files breaks system policies. What if there are
additional sources for authentication like LDAP and whatnot? What if
there are multi-factor authentication methods in place? Are you going
to clone all that in your own reimplementation of authentication?

Similar Threads