Thanks Christopher for that previous reply. It really help clear things up
and get things moving again.
Now can you tell me how do I write my own custom credential handler.
Planning one that uses sCrypt.
How can I write it and reference that same CredentialHandler in the
context.xml like
<CredentialHandler class="custom handler"></CredentialHandler>
On Mon, Aug 24, 2015 at 11:30 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Sreyan,
>
> On 8/24/15 1:19 PM, Sreyan Chakravarty wrote:
> > No you don't understand what my question was. Say I do something
> > like this-:
> >
> > String password = request.getParameter("passwd");
> >
> > long salt = // get salt from SecureRandom
> >
> > String password = salt + password;
> >
> > String hash = encrypt(password) // Use some encryption like bCrypt
> >
> > storeInDb(hash); // Stores it in User Table along with user-id and
> > role
> >
> > Now when I am querying from the database using a DataSourceRealm
> > for example. How do I replicate the exact hashing procedure.
>
> You are circling the right answer: you use a CredentialHandler for
> this. You may have to write your own if the built-in ones don't
> support your hashing strategy.
>
> > I can obviously store the salt value in another column but how can
> > I tell the Realm or CredentialHandler to use the salt and then hash
> > the password there is obviously no salt attribute in the
> > CredentialHandler.
>
> There is a salt *length* attribute, but that's how many random bits to
> use when creating a new stored-credential.
>
> The CredentialHandler docs[1] have examples of how to store the
> password in the database. If you are using digest + salt + iterations,
> then you want to store the password in the db table like this:
>
> salt$iterationCount$encodedCredential
>
> Those are literal $ symbols between the 3 different components of the
> stored credential. The salt and encodedCredential should be in
> hex-encoding (e.g. "abc" = "979899"). The iteration count should be a
> simple integer like "1000". (I highly recommend using a very large
> number of iterations... something that takes ~2s on a modern machine
> ought to be appropriate).
>
> > So in other words how do I replicate the exact same hashing
> > procedure while retrieving the password to that I used when I was
> > storing the password in the database.
> >
> > Is there a way to use the Realm to insert the user-id and password
> > into the database ?
>
> No, but you can feel free to instantiate the same kind of
> CredentialHandler with the same settings and then use the mutate()
> function to see what the CredentialHandler will produce from a given
> input.
>
> > Because that seems like the most straight forward approach. I don't
> > know why there isn't an API for doing just that in Tomcat.
>
> CredentialHandler.mutate will mutate the credentials. It's up to you
> to store them wherever makes the most sense.
>
> > What good is having saltlength in CredentialHandler if its not
> > going to use it to create a password.
>
> See above.
>
> > Salts have to be specified differently and Tomcat just cannot
> > assume the first 20 characters (specified in the saltlength
> > property) to be the salt.
>
> See above.
>
> > So how can I store the credentials in the database and get them
> > back using the same hashing procedure ?
> >
> > And why hasn't the documentation included sufficient number of
> > examples of this process.
>
> Because it's been written by people who knew what the process was and
> didn't know the right questions to answer.
>
> > No one seems to know anything about it.
>
> Really? Who have you asked? I know a fair bit about it, and I'm trying
> to answer your questions.
>
> I'm happy to help; don't be so grouchy about asking questions,
> especially if someone is willing to reply and help you out.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJV21u6AAoJEBzwKT+lPKRYH9QP/0CykG/8FCXdTuATjeam05oa
> 5ru2NO1Z44bwp932GvlPuNcySEeB+1CkYEzqtiBk/vPPalFrYAKq2SRqtba7nHnl
> RB0z1lM43OoGGuHkCyXs87xdZjD2BDCG+9pNMnZqymkzbQUsVV96UFOO1d3vHQK4
> ZC6qsXBtVBjMfKO1+bOiZ+zrUKavMShtxve798OO7M+tvbqVAG7jvFI+BL0yQqXk
> SgcxdOY30NU3jcl7GZh/JkrvcKgULNRUgMPSmDNedMI38zK4hEhTBo2xuf6yRVos
> COizoJ9zduRVfnMZKhG9TRBvmuJFFkQuaUNIr1Yrt/HKicA3y86ZaiJZzmt8FS4h
> YV/uLfZkPt2w3Ip2CoPozYE5Vp+si4N6TPTCcfKmYlCBh2Qc3jl1FbXAdw7zkfz1
> b/abID3ISAMrXEbcuFakLI+eYi/+km8JRNk3wLBX5xmg4ZF8CPIgNGBK8w39Gmaz
> x5gW3iv6p/h6iT0lE8cri4Lm4kTeQv9F/t04Z2TvN7HeQf7OBQEh8B7ZsVGurbKG
> vO4NlSU1inTMs94P4Y4WVDDcFOZIFC0ny6dseFBmeWBVpBRPKnMdjVPzBjBh6Wsr
> 1Q1U880EXFLrg+bAC69+qqV2GgvlKqvItFB9P2VZ1PXSEnVGTGFFK65Yh1KDtAgG
> dRGp4gxRJzlmRshreCqn
> =zsRW
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
