There's been some discussion of security related to passwords and I wanted to start a root node to discuss this more thoroughly. mdillon pointed out that Lesson 4, part 2 of my CGI course gets some of the details wrong regarding using an MD5 digest. The main problem with this seems to be that I'm not truly using the crypt capabilities of MD5. Thus, a cracker will find my digests easier to crack than using a proper crypt function such as Crypt::PasswdMD5 (merely because they are faster and easier to crack, if the constant is known).

A proper MD5 crypt string will resemble the following:

$1$1PUXLuZE$P.LfclRO9SKqTf2BQK.yD1

The 1PUXLuZE is the salt, so any cracker grabbing the password file now has the salt for every password. I asked why this is done, since this appears to merely be a convenient way of managing the salts, yet decreases security since with a properly random salt, finding the password will be considerably difficult.

In reply to one of my nodes regarding security, thraxil: wrote:

if the salt were secret, how would you ever check the user's password?

My point is that if the salt is separated from the password, security would be increased because, in theory, you would need both pieces the validate the passwords. Thus, including the salt with the password will decrease security because the cracker then has the salt.

After considering this, I understand the benefit of the salt, particularly in avoiding collisions (and I hadn't understood that until mdillon provided the link -- I love this place :), but I still don't see why it's included. If a cracker can gain access to the digests, he or she can try to crack them at leisure. The downside of separating the salt and passwords is that salt management is considerably more complicated.

I have been using a single, static salt (well, a constant appended to the passwords) for security on some of my work and am wondering if this weaker than the traditional method. The salt is tucked away in a config file and the password digests are in a totally separate database. Thus, gaining access one of these is useless to an attacker.

Are there any security systems that manage the salts separate from the passwords? Are they considered too impractical (e.g., if they're both in a filesystem, they might as well be in the same file - if they're on separate servers, you're at the mercy of your network connections).

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.


In reply to Too Convenient Security? by Ovid

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.