Loading ...
Sorry, an error occurred while loading the content.

SimpleMD5 quibbles

Expand Messages
  • Dave Kristol
    I have finally gotten to play with the SimpleMD5 spec. from Spyglass and John Franks s toolkit. I would like to offer these suggestions. 1) The password that
    Message 1 of 4 , Feb 1, 1995
    • 0 Attachment
      I have finally gotten to play with the SimpleMD5 spec. from Spyglass
      and John Franks's toolkit. I would like to offer these suggestions.

      1) The password that gets MD5-ed by the client must be stored on the
      server as plaintext, so the server can do MD5(nonce password). I find
      that to be a problem, since, at least in my environment, many of the
      servers are on Unix machines with shared file systems, and it would be
      relatively easy for someone to find another's password. I would prefer
      that the password be stored encoded by some function f() (possibly MD5?).
      Then the client would compute MD5(nonce f(passwd)), and the server could
      duplicate the computation, except it would have f(passwd) in its password
      file already.

      2) I've been annoyed in Basic authentication by the fact that what the
      client and server call "realm" is also used as a prompt to the user.
      Can we separate the two concepts in SimpleMD5 (and Basic, for that
      matter) by having the client and server continue to exchange a "realm"
      attribute and have the server pass a "prompt" attribute for the client
      to use? A server that didn't want to do so pass the same value for
      "prompt" as for "realm". A client that didn't see a "prompt" attribute
      could use the value of "realm" as a default.

      3) In the SimpleMD5 spec. (and Franks's program) there's an insistence
      that values (e.g., "PrideRock" in realm="PrideRock") be "-delimited.
      Seems to me this is only necessary when there's an embedded space or
      TAB or comma. How about if we tolerate a non-"-delimited span of
      contiguous characters that has no embedded space, TAB, or comma.
      (Are there other characters of which to beware too?)

      Dave Kristol
    • John Franks
      ... This is a good idea, but it is important to understand that it doesn t really protect you the way you might think. It is still necessary to protect the
      Message 2 of 4 , Feb 1, 1995
      • 0 Attachment
        According to Dave Kristol:
        >
        > I have finally gotten to play with the SimpleMD5 spec. from Spyglass
        > and John Franks's toolkit. I would like to offer these suggestions.
        >
        > 1) The password that gets MD5-ed by the client must be stored on the
        > server as plaintext, so the server can do MD5(nonce password). I find
        > that to be a problem, since, at least in my environment, many of the
        > servers are on Unix machines with shared file systems, and it would be
        > relatively easy for someone to find another's password. I would prefer
        > that the password be stored encoded by some function f() (possibly MD5?).
        > Then the client would compute MD5(nonce f(passwd)), and the server could
        > duplicate the computation, except it would have f(passwd) in its password
        > file already.

        This is a good idea, but it is important to understand that it doesn't
        really protect you the way you might think. It is still necessary to
        protect the password file from being read by any untrusted user. If
        an untrusted user gets the encoded password f(passwd) he can create
        MD5(nonce f(passwd)) and access everything the user with passwd is
        entitled to. The reason it is a good idea is that people foolishly
        tend to use the same password on many systems so the sysadmin on the
        SimpleMD5 system might read the password and guess that the user has
        that password on a different system.

        It would also be a very good idea to actually encrypt the password in
        the password file and decrypt it when checking access. This may
        involve export problems though. Here is a way one might do it using
        only MD5 (which is exportable). Have a KEY known only to the server
        and password management utilities. In the password file store

        username:salt:encrypted_pw
        where
        encrypted_pw := password xor MD5( username:salt:KEY)

        then the server can extract password because it is equal to

        encrypted_pw xor MD5( username:salt:KEY)

        The salt must change whenever the user changes password. Someone
        reading the password file cannot decrypt the password without knowing
        KEY.

        I don't know how cryptographically sound this is but it should be good
        enough for SimpleMD5. I also am not certain that the fact that SimpleMD5
        is exportable would make this exportable.

        John Franks
      • Dave Kristol
        I suggested having an encoded (encrypted) password in the server-side password file. ... I certainly agree, and I don t want to imply that I believe this is
        Message 3 of 4 , Feb 1, 1995
        • 0 Attachment
          I suggested having an encoded (encrypted) password in the server-side
          password file.

          John Franks said:
          > This is a good idea, but it is important to understand that it doesn't
          > really protect you the way you might think. It is still necessary to
          > protect the password file from being read by any untrusted user. If
          > an untrusted user gets the encoded password f(passwd) he can create
          > MD5(nonce f(passwd)) and access everything the user with passwd is
          > entitled to. The reason it is a good idea is that people foolishly
          > tend to use the same password on many systems so the sysadmin on the
          > SimpleMD5 system might read the password and guess that the user has
          > that password on a different system.

          I certainly agree, and I don't want to imply that I believe this is
          bullet-proof security. The point, though, is that if I grabbed a
          password from the server-side file, I could masquerade as a user by
          simply entering that user's password to my favorite browser. If the
          password is encoded, I have to go to some more trouble to spoof the
          user, because I can't simply supply the encoded value to the browser.

          Dave Kristol
        • Mary Ellen Zurko
          ... [...] ... Having the KEY only helps if it s less easy to access than the password files (for the threat you point out). So, how does the server know the
          Message 4 of 4 , Feb 2, 1995
          • 0 Attachment
            > only MD5 (which is exportable). Have a KEY known only to the server
            > and password management utilities. In the password file store
            [...]
            > The salt must change whenever the user changes password. Someone
            > reading the password file cannot decrypt the password without knowing
            > KEY.

            Having the KEY only helps if it's less easy to access than the
            password files (for the threat you point out). So, how does the server
            know the KEY? It's in a .conf file somewhere, or it's input on
            startup. If it's really a key and not a password, the latter will
            never fly. And actually, if given an option, most sites would take the
            .conf file anyway. Which would mean it was only in memory. Reading
            memory on a multi-user machine may be slightly harder to do than
            reading a protected file, but the threats are pretty close.
            Mez
          Your message has been successfully submitted and would be delivered to recipients shortly.