-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Sreyan,
On 8/23/15 2:36 PM, Sreyan Chakravarty wrote:
> I need to use Container Managed Security and Authentication in my
> latest project. And I have a couple of queries regarding how to
> configure a Credential Handler.
What are your requirements? You may not have to manually-configure a
CredentiaHandler.
> 1. Firstly how will a CredentialHandler declaration look like ?
> Can someone provide a sample declaration of the
> NestedCredentialHandler with the algorithm attribute declared. I
> need to know since the Digest attribute in Realms has become
> deprecated. I didn't find any examples on the web and I am utterly
> confused.
Reviewing the documentation, I can see how it might be confusing.
Here's a simple configuration.
<Realm ...>
<CredentialHandler
className="org.apache.catalina.realm.MessageDigestCredentialHandler"
algorithm="SHA-256"
iterations="28764"
saltLength="16" />
</Realm>
You only need "NestedCredentialHandler" if you want to be able to
support more than one kind of stored-credential. You only really need
to do this when you are trying to switch from one type of
stored-credential to another, and need to be able to support either
style for a period of time. (e.g. switching from plain-old MD5 to
salted, iterated SHA-256, or from hash-based credential-format into
something like PBKDF.)
> 2. Whats the difference between MessageDigestCredentialHandler and
> SecretKeyCredentialHandler which one is more secure ?
As the documentation says, MessageDigest uses MessageDigest to hash
passwords. It can also perform iterations and salting of the password
as it's hashed. SecretKey uses the the SecretKeyFactory class and
therefore supports the types of algorithms supported, there.
Which one is more secure is a matter of opinion (at least, IMO).
Algorithms such as PBKDF2 are not really much more than
salt+hash+iteration, so you can achieve the same effect with the
MessageDigestCredentialHandler if you tune the parameters correctly.
You may be in an environment where saying that you specifically use
PBKDF2 (rather than some "home brewed" salt+hash+iteration) may be
more advantageous. Also, that kind of algorithm (PBKDF2) is
formally-specified.
> 3. SecretKeyCredentialHandler specifies only one algorithm in the
> documentation which is PBKDF2WithHmacSHA1. What other algorithms
> are available ?
Have a look at your JVM to find out what is currently supported. Call
java.security.Provider.keySet() on your crypto provider(s) to find out
their properties. You're looking for something like this:
SecretKeyFactory.DES=com.sun.crypto.provider.DESKeyFactory
SecretKeyFactory.DESede=com.sun.crypto.provider.DESedeKeyFactory
SecretKeyFactory.PBEWithHmacSHA1AndAES_128=com.sun.crypto.provider.PBEKe
yFactory$PBEWithHmacSHA1AndAES_128
SecretKeyFactory.PBEWithHmacSHA1AndAES_256=com.sun.crypto.provider.PBEKe
yFactory$PBEWithHmacSHA1AndAES_256
SecretKeyFactory.PBEWithHmacSHA224AndAES_128=com.sun.crypto.provider.PBE
KeyFactory$PBEWithHmacSHA224AndAES_128
SecretKeyFactory.PBEWithHmacSHA224AndAES_256=com.sun.crypto.provider.PBE
KeyFactory$PBEWithHmacSHA224AndAES_256
SecretKeyFactory.PBEWithHmacSHA256AndAES_128=com.sun.crypto.provider.PBE
KeyFactory$PBEWithHmacSHA256AndAES_128
SecretKeyFactory.PBEWithHmacSHA256AndAES_256=com.sun.crypto.provider.PBE
KeyFactory$PBEWithHmacSHA256AndAES_256
SecretKeyFactory.PBEWithHmacSHA384AndAES_128=com.sun.crypto.provider.PBE
KeyFactory$PBEWithHmacSHA384AndAES_128
SecretKeyFactory.PBEWithHmacSHA384AndAES_256=com.sun.crypto.provider.PBE
KeyFactory$PBEWithHmacSHA384AndAES_256
SecretKeyFactory.PBEWithHmacSHA512AndAES_128=com.sun.crypto.provider.PBE
KeyFactory$PBEWithHmacSHA512AndAES_128
SecretKeyFactory.PBEWithHmacSHA512AndAES_256=com.sun.crypto.provider.PBE
KeyFactory$PBEWithHmacSHA512AndAES_256
SecretKeyFactory.PBEWithMD5AndDES=com.sun.crypto.provider.PBEKeyFactory$
PBEWithMD5AndDES
SecretKeyFactory.PBEWithMD5AndTripleDES=com.sun.crypto.provider.PBEKeyFa
ctory$PBEWithMD5AndTripleDES
SecretKeyFactory.PBEWithSHA1AndDESede=com.sun.crypto.provider.PBEKeyFact
ory$PBEWithSHA1AndDESede
SecretKeyFactory.PBEWithSHA1AndRC2_128=com.sun.crypto.provider.PBEKeyFac
tory$PBEWithSHA1AndRC2_128
SecretKeyFactory.PBEWithSHA1AndRC2_40=com.sun.crypto.provider.PBEKeyFact
ory$PBEWithSHA1AndRC2_40
SecretKeyFactory.PBEWithSHA1AndRC4_128=com.sun.crypto.provider.PBEKeyFac
tory$PBEWithSHA1AndRC4_128
SecretKeyFactory.PBEWithSHA1AndRC4_40=com.sun.crypto.provider.PBEKeyFact
ory$PBEWithSHA1AndRC4_40
SecretKeyFactory.PBKDF2WithHmacSHA1=com.sun.crypto.provider.PBKDF2Core$H
macSHA1
SecretKeyFactory.PBKDF2WithHmacSHA224=com.sun.crypto.provider.PBKDF2Core
$HmacSHA224
SecretKeyFactory.PBKDF2WithHmacSHA256=com.sun.crypto.provider.PBKDF2Core
$HmacSHA256
SecretKeyFactory.PBKDF2WithHmacSHA384=com.sun.crypto.provider.PBKDF2Core
$HmacSHA384
SecretKeyFactory.PBKDF2WithHmacSHA512=com.sun.crypto.provider.PBKDF2Core
$HmacSHA512
That's for my Oracle 1.8-level JVM. So it looks like it supports the
following algorithms: DES, PBEWithHmacSHA1AndAES_128 (and friends),
PBEWithMD5AndDES (and friends), PBKDF2WithHmacSHA1 (and friends).
I tested on a 1.6 JVM and it looks like PBKDF2WithHmacSHA1 is the only
one supported at that JVM level.
The complexity of the <CredentialHandler> was added so that it would
be easier to plug-in arbitrary algorithms (e.g. bcrypt/scrypt/etc.) if
users wanted to support them. As it was before CredentialHandler was
added, a user would basically have to re-implement the whole Realm
just to change the way credential-munging was being done.
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJV2yBHAAoJEBzwKT+lPKRYFrQP/ieskP7sh6lIz3KpCOtWeGyS
4bBVdPcSoBnIZmJHbA9OrjiZrcH7+rhOgMr5J8cKzG70NqUKMGcdzbuonuFVbT1S
CXymcRPj8sRjHYOZwoXoJhotqbcsGZQTu5vyi0QryQEabRFi+Nlovh2V1fPF3nQ+
VkHx1Pmu79H4RmagMWpiqvT0epWvz1joUukeDK6BOcwDDZjDx5wU60MLGyNEicpN
PE9ynPfV86q2KKsAYRJ2Y8If/CN4fYAcP5RctzqS5XiV3wuYYAYZi7UO6p76fh71
j0074TERhFiFtri6g4mRtncCqS8JCR3Z1vgSU6CSWKPJEtDWNfRp7H+UD5QM9kSd
2Ff/trn0LjBXeDbgKj25Ty4NHV9ShmCUYgWYlr7/mDQ3eWCJ1OR3ads79ztI7mQt
7Plu6Wx6zVnObbV8HhCbE5Bs6EEINvudJ9JiT5J8xoRHSLrbGi1rruJzq2hZv6zD
21y93b6PXGdw8TqgGQGbDonaHQ/MZLSPYilx8JXxXQhVwQeoU4hUQ0nQWh3ApLuK
ENJovT0Wj9kN72EdLoDT7nBZrh7YMLFI9Gvrf71oSmWJGvT5b5aBf6CMVD0UzUcs
o+D8ULrsOFd22GC7nCMhX30cPeqacKzQlCrlmg4n5BSzQ7A4vbO1oWiZuzFTgUmk
neC95qzm0mIM0ith6RIg
=qucr
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
