You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Yuval Schwartz <yu...@gmail.com> on 2015/05/20 15:34:58 UTC
Fwd:
Hello,
I believe I am running tomcat 8.0 (although when I call the getServerInfo()
method of the implicit ServletContext Object It tells me that I am running
on 7.54)
I configured my realm element in my context.xml file as follows (based on
the howto guide: https://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html):
<Realm className="org.apache.catalina.realm.DataSourceRealm" debug="99"
dataSourceName="jdbc/board" localDataSource="true"
userTable="test_user" userNameCol="Email" userCredCol="HashedPassword"
userRoleTable="test_user_role" roleNameCol="Role">
<CredentialHandler className="MessageDigestCredentialHandler"
algorithm="SHA-1"
iterations="1000" saltLength="48"/>
</Realm>
However, despite the password being stored in the format described in your
"how to" manual (ie:{salt}${iterations}${password}), authentication fails.
I assume that this is because something in my <Realm> configuration is
wrong.
I was not able to find an answer on online help forums.
I also couldn't find a way to call the initialized DataSourceRealm Object's
digest method when inputting the HashedPassword (ie: I had to calculate
salt and hash on my own using the SHA-1 algorithm). Perhaps this also has
something to do with why authentication is failing?
Thank you
Re: Fwd: Fwd:
Posted by André Warnier <aw...@ice-sa.com>.
Hello Yuval.
As a kind of generic answer to your previous enquiries :
Tomcat is a "Servlet Container", and the developers who write Tomcat strive to have it
behave in accordance with the applicable "Java Servlet Specification".
Refer to this page to find out which version of Tomcat matches which version of the
Servlet Specification : http://tomcat.apache.org/whichversion.html
and then search the web for the appropriate version of the Servlet Specifications.
As the name indicates, this document describes in detail what java servlets and servlet
containers should and should not do, and in some cases how they should do it.
In that specification, there is a chapter entitled "Security" which among other things
covers the various forms of user authentication that should be supported by any
specs-respecting servlet container and which you are encouraged to read, as it already
contains answers to many of your questions.
In summary though, there are essentially 2 sub-categories there :
- container-managed (which covers Basic, Digest and Form-based user authentication)
- application-managed (which is whatever a developer may choose to implement at
application (webapp/servlet) level, e.g. via servlet filters)
As far as container-managed Form-based authentication is concerned, what Tomcat provides
is what the Servlet Specification says that it should.
(And that does not cover the "remember me" feature as you describe it below).
There may be third-parties which offer such enhancements (free or commercial), but you
will need to search for them.
Note that in addition to the above 3 container-managed authentication mechanisms, Tomcat
does also provide some additional options, like SPNEGO, JAAS etc..
See here : http://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html
and here : http://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html
And what Tomcat does provide is /sessions/, for which you can set yourself the expiration
time. It does not really do the same as the "remember me" feature you are talking about,
but it may cover your needs to some extent, depending on your circumstances.
Sessions are also explained in a chapter of the Servlet Specification.
HTH
Yuval Schwartz wrote:
> Hello Chris,
>
>
> Answers below.
>
> Thanks again.
>
> On Mon, May 25, 2015 at 3:18 PM, Christopher Schultz <
> chris@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 <
>>> chris@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fwd: Fwd:
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Yuval,
On 5/25/15 8:58 AM, Yuval Schwartz wrote:
> On Mon, May 25, 2015 at 3:18 PM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
> 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 <
>>>> chris@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(inputCred
ent
>
>>>>>
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.
Then don't call ServletRequest.login(), since you aren't performing
authentication in that case. You are using a previously-authenticated
token to essentially continue the user's previous "session" (I say
"session" because it's likely not an HttpSession).
Tomcat does not have a way to do this directly for you. But, you could
write a Valve (a Tomcat-specific component) that can handle this for
you. Instead of calling login(), you'll want to do what the
AuthenticatorValves do, and attach a Principal to the session as a
"note". You'll have to read the code to see how that all works.
>> 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).
Be careful about how you implement this: it's easy to subvert this
kind of setup if you (the programmer) don't know what you are doing.
In particular, I'd at least lock-down the "remember me" token to the
user's current IP address, and possibly require something else to
partially-authenticate the client.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVZHC8AAoJEBzwKT+lPKRY21AP/RZz/BIua0i3EfoDnBeyyeSO
/6kvznA9ZRtvA3tgKfse9EMzQch4f+/EyxZHZeGWJ+bsFjtarGsPYUD5xund/6IV
r341TVZkKV6/gf43Xyz87bsZTNMj4eb2R2GGFnr1fGb+o9PjMgCS8jIuwxPcDkBb
x0KR2oygnbOVcgJT8jr7WRFs4TDQpGhNVIqCzjMA4MgBL3g6NOb5mbjKbdrJaqgW
VKwICEWczlr2Gtz0B/VGLcslXRED/Zbo53yYmC0TDVlUfNO3FucQyVim43MgC3U2
83bXEGAwfkGvUBvftPiEKRqWvUqd4XjU3m+DZZFwP7u9PaXnnS/tSghfOA/QJ+Hv
pGx9Ngy/7sEezAXWbomuj38xclZ61gDK1tAS2qd9enoyh3OXiR7E7sW+Lnmgn+We
R9hwCthkRHKgnCVLzV1b4HxnifHfZqbfe4laIYoQfEuI0NC3R0hiMum4V077UG0g
e69NuxQ48W+RP0qC16vM8oQE9mQwyH1zKu9U6sVmVAxwiBYZyTu7ig9xQ/euRxeE
HA2xDTGh4V72FoPcJ7Piwm3f3yj0Vp54BxBox/xqnnGDyVPtXAlAwalpnxWD/vGL
9xT6LFrFbfvfuAMvAF1/1e1seUMhzcLBRrTQeVDSZABmXyj/tP3hqaaa4QvDjwjA
t2n8OmWSgFRjrRpOV9hx
=RYmZ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fwd: Fwd:
Posted by Yuval Schwartz <yu...@gmail.com>.
Hello Chris,
Answers below.
Thanks again.
On Mon, May 25, 2015 at 3:18 PM, Christopher Schultz <
chris@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 <
> > chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Fwd: Fwd:
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <
> chris@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.
- -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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fwd: Fwd:
Posted by Yuval Schwartz <yu...@gmail.com>.
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 <
chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Fwd: Fwd:
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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.
It looks like you are struggling to create the stores credentials in
the first place (e.g. in a "change password" or "register" workflow).
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fwd: Fwd:
Posted by Yuval Schwartz <yu...@gmail.com>.
Hello Chris,
Thanks once again.
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.
And, from a servlet, the HttpServletRequest Object's login() (for example)
method works when inputting the user_name and plain text password.
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.
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 way my code is now there is no purpose to specifying saltLength and
iterations in the context.xml file.
Thanks
_
Yuval
On Fri, May 22, 2015 at 8:17 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Yuval,
>
> On 5/22/15 9:54 AM, Yuval Schwartz wrote:
> > I wasn't aware that I can look at the actual classes but I wasn't
> > able to find a precompiled version of RealmBase for tomcat 8.
>
> You mean you didn't know you could look at the source code for Tomcat?
> It's open-source software, like like everything else at the Apache
> Software Foundation. Here's a link directly into the Subversion
> repository for the RealmBase code:
> http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catali
> na/realm/RealmBase.java?view=markup
>
> You can also pull the whole source tree from Subversion, or download a
> source distribution:
> http://tomcat.apache.org/download-80.cgi#Source_Code_Distributions
>
> > The following is a link to the class of version 7 (which doesn't
> > include the CredentialHandler code):
> > http://grepcode.com/file/repository.springsource.com/org.apache.catali
> na/com.springsource.org.apache.catalina/7.0.26/org/apache/catalina/realm
> /RealmBase
>
> Looking
> >
> at Tomcat 7 won't help, as you said: the CredentialHandler
> code is not in there.
>
> > When I try to view this file from my netbeans IDE (which is the
> > correct version), I get the compiled version. Do you know how I can
> > view the file that's not compiled?
>
> See above. This is the beauty of open source software :)
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJVX2SPAAoJEBzwKT+lPKRYxVAQAL4tp2cWv/xcVjEQ1BgnTAFT
> tlnBrBwVxRQvUsemByZ4DzGSQmkR6LFXFc0P95BLx7XBUB9AymGAL2CQdFevg3ah
> AUtwChNzu2Bfeu05fShHUNAGeJhArfxOpkYGtGX5VnD96XnyKCcTe2fME4vPm9hs
> 8VqsYr9bRLx0AhVmC2HgGan60DPGIjb/ZvFagS5nZDtj3/ZlYz+kkrN51POVcFXe
> EpWZi5lNBUNdeN1Dq+IbD9OqAkZJE/OjB2xdPPRGZfBeuXnzA97W2DrjCNTUpBHL
> wYsSxBoWjFVXtClZrn1Tkr1E72nWtKNu7mai7nou996c3oCvIZS92ev8SOIfb512
> BduEhPYeGI4vcTOv+Vtn02TTCApFjqD+OAxWfKtkT+Moau4L63qOeEedWKs9byVp
> lRKep137+ljyBDZXd9scArIs5RLShZBybkTTgyBc6v6ZJFsQiIF5Z3ow3Ox8v3u4
> w0gucKdiMEfQIorlmkCUgCUQDfzotammyaCg4O69N4dU7Okcla7Jpl1blv0YHCFf
> xnHVc0wXHQwRWdS+kJOsis8ScivXU5lYOS7vsRR3ZtKOadzE1rO4INHljpdK1G1T
> qySaZO0MH3k4BA3Gq1VIXpld2q7bWcEE8kaAiLl17LlBzSbGMSBik3uxl9PmF32N
> jjnMtokx3RX4oi1KaAD9
> =18f6
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Fwd: Fwd:
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Yuval,
On 5/22/15 9:54 AM, Yuval Schwartz wrote:
> I wasn't aware that I can look at the actual classes but I wasn't
> able to find a precompiled version of RealmBase for tomcat 8.
You mean you didn't know you could look at the source code for Tomcat?
It's open-source software, like like everything else at the Apache
Software Foundation. Here's a link directly into the Subversion
repository for the RealmBase code:
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catali
na/realm/RealmBase.java?view=markup
You can also pull the whole source tree from Subversion, or download a
source distribution:
http://tomcat.apache.org/download-80.cgi#Source_Code_Distributions
> The following is a link to the class of version 7 (which doesn't
> include the CredentialHandler code):
> http://grepcode.com/file/repository.springsource.com/org.apache.catali
na/com.springsource.org.apache.catalina/7.0.26/org/apache/catalina/realm
/RealmBase
Looking
>
at Tomcat 7 won't help, as you said: the CredentialHandler
code is not in there.
> When I try to view this file from my netbeans IDE (which is the
> correct version), I get the compiled version. Do you know how I can
> view the file that's not compiled?
See above. This is the beauty of open source software :)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVX2SPAAoJEBzwKT+lPKRYxVAQAL4tp2cWv/xcVjEQ1BgnTAFT
tlnBrBwVxRQvUsemByZ4DzGSQmkR6LFXFc0P95BLx7XBUB9AymGAL2CQdFevg3ah
AUtwChNzu2Bfeu05fShHUNAGeJhArfxOpkYGtGX5VnD96XnyKCcTe2fME4vPm9hs
8VqsYr9bRLx0AhVmC2HgGan60DPGIjb/ZvFagS5nZDtj3/ZlYz+kkrN51POVcFXe
EpWZi5lNBUNdeN1Dq+IbD9OqAkZJE/OjB2xdPPRGZfBeuXnzA97W2DrjCNTUpBHL
wYsSxBoWjFVXtClZrn1Tkr1E72nWtKNu7mai7nou996c3oCvIZS92ev8SOIfb512
BduEhPYeGI4vcTOv+Vtn02TTCApFjqD+OAxWfKtkT+Moau4L63qOeEedWKs9byVp
lRKep137+ljyBDZXd9scArIs5RLShZBybkTTgyBc6v6ZJFsQiIF5Z3ow3Ox8v3u4
w0gucKdiMEfQIorlmkCUgCUQDfzotammyaCg4O69N4dU7Okcla7Jpl1blv0YHCFf
xnHVc0wXHQwRWdS+kJOsis8ScivXU5lYOS7vsRR3ZtKOadzE1rO4INHljpdK1G1T
qySaZO0MH3k4BA3Gq1VIXpld2q7bWcEE8kaAiLl17LlBzSbGMSBik3uxl9PmF32N
jjnMtokx3RX4oi1KaAD9
=18f6
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fwd: Fwd:
Posted by Yuval Schwartz <yu...@gmail.com>.
Thanks again Chris,
I wasn't aware that I can look at the actual classes but I wasn't able to
find a precompiled version of RealmBase for tomcat 8.
The following is a link to the class of version 7 (which doesn't include
the CredentialHandler code):
http://grepcode.com/file/repository.springsource.com/org.apache.catalina/com.springsource.org.apache.catalina/7.0.26/org/apache/catalina/realm/RealmBase
When I try to view this file from my netbeans IDE (which is the correct
version), I get the compiled version. Do you know how I can view the file
that's not compiled?
Thanks
On Thu, May 21, 2015 at 11:49 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Yuval,
>
> On 5/21/15 2:39 PM, Yuval Schwartz wrote:
> > Hello,
> >
> > I have some follow-up questions to Chris' response below (in
> > blue).
> >
> > On Wed, May 20, 2015 at 5:53 PM, Christopher Schultz <
> > chris@christopherschultz.net> wrote:
> >
> > Yuval,
> >
> > On 5/20/15 9:34 AM, Yuval Schwartz wrote:
> >>>> I believe I am running tomcat 8.0 (although when I call the
> >>>> getServerInfo() method of the implicit ServletContext Object
> >>>> It tells me that I am running on 7.54)
> >
> > Then you are not running Tomcat 8.0.x.
> >
> >>>> I configured my realm element in my context.xml file as
> >>>> follows (based on the howto guide:
> >>>> https://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html):
> >
> > If you are running Tomcat 7, the Tomcat 8 users guide may give you
> > bad guidance. If you are intending to run Tomcat 8, you might want
> > to get that fixed, first.
> >
> >
> >> You are correct, I was running Tomcat 7, which doesn't use the
> >> same syntax for digesting from the command prompt (I think it
> >> doesn't have the options for salt, iterations, etc.). So I
> >> updated to tomcat 8.
>
> Correct: you'll need Tomcat 8 for the salting and iterative hashing.
>
> >>>> <Realm className="org.apache.catalina.realm.DataSourceRealm"
> >>>> debug="99"
> >
> > The "debug" attribute hasn't been supported for something like 10
> > years.
> >
> >>>> dataSourceName="jdbc/board" localDataSource="true"
> >>>> userTable="test_user" userNameCol="Email"
> >>>> userCredCol="HashedPassword" userRoleTable="test_user_role"
> >>>> roleNameCol="Role">
> >>>>
> >>>> <CredentialHandler
> >>>> className="MessageDigestCredentialHandler" algorithm="SHA-1"
> >>>> iterations="1000" saltLength="48"/>
> >
> > Oh, good: someone is using the CredentialHandler to improve their
> > security. You might want to:
> >
> > 1. Switch to a larger hash, like SHA-256 2. Find out how much time
> > it takes to do 1000 SHA-1 (or SHA-256) hashes on your server. You
> > want the hashing to take more than a trivial amount of time. Our
> > services currently use more than 10k iterations of SHA-256. This
> > makes brute-forcing our password database very time consuming for
> > an attacker, if they were to capture the database itself.
> >
> >>>> </Realm>
> >>>>
> >>>>
> >>>> However, despite the password being stored in the format
> >>>> described in your "how to" manual
> >>>> (ie:{salt}${iterations}${password}), authentication fails. I
> >>>> assume that this is because something in my <Realm>
> >>>> configuration is wrong.
> >
> > Tomcat can generate a hash for you from the command-line:
> >
> > $ ./bin/digest.sh -a SHA-256 -i 1000 -s 48 'test'
> > test:04d9deb5f6f1f206c7139a28806e7ebde8f444018e0191168f8d00291d6e8719c
> d2
> >
> >
> 5cc82eca073f9a925c005aadf238b$1000$22cb9257949205ffbff01088b46137cf768dc
> > 67a0faca26f48269ca9250d4d9b
> >
> > Let's take-apart that credential to see what's in there:
> >
> > hash:
> >
> >
> >> Don't you mean "salt" above, instead of "hash:"?
>
> Yes.
>
> > 04d9deb5 f6f1f206 c7139a28 806e7ebd e8f44401 8e019116 8f8d0029
> > 1d6e8719 cd25cc82 eca073f9 a925c005 aadf238b
> >
> > That's 48 bytes (96 characters) of data.
> >
> > iteration count: 1000 (easy)
> >
> > fingerprint: 22cb9257 949205ff bff01088 b46137cf 768dc67a 0faca26f
> > 48269ca9 250d4d9b
> >
> > That's 32 bytes (64 characters) of data. SHA-1 produces 32-byte
> > output, so this looks good on the face of it.
> >
> >
> >> I think you mean "SHA-256" here, right?
>
> Yes, sorry. SHA-256 produces a 256-bit hash, which is 32 8-bit bytes.
>
> >> Yes, it looks correct. My issue is that I would like to run this
> >> "digest" from a servlet. How would I do that? I need to run it
> >> from a servlet because I need to enter it into my database (in
> >> the format {salt}${iterations}${passowrd}).
>
> Take a look at RealmBase to see how it does it.
>
> >> Should I even be doing it this way? This relates to my previous
> >> comment: Is there no way to call the same digest function that we
> >> ran from the command line, in a servlet?
>
> Sure. Look at how RealmBase does it.
>
> >> Indeed there is a digest method as part of the RealmBase API, I
> >> just don't know how to get an instance of the RealmBase Object
> >> from the servlet.
>
> Create a new one and fill it with the information you know about how
> you want to store passwords?
>
> >> I looked at the RealmBase class:
> >
> >> https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/real
> m/RealmBase.html
> >
> >> I couldn't find where it mentions how to initially generate the
> >> stored credential. Could you give me a little more direction as
> >> to where I should look?
>
> You need to read the code, not look at the API. RealmBase just
> instantiates an instance of a CredentialHandler, configures it, and
> then calls its methods. Take a look at RealmBase's main() method.
> There's a lot of junk in there to handle handlers whose classes and
> methods are not known, but it boils down to:
>
> 1. Calling a constructor
> 2. Calling set[Stuff] several times
> 3. Calling a method that accepts the cleartext credential and produces
> an array of hashed bytes.
>
> You will have to manually assemble the {salt}${iterations}${hash}
> string, which should be trivial at that point.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJVXkTAAAoJEBzwKT+lPKRYr0YP/1Av1CqR50qUNeHxNTxJVH1l
> u9FlARGcEZ/eZ7qDDBjsUiXneAlkTOk8ZZat6Gxs/aJvVH0YAKGXA2rUmVHDIOYo
> Af6iD2wsHhL9Y5OePiK4PJHXdS1+1XRS5bUc61vE5abCx+PsOkQv9aPWvZMGJ8mv
> rw/4Lq8PlOEA4cBZ3GShm4tcL7DIeWLttygZGP22iQmIBnl6UJ7gj2PE//ozQGUr
> wBjhKg2JwMrglDqbFBXciXUQhvEofXXCuJvvfcWevo1FD9aGZTSPAmEYAZmzMKlP
> 0iGaiSpCl5j5rIsEHJlvR4xe1unD79U3pGTQ/fL71QxJ8zt4XlCnKsEvHUsbttgb
> X0ylt1GlUmrroOHp9GTAE79OCatjwsIv1VB/MmBk/IFMNbH0c1hkPqzn9Qn6xd60
> ssL7MPFXP8h8XzRHCLvJlxGtZ236YabKlI9BKK0HKnvSX7nMBDL8twHx8/3JM6MB
> czeyRgZj95+bOW1pco8skuSMtI0TjyZyxYLkf9nPvDJYVnje7OR9oMi/HIOMRdNb
> P+nHCZuNCAv+SNOLuQVMbx65NFBNK/LYPHzdzTCSEVaFsNNhUxnumX9rak9zHujV
> fDKaarRucIZVwFHNN1NiN2Ye1TVrgsyAHwujFQ1bYdPMlFRYdnBNhnFcFcXw7yL8
> fRiWM+ehAToF4sOK90DD
> =wfoh
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Fwd: Fwd:
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Yuval,
On 5/21/15 2:39 PM, Yuval Schwartz wrote:
> Hello,
>
> I have some follow-up questions to Chris' response below (in
> blue).
>
> On Wed, May 20, 2015 at 5:53 PM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
> Yuval,
>
> On 5/20/15 9:34 AM, Yuval Schwartz wrote:
>>>> I believe I am running tomcat 8.0 (although when I call the
>>>> getServerInfo() method of the implicit ServletContext Object
>>>> It tells me that I am running on 7.54)
>
> Then you are not running Tomcat 8.0.x.
>
>>>> I configured my realm element in my context.xml file as
>>>> follows (based on the howto guide:
>>>> https://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html):
>
> If you are running Tomcat 7, the Tomcat 8 users guide may give you
> bad guidance. If you are intending to run Tomcat 8, you might want
> to get that fixed, first.
>
>
>> You are correct, I was running Tomcat 7, which doesn't use the
>> same syntax for digesting from the command prompt (I think it
>> doesn't have the options for salt, iterations, etc.). So I
>> updated to tomcat 8.
Correct: you'll need Tomcat 8 for the salting and iterative hashing.
>>>> <Realm className="org.apache.catalina.realm.DataSourceRealm"
>>>> debug="99"
>
> The "debug" attribute hasn't been supported for something like 10
> years.
>
>>>> dataSourceName="jdbc/board" localDataSource="true"
>>>> userTable="test_user" userNameCol="Email"
>>>> userCredCol="HashedPassword" userRoleTable="test_user_role"
>>>> roleNameCol="Role">
>>>>
>>>> <CredentialHandler
>>>> className="MessageDigestCredentialHandler" algorithm="SHA-1"
>>>> iterations="1000" saltLength="48"/>
>
> Oh, good: someone is using the CredentialHandler to improve their
> security. You might want to:
>
> 1. Switch to a larger hash, like SHA-256 2. Find out how much time
> it takes to do 1000 SHA-1 (or SHA-256) hashes on your server. You
> want the hashing to take more than a trivial amount of time. Our
> services currently use more than 10k iterations of SHA-256. This
> makes brute-forcing our password database very time consuming for
> an attacker, if they were to capture the database itself.
>
>>>> </Realm>
>>>>
>>>>
>>>> However, despite the password being stored in the format
>>>> described in your "how to" manual
>>>> (ie:{salt}${iterations}${password}), authentication fails. I
>>>> assume that this is because something in my <Realm>
>>>> configuration is wrong.
>
> Tomcat can generate a hash for you from the command-line:
>
> $ ./bin/digest.sh -a SHA-256 -i 1000 -s 48 'test'
> test:04d9deb5f6f1f206c7139a28806e7ebde8f444018e0191168f8d00291d6e8719c
d2
>
>
5cc82eca073f9a925c005aadf238b$1000$22cb9257949205ffbff01088b46137cf768dc
> 67a0faca26f48269ca9250d4d9b
>
> Let's take-apart that credential to see what's in there:
>
> hash:
>
>
>> Don't you mean "salt" above, instead of "hash:"?
Yes.
> 04d9deb5 f6f1f206 c7139a28 806e7ebd e8f44401 8e019116 8f8d0029
> 1d6e8719 cd25cc82 eca073f9 a925c005 aadf238b
>
> That's 48 bytes (96 characters) of data.
>
> iteration count: 1000 (easy)
>
> fingerprint: 22cb9257 949205ff bff01088 b46137cf 768dc67a 0faca26f
> 48269ca9 250d4d9b
>
> That's 32 bytes (64 characters) of data. SHA-1 produces 32-byte
> output, so this looks good on the face of it.
>
>
>> I think you mean "SHA-256" here, right?
Yes, sorry. SHA-256 produces a 256-bit hash, which is 32 8-bit bytes.
>> Yes, it looks correct. My issue is that I would like to run this
>> "digest" from a servlet. How would I do that? I need to run it
>> from a servlet because I need to enter it into my database (in
>> the format {salt}${iterations}${passowrd}).
Take a look at RealmBase to see how it does it.
>> Should I even be doing it this way? This relates to my previous
>> comment: Is there no way to call the same digest function that we
>> ran from the command line, in a servlet?
Sure. Look at how RealmBase does it.
>> Indeed there is a digest method as part of the RealmBase API, I
>> just don't know how to get an instance of the RealmBase Object
>> from the servlet.
Create a new one and fill it with the information you know about how
you want to store passwords?
>> I looked at the RealmBase class:
>
>> https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/real
m/RealmBase.html
>
>> I couldn't find where it mentions how to initially generate the
>> stored credential. Could you give me a little more direction as
>> to where I should look?
You need to read the code, not look at the API. RealmBase just
instantiates an instance of a CredentialHandler, configures it, and
then calls its methods. Take a look at RealmBase's main() method.
There's a lot of junk in there to handle handlers whose classes and
methods are not known, but it boils down to:
1. Calling a constructor
2. Calling set[Stuff] several times
3. Calling a method that accepts the cleartext credential and produces
an array of hashed bytes.
You will have to manually assemble the {salt}${iterations}${hash}
string, which should be trivial at that point.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVXkTAAAoJEBzwKT+lPKRYr0YP/1Av1CqR50qUNeHxNTxJVH1l
u9FlARGcEZ/eZ7qDDBjsUiXneAlkTOk8ZZat6Gxs/aJvVH0YAKGXA2rUmVHDIOYo
Af6iD2wsHhL9Y5OePiK4PJHXdS1+1XRS5bUc61vE5abCx+PsOkQv9aPWvZMGJ8mv
rw/4Lq8PlOEA4cBZ3GShm4tcL7DIeWLttygZGP22iQmIBnl6UJ7gj2PE//ozQGUr
wBjhKg2JwMrglDqbFBXciXUQhvEofXXCuJvvfcWevo1FD9aGZTSPAmEYAZmzMKlP
0iGaiSpCl5j5rIsEHJlvR4xe1unD79U3pGTQ/fL71QxJ8zt4XlCnKsEvHUsbttgb
X0ylt1GlUmrroOHp9GTAE79OCatjwsIv1VB/MmBk/IFMNbH0c1hkPqzn9Qn6xd60
ssL7MPFXP8h8XzRHCLvJlxGtZ236YabKlI9BKK0HKnvSX7nMBDL8twHx8/3JM6MB
czeyRgZj95+bOW1pco8skuSMtI0TjyZyxYLkf9nPvDJYVnje7OR9oMi/HIOMRdNb
P+nHCZuNCAv+SNOLuQVMbx65NFBNK/LYPHzdzTCSEVaFsNNhUxnumX9rak9zHujV
fDKaarRucIZVwFHNN1NiN2Ye1TVrgsyAHwujFQ1bYdPMlFRYdnBNhnFcFcXw7yL8
fRiWM+ehAToF4sOK90DD
=wfoh
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Fwd: Fwd:
Posted by Yuval Schwartz <yu...@gmail.com>.
Hello,
I have some follow-up questions to Chris' response below (in blue).
On Wed, May 20, 2015 at 5:53 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Yuval,
>
> On 5/20/15 9:34 AM, Yuval Schwartz wrote:
> > I believe I am running tomcat 8.0 (although when I call the
> > getServerInfo() method of the implicit ServletContext Object It
> > tells me that I am running on 7.54)
>
> Then you are not running Tomcat 8.0.x.
>
> > I configured my realm element in my context.xml file as follows
> > (based on the howto guide:
> > https://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html):
>
> If you are running Tomcat 7, the Tomcat 8 users guide may give you bad
> guidance. If you are intending to run Tomcat 8, you might want to get
> that fixed, first.
>
You are correct, I was running Tomcat 7, which doesn't use the same syntax
for digesting from the command prompt (I think it doesn't have the options
for salt, iterations, etc.). So I updated to tomcat 8.
>
> > <Realm className="org.apache.catalina.realm.DataSourceRealm"
> > debug="99"
>
> The "debug" attribute hasn't been supported for something like 10 years.
>
> > dataSourceName="jdbc/board" localDataSource="true"
> > userTable="test_user" userNameCol="Email"
> > userCredCol="HashedPassword" userRoleTable="test_user_role"
> > roleNameCol="Role">
> >
> > <CredentialHandler className="MessageDigestCredentialHandler"
> > algorithm="SHA-1" iterations="1000" saltLength="48"/>
>
> Oh, good: someone is using the CredentialHandler to improve their
> security. You might want to:
>
> 1. Switch to a larger hash, like SHA-256
> 2. Find out how much time it takes to do 1000 SHA-1 (or SHA-256)
> hashes on your server. You want the hashing to take more than a
> trivial amount of time. Our services currently use more than 10k
> iterations of SHA-256. This makes brute-forcing our password database
> very time consuming for an attacker, if they were to capture the
> database itself.
>
> > </Realm>
> >
> >
> > However, despite the password being stored in the format described
> > in your "how to" manual (ie:{salt}${iterations}${password}),
> > authentication fails. I assume that this is because something in my
> > <Realm> configuration is wrong.
>
> Tomcat can generate a hash for you from the command-line:
>
> $ ./bin/digest.sh -a SHA-256 -i 1000 -s 48 'test'
> test:04d9deb5f6f1f206c7139a28806e7ebde8f444018e0191168f8d00291d6e8719cd2
> 5cc82eca073f9a925c005aadf238b$1000$22cb9257949205ffbff01088b46137cf768dc
> 67a0faca26f48269ca9250d4d9b
>
> Let's take-apart that credential to see what's in there:
>
> hash:
>
Don't you mean "salt" above, instead of "hash:"?
> 04d9deb5 f6f1f206
> c7139a28 806e7ebd
> e8f44401 8e019116
> 8f8d0029 1d6e8719
> cd25cc82 eca073f9
> a925c005 aadf238b
>
> That's 48 bytes (96 characters) of data.
>
> iteration count: 1000 (easy)
>
> fingerprint:
> 22cb9257 949205ff
> bff01088 b46137cf
> 768dc67a 0faca26f
> 48269ca9 250d4d9b
>
> That's 32 bytes (64 characters) of data. SHA-1 produces 32-byte
>
I think you mean "SHA-256" here, right?
> output, so this looks good on the face of it.
>
Yes, it looks correct.
My issue is that I would like to run this "digest" from a servlet. How
would I do that?
I need to run it from a servlet because I need to enter it into my database
(in the format {salt}${iterations}${passowrd}).
>
> > I was not able to find an answer on online help forums. I also
> > couldn't find a way to call the initialized DataSourceRealm
> > Object's digest method when inputting the HashedPassword (ie: I had
> > to calculate salt and hash on my own using the SHA-1 algorithm).
> > Perhaps this also has something to do with why authentication is
> > failing?
>
> You probably weren't following the algorithm the same way. For
> example, the 1000 iterations is done like this:
>
> cred = password
> do 1000 times:
> cred = hash ( salt + cred )
>
> You probably forgot to salt the credential for each of the iterations.
>
Should I even be doing it this way? This relates to my previous comment: Is
there no way to call the same digest function that we ran from the command
line, in a servlet?
Indeed there is a digest method as part of the RealmBase API, I just don't
know how to get an instance of the RealmBase Object from the servlet.
>
> Take a look at the RealmBase class to see how the stored credential
> should be generated initially.
>
>
I looked at the RealmBase class:
https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/realm/RealmBase.html
I couldn't find where it mentions how to initially generate the stored
credential. Could you give me a little more direction as to where I should
look?
Thanks a lot again.
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJVXJ/UAAoJEBzwKT+lPKRYHZUQAKWVQoUhMr1QhBLBPmypX6By
> vQob26NzVU5h9C14CdiTuTJS1uc664yvgZHGkW3xfIKGlRmH0Kez/fuwO7ral1LX
> 4NWtkX1x2sRVTXZ5ZrEIcM9ofXrELqHCQmS3Jq7Y2VaXvAEvSNvsuY5kSh6+T8/w
> xEGyd509BU/QssidcQHGSjupxzlwbDngaWps2M4MW5JHfYBGzylNVw4tBpLwBEWm
> halR3EdHnIc/ReDCzelS9wH96onOAgMsnioh0ib/sC//5KVM6Mo1wh5IdTmQTcTp
> YF2Wj8QVMj8xaOrGMBqnEoimtY069QEJvaVeltmb0qle/ixKs7qbnrFUcR8Gpju3
> ytf1JEUSi29Pw+ct5GL7HPN66P1Y0OfevFLlcB4UUALfceaKrI41/yQBpr8fp7U6
> tMQ6fp6k11z92e2+MVgYosi2czpsRwJJO91GY85Ai2YlB8fLbQ9j3dv4Qzh1rl5m
> pF9B6G1zYLkXSEXk4ugEmHptTvDibPD9BSChnttZPUsLJN2oZfGBjZ2yEeKNpk4P
> 4xim6CiSfVFT6YNnKYmClzDOk4V+Lpo5uTLSHsd/GdueiSOoQXJmgRpoV7/uacWq
> J1QSUsyneNPVdrLosfTiidpgYCtTOKZSZ8OEdCiZV09m0JNnRcEoje3nNGYXlUg3
> 1EyyDLzlNZyDqRTYl+gJ
> =N8j2
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Fwd:
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Yuval,
On 5/20/15 9:34 AM, Yuval Schwartz wrote:
> I believe I am running tomcat 8.0 (although when I call the
> getServerInfo() method of the implicit ServletContext Object It
> tells me that I am running on 7.54)
Then you are not running Tomcat 8.0.x.
> I configured my realm element in my context.xml file as follows
> (based on the howto guide:
> https://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html):
If you are running Tomcat 7, the Tomcat 8 users guide may give you bad
guidance. If you are intending to run Tomcat 8, you might want to get
that fixed, first.
> <Realm className="org.apache.catalina.realm.DataSourceRealm"
> debug="99"
The "debug" attribute hasn't been supported for something like 10 years.
> dataSourceName="jdbc/board" localDataSource="true"
> userTable="test_user" userNameCol="Email"
> userCredCol="HashedPassword" userRoleTable="test_user_role"
> roleNameCol="Role">
>
> <CredentialHandler className="MessageDigestCredentialHandler"
> algorithm="SHA-1" iterations="1000" saltLength="48"/>
Oh, good: someone is using the CredentialHandler to improve their
security. You might want to:
1. Switch to a larger hash, like SHA-256
2. Find out how much time it takes to do 1000 SHA-1 (or SHA-256)
hashes on your server. You want the hashing to take more than a
trivial amount of time. Our services currently use more than 10k
iterations of SHA-256. This makes brute-forcing our password database
very time consuming for an attacker, if they were to capture the
database itself.
> </Realm>
>
>
> However, despite the password being stored in the format described
> in your "how to" manual (ie:{salt}${iterations}${password}),
> authentication fails. I assume that this is because something in my
> <Realm> configuration is wrong.
Tomcat can generate a hash for you from the command-line:
$ ./bin/digest.sh -a SHA-256 -i 1000 -s 48 'test'
test:04d9deb5f6f1f206c7139a28806e7ebde8f444018e0191168f8d00291d6e8719cd2
5cc82eca073f9a925c005aadf238b$1000$22cb9257949205ffbff01088b46137cf768dc
67a0faca26f48269ca9250d4d9b
Let's take-apart that credential to see what's in there:
hash:
04d9deb5 f6f1f206
c7139a28 806e7ebd
e8f44401 8e019116
8f8d0029 1d6e8719
cd25cc82 eca073f9
a925c005 aadf238b
That's 48 bytes (96 characters) of data.
iteration count: 1000 (easy)
fingerprint:
22cb9257 949205ff
bff01088 b46137cf
768dc67a 0faca26f
48269ca9 250d4d9b
That's 32 bytes (64 characters) of data. SHA-1 produces 32-byte
output, so this looks good on the face of it.
> I was not able to find an answer on online help forums. I also
> couldn't find a way to call the initialized DataSourceRealm
> Object's digest method when inputting the HashedPassword (ie: I had
> to calculate salt and hash on my own using the SHA-1 algorithm).
> Perhaps this also has something to do with why authentication is
> failing?
You probably weren't following the algorithm the same way. For
example, the 1000 iterations is done like this:
cred = password
do 1000 times:
cred = hash ( salt + cred )
You probably forgot to salt the credential for each of the iterations.
Take a look at the RealmBase class to see how the stored credential
should be generated initially.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVXJ/UAAoJEBzwKT+lPKRYHZUQAKWVQoUhMr1QhBLBPmypX6By
vQob26NzVU5h9C14CdiTuTJS1uc664yvgZHGkW3xfIKGlRmH0Kez/fuwO7ral1LX
4NWtkX1x2sRVTXZ5ZrEIcM9ofXrELqHCQmS3Jq7Y2VaXvAEvSNvsuY5kSh6+T8/w
xEGyd509BU/QssidcQHGSjupxzlwbDngaWps2M4MW5JHfYBGzylNVw4tBpLwBEWm
halR3EdHnIc/ReDCzelS9wH96onOAgMsnioh0ib/sC//5KVM6Mo1wh5IdTmQTcTp
YF2Wj8QVMj8xaOrGMBqnEoimtY069QEJvaVeltmb0qle/ixKs7qbnrFUcR8Gpju3
ytf1JEUSi29Pw+ct5GL7HPN66P1Y0OfevFLlcB4UUALfceaKrI41/yQBpr8fp7U6
tMQ6fp6k11z92e2+MVgYosi2czpsRwJJO91GY85Ai2YlB8fLbQ9j3dv4Qzh1rl5m
pF9B6G1zYLkXSEXk4ugEmHptTvDibPD9BSChnttZPUsLJN2oZfGBjZ2yEeKNpk4P
4xim6CiSfVFT6YNnKYmClzDOk4V+Lpo5uTLSHsd/GdueiSOoQXJmgRpoV7/uacWq
J1QSUsyneNPVdrLosfTiidpgYCtTOKZSZ8OEdCiZV09m0JNnRcEoje3nNGYXlUg3
1EyyDLzlNZyDqRTYl+gJ
=N8j2
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org