Hello,
Firstly, I'd like to clear something up:
Is container managed security security only intended for use with
administrative users of a web application?
Because I was intending on using it for all users of my web application
(eg: customers, students, etc. People with no administrative
responsibilities).
I have some more follow up questions and they are below.
Thank you again for your time.
On Sun, May 24, 2015 at 9:00 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Yuval,
>
> On 5/23/15 7:15 AM, Yuval Schwartz wrote:
> > I can currently initialize a MessageDigestCredentialHandler object
> > with my desired salt, iteration and algorithm parameters and then
> > call the handler's mutate() method before inserting the password
> > into my database.
>
> Good.
>
> > And, from a servlet, the HttpServletRequest Object's login() (for
> > example) method works when inputting the user_name and plain text
> > password.
>
> Good.
>
> > However, I am still struggling to create my database input
> > ({salt}:{iterations}:{hash}) without inputting my desired
> > parameter (iterations, saltLength, etc.) to a
> > MessageDigestCredentialHandler, but rather by getting these
> > parameters (or the CredentialHandler itself) from the servlet.
>
> What have you tried? Do you want the remote user to be able to specify
> the salt size and iterations?
I'd advise against that, since users may
> intentionally reduce their own security (or, worse, intentionally give
> you an effectively infinite salt or iteration count, which could
> represent a DOS vulnerability).
>
> > Without being able to do this, I don't see the purpose of
> > specifying these parameters in the nested <CredentialHandler>
> > element within the <Realm> element of the context.xml file (these
> > parameters are retrieved from the "storedCredential" when
> > authenticating meaning they're not used when a method such as
> > request.login() is performed).
>
> The are absolutely used when HttpServletRequest.login() is called.
> That login() method ultimately calls Realm.authenticate(), which uses
> the CredentialHandler. The settings in CredentialHandler entirely
> handle logins for existing users.
>
Realm.authenticate() calls
MessageDigestCredentialHandler.matches(inputCredential, storedCredential)
calls
DigestCredentialHandlerBase.matchesSaltIterationsEncoded(inputCredentials,
storedCredentials) (line 146 of class MessageDigestCredentialHandler)
This method isolates the salt from the storedCredential (line 162)
Then isolates the iterations from the storedCredential (line 164)
Then uses both these parameters in addition to the inputCredential to call
MessageDigestCredentialHandler.mutate( inputCredential, salt, iterations).
Then does calls the equals method of String class to compare the mutated
results.
Therefore I concluded that the salt and iterations are taken from the
stored password when authenticate() is called.
Also, if I change the iterations and saltLength in my context.xml file,
authentication is still successful regardless of the values I input.
Did I configure something incorrectly?
>
> It looks like you are struggling to create the stores credentials in
> the first place (e.g. in a "change password" or "register" workflow).
>
I wanted to do it by getting the same MessageDigestCredentialHandler that I
defined in the context.xml in my servlet.
But since I am not able to, I just initialize a new
MessageDigestCredentialHandler and use that to create the stored
credentials.
Is there any way to authenticate a user using just the stored credential
(ie: I don't have the plain text password. I only have the storedCredential
and I want to call request.login(). Is that possible?
Thanks.
>
> > The way my code is now there is no purpose to specifying saltLength
> > and iterations in the context.xml file.
>
> Does that mean you have hard-coded the salt length and iterations in
> your credential-generating algorithm? I'd advise against that because
> you may want to modify the salt size or number of iterations in the
> future, and you don't want to have to re-compile your code to do that.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJVYhHEAAoJEBzwKT+lPKRYqjwP/A/+uLxfqKhiYcnnsnz+L64f
> l4Bwde+wy+QJh5/0A90KVSbBi7BS0x9/khOCm+xjGMNtH7BeApMW+h+haBXEbAZW
> ANFLLYv+4yJEFuz1Kz3jmtXkdwHpKRf9a7eN7HMwDfslZFaH+HgF1szzzaWVeV9i
> 398+5R5fiUqZZfVqp6TpZ3rh4TdmtwxbWgNWmiBz5pFrRvg9Uq+vOr6JQBYjsuu0
> l9rNepJjHItvxEv+cvCY4xaJjdKhHd4xM2XgTuG60YT7MsItlRvMiYsUnM41oPJU
> 9KTI30wAC3DacVwj7ChFzQIgAP1NaGfbLFSsie4xqeyS7G4WSAux0uSR/gHtsQzi
> NDHJSU96R2vu1O5n+kDZyyHYCqLpezXbNMQydMPgoAPQ6lt9HG1T3cA/GUYO83Zy
> BAKr8D7FJQZyPH7CfNtRUynbZsKIBelhJ9x2SDM3/seJRyEGJvxshHJxwFcATyEk
> OWppe9IVFL4YaCVl+RAuIvVeLxOczIrTACibgRmmX0TJiqBZFgWFhUbEX+kGhQVN
> AjTubEIqKaiifzUfkem0cC0bAf4KFQq4vyUbxCJJDY9EJpsB+5ysdr0IzU2qI0Q0
> 9tP7zAB1n5+fobV/5qr+orMAuGqlucPz5zK6IJqpEqYBp0Duw2+iuiv4jYnxlDgI
> fCi/4VXuKjprHqM7Aqb7
> =Ndq8
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
