Mailing List Archive: PAM/passwd? and hash tables

PAM/passwd? and hash tables

Nov 15, 2005, 6:03 AM

Post #1 of 6 (3693 views)

Hi

I read the following artivle
http://www.securityfocus.com/news/11355/2
which has prompted me to reconsider my security setup, it is a home
system but with open ssh ports and similar.
My specific question is this - What method/cryptography is used to
create the passwd hash under PAM ie. is it vunerable to rainbow type
hash tables.
-----snip---- ^^ article
RainbowCrack Online will offer 11 tables covering six different hash
algorithms, including LanMan, MD5, MySQL 323, and SHA-1
-----snip-----

now that said it is quite possible that I have got the wrong end of
the stick so to speak, ie. I know that PAM handles login etc but is it
PAM that generates the hash of my chosen password?
If so can I expand my question to ask what program and further what
algorithm is used to do this task.
This is for my system of course but I guess the principle can be
applied to many systems.

EDIT
As I was writing this I checked man passwd which seems to have
answered my question on the whole
---snip---
The UNIX System encryption
method is based on the NBS DES algorithm and is very secure.
---snip---

I have left my earlier question [more or less answered] just for some
confirmation, but the new point is -
Does the "NBS DES algorithm" come under the "salt" method? and is it
therefore immune to attacks of the hash table variety?

regards

stuart

ps. I know the above is a little disjointed but I am stumbling in the
dark a little here.

--
"There are 10 types of people in this world: those who understand
binary, those who don't"

--Unknown

--
gentoo-security@gentoo.org mailing list

Re: PAM/passwd? and hash tables [ In reply to ]

gentoo-security at ml

Nov 15, 2005, 6:35 AM

Post #2 of 6 (3608 views)

Permalink

* Stuart Howard | 2005-11-15 13:03:48 [+0000]:

>Hi
Hi,

>My specific question is this - What method/cryptography is used to
>create the passwd hash under PAM ie. is it vunerable to rainbow type
>hash tables.
MD5 or SHA1 with "salt" and therefore it is _not_.

>PAM that generates the hash of my chosen password?
Almost. It is done by one of pam's module. Look in /etc/pam.d

>Does the "NBS DES algorithm" come under the "salt" method? and is it
The salt method is not algorithm specific. Emerge john and let it run on
your local passwords and you will know what it is :)
As far I remember the DES version was with salt, too (I have no clue
what NBS stands for).

>regards
>
>stuart
--
regards
Sebastian Siewior
--
gentoo-security@gentoo.org mailing list

Re: PAM/passwd? and hash tables [ In reply to ]

christophe at garault

Nov 15, 2005, 7:17 AM

Post #3 of 6 (3609 views)

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart Howard wrote :

>What method/cryptography is used to
>create the passwd hash under PAM ie. is it vunerable to rainbow type
>hash tables.

As I've spend some time to try understanding this by looking at the
source code, I think I can give you some tips.
Fisrt of all, have a look at your /etc/shadow where the encrypted
password is.
For example:
fabienne:$1$/oZtuVKk$dIY/JnsPaMF47Ai9SgacZ.:12789:0:99999:7:::

Fields are separated by a semicolon. So in the first one you have the
username, and in the second one there is the encrypted password but
this field is again separated in three new fields by a $ sign. So the
first one (1 in this case) is the encryption algorithm used (I'll have
to dive again in pam's sources to remember which number belongs to
wich encryption scheme). The second fields (/oZtuVKk) is the salt, and
the last one (dIY/JnsPaMF47Ai9SgacZ.) is the result of the encrypted
passwd+salt.

If you're interested to know more, I think I've allready posted a few
things some months agao, so I could try to search in my old mails if
you want to.

Have a nice day.
- --
Christophe Garault

ps: if someone tries to connect with this account, I'll ban him
forever... ;)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFDee37J5Nh3YMYAQsRAscjAJ4sQDFgx2XRb88gSGIWMKYEZCVNCQCfZNcz
cbfgQHdbBHP++E6K94hXXPA=
=eOVZ
-----END PGP SIGNATURE-----

--
gentoo-security@gentoo.org mailing list

Re: PAM/passwd? and hash tables [ In reply to ]

stian at nixia

Nov 15, 2005, 8:14 AM

Post #4 of 6 (3608 views)

Permalink

> Fields are separated by a semicolon. So in the first one you have the
> username, and in the second one there is the encrypted password but
> this field is again separated in three new fields by a $ sign. So the
> first one (1 in this case) is the encryption algorithm used (I'll have

$1$ meens MD5 (with salt). glibc crypt() function also reflects this. If
the salt format doesn't match $1$xxxxxxx$ format, DES encryption is
assumed, which has a very weak salt.

Stian Skjelstad
--
gentoo-security@gentoo.org mailing list

Re: PAM/passwd? and hash tables [ In reply to ]

stuart.g.howard at gmail

Nov 15, 2005, 12:50 PM

Post #5 of 6 (3612 views)

Permalink

Thanks for the replies

I have done some further reading on the matter and seem to have come
across a paradox of sorts.
What got me intersted was that an article claiming that the hash
tables may be used for "evil " purposes but it was pointed out to me
that without the hash you have no comparison so what use is a hash
table, indeed you would also have had to gain access to the
/etc/shadow file to get the hash and since that requires root
priviledge it would seem you allready have a larger problem than
losing a password to clear text.
Of course I am only thinking of a remote login via 22 as that is what
primarily concerns me at the moment. So in short it seems I am safe
with my system as it is for now.

stu

ps on a side note
NBS DES
National Bureau of Standards Data Encryption Standard
http://www.garykessler.net/library/crypto.html#desmath

On 15/11/05, stian@nixia.no <stian@nixia.no> wrote:
> > Fields are separated by a semicolon. So in the first one you have the
> > username, and in the second one there is the encrypted password but
> > this field is again separated in three new fields by a $ sign. So the
> > first one (1 in this case) is the encryption algorithm used (I'll have
>
> $1$ meens MD5 (with salt). glibc crypt() function also reflects this. If
> the salt format doesn't match $1$xxxxxxx$ format, DES encryption is
> assumed, which has a very weak salt.
>
>
> Stian Skjelstad
> --
> gentoo-security@gentoo.org mailing list
>
>

--
"There are 10 types of people in this world: those who understand
binary, those who don't"

--Unknown

--
gentoo-security@gentoo.org mailing list

Re: PAM/passwd? and hash tables [ In reply to ]

gentoo at embracetherandom

Nov 15, 2005, 7:14 PM

Post #6 of 6 (3632 views)

Permalink

But many vulnerabilities are information disclosure in nature and can
allow for the capture of the shadow file without also allowing for the
creation of a root session. That is part of *why* password cracking, and
hence the hash tables, are a problem. This is the same argument that is
used to declaim the weakness of Windows passwords - because there is no
salt the hash table is small enough that people have claimed the ability
to brute-force the whole table in twelve seconds.

Also, if they can get to some lesser account they can try the hash table
against su or some such, unless you have accounts lock out after too
many bad passwords, etc.

Regards,

Richard M. Conlan

Stuart Howard wrote:
> Thanks for the replies
>
> I have done some further reading on the matter and seem to have come
> across a paradox of sorts.
> What got me intersted was that an article claiming that the hash
> tables may be used for "evil " purposes but it was pointed out to me
> that without the hash you have no comparison so what use is a hash
> table, indeed you would also have had to gain access to the
> /etc/shadow file to get the hash and since that requires root
> priviledge it would seem you allready have a larger problem than
> losing a password to clear text.
> Of course I am only thinking of a remote login via 22 as that is what
> primarily concerns me at the moment. So in short it seems I am safe
> with my system as it is for now.
>
> stu
>
> ps on a side note
> NBS DES
> National Bureau of Standards Data Encryption Standard
> http://www.garykessler.net/library/crypto.html#desmath
>
>
>
> On 15/11/05, stian@nixia.no <stian@nixia.no> wrote:
>
>>>Fields are separated by a semicolon. So in the first one you have the
>>>username, and in the second one there is the encrypted password but
>>>this field is again separated in three new fields by a $ sign. So the
>>>first one (1 in this case) is the encryption algorithm used (I'll have
>>
>>$1$ meens MD5 (with salt). glibc crypt() function also reflects this. If
>>the salt format doesn't match $1$xxxxxxx$ format, DES encryption is
>>assumed, which has a very weak salt.
>>
>>
>>Stian Skjelstad
>>--
>>gentoo-security@gentoo.org mailing list
>>
>>
>
>
>
> --
> "There are 10 types of people in this world: those who understand
> binary, those who don't"
>
> --Unknown
>
--
gentoo-security@gentoo.org mailing list