-
1. Re: Proposed changes.
starksm64 Sep 20, 2005 4:26 PM (in response to acoliver)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 Sep 20, 2005 4:41 PM (in response to 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 Sep 20, 2005 5:10 PM (in response to acoliver)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 Sep 20, 2005 6:07 PM (in response to 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 Sep 20, 2005 6:44 PM (in response to acoliver)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.
-
-
7. Re: Proposed changes.
starksm64 Sep 20, 2005 6:55 PM (in response to acoliver)Ok, I'll add that.
-
8. Re: Proposed changes.
acoliver Sep 20, 2005 7:02 PM (in response to acoliver)shall I add a flag to "reverseHashing" or something...?
-
9. Re: Proposed changes.
starksm64 Sep 20, 2005 7:07 PM (in response to acoliver)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 Sep 20, 2005 7:09 PM (in response to 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? ;-)
-
-
12. Re: Proposed changes.
starksm64 Sep 20, 2005 9:27 PM (in response to acoliver)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 Sep 29, 2005 4:52 PM (in response to acoliver)Humm this appears to not be operating as expected. Fixing.
-
14. Re: Proposed changes.
acoliver Sep 29, 2005 6:28 PM (in response to 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.