1 2 Previous Next 17 Replies Latest reply on Oct 1, 2005 4:57 PM by acoliver

    Proposed changes.

    acoliver

      I'm working on APOP for JBMS: http://jira.jboss.com/jira/browse/JBMAIL-80 for JBMS which needs a thread-based "shared secret" which is prepended to the password and MD5 hashed:

      http://www.xs4all.nl/~jrme/apop.html

      "
      S: <wait for connection on TCP port 110>
      C: <open connection>
      S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
      C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
      "

      The string is <1896.697170952@dbc.mtview.ca.us>password

      My plan is to add a couple settings to jboss-4.0/security/src/main/org/jboss/security/auth/spi/UsernamePasswordLoginModule.java

      for specifying the name of a thread local static singleton class which matches an interface specifying "getSecret()" which provides the <1896.697170952@dbc.mtview.ca.us> key. It would only take effect if the tlsPrefix option was set to a FQN providing the "getSecret()".

      The class specified will be constrained to be in an accessible classloader for the JAAS login module.

      This will not interfere with normal operation of the class unless the hashing is enabled with the tls provider set. I'll of course provide unit tests and stuff like that.

      Is this reasonable?

      Thanks,

      Andy

        • 1. Re: Proposed changes.
          starksm64

          There already is a plugin that can be specified via the digestCallback option: The class name of the org.jboss.crypto.digest.DigestCallback implementation that includes pre/post digest content like salts.

          /*
          * JBoss, the OpenSource J2EE webOS
          *
          * Distributable under LGPL license.
          * See terms of license at gnu.org.
          */
          package org.jboss.crypto.digest;
          
          import java.util.Map;
          import java.security.MessageDigest;
          
          /**
           * An interface that can be used to augment the behavior of a digest hash.
           * One example usecase is with the password based login modules to
           * modify the behavior of the hashing to introduce prefix/suffix salts.
           *
           * @author Scott.Stark@jboss.org
           * @version $Revision: 1.1 $
           */
          public interface DigestCallback
          {
           /** Pass through access to the login module options. When coming from a
           * login module this includes the following keys:
           * javax.security.auth.login.name - for the username
           * javax.security.auth.login.password - for the String password
           */
           public void init(Map options);
           /**
           * Pre-hash callout to allow for content before the password. Any content
           * should be added using the MessageDigest update methods.
           * @param digest - the security digest being used for the one-way hash
           */
           public void preDigest(MessageDigest digest);
           /** Post-hash callout afer the password has been added to allow for content
           * after the password has been added. Any content should be added using the
           * MessageDigest update methods.
           * @param digest - the security digest being used for the one-way hash
           */
           public void postDigest(MessageDigest digest);
          }
          


          Can you use this?


          • 2. Re: Proposed changes.
            acoliver

            Looking at the code this looks like it is ONLY called on the input password and not on the stored password. This shared secret is created every time a user connects on a thread. The password stored by the login module needs to be hashed with the prepend as well... Am I missing something/incorrect that this is only on the input password and not the "expectedPassword"?

            • 3. Re: Proposed changes.
              starksm64

              Yes, only the inputPassword is hashed as the expectedPassword is expected to be stored in a hashed form. I don't follow how the login module obtains the expectedPassword, how does the handshake interact with the security store?

              Generally the stored form has already been hashed and cannot be reversed to rehash to another form. Requiring access to the clear text password on the server and client is a poor security algorithm.

              • 4. Re: Proposed changes.
                acoliver

                I didn't state it clearly...for the purpose of this only the sent password is "hashed" so we must hash the stored password on the fly. The prefix changes EVERY time we connect.

                So here is the idea. The server sends

                +OK POP3 Server (JBMAIL POP3 Server version 0.2) ready <56.1127252208123@localhost.localdomain>

                then the client sends:

                APOP username (md5-hashed-hexed:<56.1127252208123@localhost.localdomain>password)

                The <56.1127252208123@localhost.localdomain> is generated for EVERY connection (threadid.epochtime@servername)

                The password is stored in the clear.

                The idea of this (though admitedly silly) is that it is not vulnerable to replay attacks since the server will never give you the same howdy-do ever again (threadid+epoch). So anyone intercepting the hashed password cannot use that hash in a replay because it will be different. SSL kind of makes this unnecessary (because of nonce) but this is a widespread standard and does not require another port. If you look at the links I posted above it will be clearer.

                -andy

                • 5. Re: Proposed changes.
                  starksm64

                  Ok, so what you really need is a storeDigestCallback to apply the same hashing to the cleartext password known by the server that the client has done correct? Inside the storeDigestCallback you can look for the shared secret via a thread local.

                  • 6. Re: Proposed changes.
                    acoliver

                    Affirmative.

                    • 7. Re: Proposed changes.
                      starksm64

                      Ok, I'll add that.

                      • 8. Re: Proposed changes.
                        acoliver

                        shall I add a flag to "reverseHashing" or something...?

                        • 9. Re: Proposed changes.
                          starksm64

                          I added a storeDigestCallback option:

                          option: storeDigestCallback - The class name of the org.jboss.crypto.digest.DigestCallback implementation that includes pre/post digest content like salts for hashing the store/expected password.

                          • 10. Re: Proposed changes.
                            acoliver

                            cool... Man every time I get close to messing up JBossSX you add it instead ;-) How am I supposed to inject horrible security flaws into JBossSX? ;-)

                            • 11. Re: Proposed changes.
                              starksm64

                              Keep trying.

                              • 12. Re: Proposed changes.
                                starksm64

                                Both a hashStorePassword and storeDigestCallback are needed as the password could be hashed without specifying a storeDigestCallback.

                                # hashStorePassword (4.0.3+) - A flag indicating if the store password returned from getUsersPassword() should be hashed.
                                # storeDigestCallback (4.0.3+) - The class name of the org.jboss.crypto.digest.DigestCallback implementation that includes pre/post digest content like salts for hashing the store/expected password. Only used if hashStorePassword is true and hashAlgorithm has been specified.

                                • 13. Re: Proposed changes.
                                  acoliver

                                  Humm this appears to not be operating as expected. Fixing.

                                  • 14. Re: Proposed changes.
                                    acoliver

                                    made a few small alterations. Hopefully I snuck in a good fat security hole in the process. I've been slashdotted before, now I'm hoping to have a cert advisory named after me.

                                    1 2 Previous Next