List Archive: gentoo-security
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
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.
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.
> ps on a side note
> NBS DES
> National Bureau of Standards Data Encryption Standard
> On 15/11/05, stian@... <stian@...> 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.
>>firstname.lastname@example.org mailing list
> "There are 10 types of people in this world: those who understand
> binary, those who don't"
email@example.com mailing list