Mailinglist Archive: opensuse-security (601 mails)

< Previous Next >
Re: [suse-security] crypt()
  • From: Yuri Robbers <yuri@xxxxxxxxxxxxxxxxxxxx>
  • Date: Wed, 16 Aug 2000 16:20:29 +0200 (MEST)
  • Message-id: <Pine.LNX.4.21.0008161553020.9130-100000@xxxxxxxxxxxxxxxxxxxx>


On Wed, 16 Aug 2000, Robert Casties wrote:

> I don't understand that. If someone has your password file he can start a
> dictionary attack. Is there any difference encrypting words in crypt or
> MD5 and comparing the result to passwd?
> Wouldn't the centuries apply only to cracking the scrambled value but not
> to a "guessing" approach? Maybe I'm just ignorant.

The numbers I mentioned apply to guessing attacks. Algorithms like
crypt(), are designed to be one-way. It is not (or should not be) possible
to reconsruct the original password from the encrypted password.

The differences between crypt(), MD5, etc. with regard to guessing attacks
are the amount of time needed for one guess, the maximum number of
characters in a password, and the number of possible encrypted passwords.
More time per guess slows down the cracker, but also the login-process for
the bona fide user. A larger number of possible encrypted passwords
increases the search space the cracker needs to cover, and makes it less
feasible to create a database of all possible encrypted passwords, which
would make it possible to crack a password by doing a simple database

The 10th of a second refers to a lookup in a database of all possible
encrypted crypt() passwords (i.e. not only those in a dictionary, but
_all_ possible passwords). In this case the brute force attack needed to
create this database (which would be just under 9 Gb) has been done
beforehand. The couple of days refers to a brute force guessing attack on
one encrypted password. As a matter of fact it would take about 1 month on
a regular Pentium III system to try all possible passwords in crypt().

Using MD5 the time needed per guess increases dramatically, making it less
feasible to launch a brute force guessing attack. Also the total number of
possible encrypted passwords increases many orders of magnitude, making it
(for the time being) impossible to create a database of all possible
encrypted passwords.

The same applies in varying degrees to any other algorithm. The years,
centuries, and many times the estimated lifetime of the universe apply to
guessing attacks on - for example - the eks-Blowfish algorithm.

The solution to this dilemma is choosing a good password algorithm that
can - hopefully - be used for quite some time into the future.

As an aside, the reasons for not choosing a dictionary (or otherwise
easily guessable string) as a password is the fact that it is immensily
quicker to check all dictionary words in a guesisng attack than to check
all possible strings. That's why I tend to have passwords like Ki&G7!0p
on all my accounts, and never the same password on any two accounts. It's
a pain on the memory, but it keeps my data safer.

> Security would of course be enhanced by allowing more than 8 character
> passwords. Last I heard there were still issues with NIS. (Not that
> there's much security left when you use NIS ;-)

Yes. Using longer passwords is an easy way of increasing security. But
there is a limit to the password length user are prepared (or able) to
memorize. And you don't want them to go around writing down their password
on a post-it not that they stick to their screen. The same goes for the
incomprehensible passwords like Ki&G7!0p. The best method I'm aware of is,
using acronyms for passwords. For example "SwAT7D!" which is short for
"Snowwhite and the seven dwarves!".

And well... about all those unsafe protocols that send plaintext passwords
over teh network... they should be outlawed :o)

Use ssh ( instead of telnet, rlogin, etc. Or
implement IPSec...

I hope this helps (and doesn;t bore you to death, being as long-winded as
it is)... :o)


drs. Yuri Robbers phone : +31-71-527-4966
Leiden University fax : +31-71-527-4900
Institute for Theoretical Biology email : robbers@xxxxxxxxxxxxxxxxxxxx
Kaiserstraat 63
2311 GP Leiden PGP 5.0 public key available:
the Netherlands Check your favourite hkp server.

< Previous Next >
Follow Ups