Hello Chris,
Answers below.
Thanks again.
On Mon, May 25, 2015 at 3:18 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Yuval,
>
> On 5/24/15 5:06 PM, Yuval Schwartz wrote:
> > Firstly, I'd like to clear something up: Is container managed
> > security security only intended for use with administrative users
> > of a web application?
>
> No. What would give you that impression?
>
> > Because I was intending on using it for all users of my web
> > application (eg: customers, students, etc. People with no
> > administrative responsibilities).
>
> You can use it with everyone.
>
> > On Sun, May 24, 2015 at 9:00 PM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > 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(inputCredent
> ials,
> >>
> >>
> 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.
>
> Correct: both the salt and iteration could is stored in the database
> along with the actual hashed credential.
>
> >> Also, if I change the iterations and saltLength in my context.xml
> >> file, authentication is still successful regardless of the values
> >> I input.
>
> Correct: the stored credentials still include the salt length and
> iteration count. If you specify the "iterations" and "saltLength" in
> context.xml, they will be applied to the CredentialHandler object, but
> no code actually uses that.
>
> Note that neither the "saltLength" nor the "iterations" attributes are
> documented in the Tomcat users' guide... because they are unnecessary.
>
> >> 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.
>
> This is not possible without a great deal of work. I would just
> instantiate my own MessageDigestCredentialHandler, configure it, and
> then use it to create new credentials.
>
> >> But since I am not able to, I just initialize a new
> >> MessageDigestCredentialHandler and use that to create the stored
> >> credentials.
>
> Sounds good.
>
> >> 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?
>
> Tomcat can't authenticate without the plain-text credential. That's
> whe whole point of authentication: to prove that the remote client is
> who they say they are. Without the plain-text credential, there's
> nothing to verify.
>
> What are you actually trying to do, here... it sounds like you don't
> want to do standard username/password authentication.
>
I want to do standard username/password authentication.
However, I also want an additional (common) feature that a lot of other
websites have: a "remember me" checkbox.
This "remember me" checkbox will store a cookie with a unique id in it.
My database will link this unqiue id to the userid.
Then I can retrieve the user object in the servlet.
Then I would like to log him in with request.login(). However, at this
point, all I have is the hashed version of the password (because it was
retrieved from my database, not from the user).
How else can I go about doing this?
Thanks.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJVYxMYAAoJEBzwKT+lPKRYrTUQAJEBT6IXUIbnFJlBTxPIBDia
> SqTh2YfWom5c2a+M6A3354llz6jnW8LZNU+In2sXgC9kwae3FwHLiPsUNEV+HWAq
> 674gKOvwNm2j7Ic5NwZe03tmzhFIpA3hz+Rr4oriAb38VeMpvpWjqZFGu1x8fEJi
> +RJO6g8W85Lg9enkeoPxyA3bBdPuE+WtD2gGPcbZsrgh4g/V9HSNq0Wp7rlv9eez
> kOnP2hOip/+wDVJ/9j3OObXK/F6ZFHZtZHlJbI9W15qm6FsPhY1F0XLMhWQUrXCi
> Ifmw4Ljwle078EV6NxfLRZyC88Ap45y70Y9a6JX/K9jZFTwhQZpxKiwE3wftPY+d
> aXBiMUd/imSOOmkGIYsQSNyFTqwwsi30/ZxY5LyvYKUKCNFsczpG2LrUGF9/ItqF
> DdS0hR9Rbyz+9uiTFgAjG1fcvVSnTcCS4CfuQTDa1wdMYz+B4y39ewdq8gkej4SF
> XxKkYGtphIx4zxtG7ud3TtoGsew8bxMI8q363NRvjKBxVlhE4uAPibUE03eY6Qhi
> pGo26GMva/FjYLm7rhJBng+qNuiETYi2NXIGgUpXGyAxHRW/f1rU/AcelEUp8sx2
> T9SjCcf67Bpthh92b8ihmCdZS4MZkdNclv6gvFTFBE84uRsefgs8fYsY/G0NeWPJ
> fmZnh9WI0zRote025Vnh
> =Cf7r
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
