-----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 <
> ch...@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 <
>>>> 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(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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
