[security-dev] Undertow / IdentityManager and Digest Authentication

[Darran Lofthouse]

Hello all,

(I am going to send my response to the thread that continued overnight 
in a couple of different e-mails - adding many points to one message I 
think will get confusing.)

If we do have an API that meets our needs I am no against using it at 
all however at this point I am a little concerned we may be dropping 
into similar problems we ended up with around JAAS.  i.e. we start off 
with simple username / password verification so a username and a 
credential and then we start trying to add more complex scenarios which 
need more workarounds and end up having capabilities restricted.

Initially my understanding was PicketLink IDM was an identity manager, 
what we are now starting to talk about is it becoming a general purpose 
authentication manager - but we also have requirements now moving beyond 
the account verification step.  As I mentioned before we are now going 
to require code related to HTTP authentication in a CredentialHandler 
and we are going to require code related to SASL authentication in there.

Regards,
Darran Lofthouse.


On 01/05/13 05:09, Shane Bryzak wrote:
> On 01/05/13 13:49, Bill Burke wrote:
>>
>> On 4/30/2013 9:53 PM, Shane Bryzak wrote:
>>> On 01/05/13 10:38, Bill Burke wrote:
>>>> On 4/30/2013 4:54 PM, Shane Bryzak wrote:
>>>>> There's two options here; the first one is to store the private key as
>>>>> an attribute which then makes it a piece of cake to retrieve the value:
>>>>>
>>>>> Attribute<PrivateKey> attrib = user.<PrivateKey>getAttribute("mysecret");
>>>>> PrivateKey key = attrib.getValue();
>>>>>
>>>>> The other option is to implement your own CredentialHandler as mentioned
>>>>> previously.  The design decision to insulate the actual credential
>>>>> values from the API was intentional, and at the moment the only time
>>>>> they are exposed to the API is when they are created for the very first
>>>>> time.  With there seemingly being a major password hack on the news
>>>>> every week it is in our best interest to reduce the number of attack
>>>>> vectors that make this kind of thing possible, hence the decoupled
>>>>> design.
>>>> Think about what you're saying here....  The credential isn't protected
>>>> at all because the code that is invoking the validation already has the
>>>> credential.  Its just not verified.  For two-way SSL its even more
>>>> pointless because you're validating the client with public certificates.
>>> Think about it from the perspective of an attacker who has gained access
>>> to the API via some vulnerability (yes, this has actually happened to us
>>> before).  If they were able to simply query the credential values
>>> directly from the IdentityManager they could start siphoning off
>>> password hash values for later use in a dictionary attack.
>>>
>> If they have access to the API then they can register malicious handlers
>> and get at the data anyways.
>
> Not at all, to do that they would have to somehow deploy an entirely new
> class to the application, which as I said in my previous e-mail is a
> totally different ball game to simply having access to the API.
>
>>
>>>> There's also certain credentials, i.e. a TOTP secret key, in which the
>>>> credential can't be stored as a hash.  So, isn't it possible for a
>>>> malicious programmer to register a malicious Handler so they can get
>>>> access to whatever information they want?
>>> Being able to register a malicious handler is a totally different ball
>>> game.  If the attacker has the capability to actually add new handler
>>> classes to an application at runtime then they effectively own the
>>> system anyway and there's pretty much nothing we can do about it from
>>> that point on.
>>>
>> So your point above is moot.  If the attacker has access to the api,
>> they can register malicious handlers, no?  There's also no reason a Java
>> SecurityManager couldn't sit in front of the API so that only certain
>> sections of code are allowed to access the API within the app server.
>>
>>> Remember also that we need this abstraction layer also because not all
>>> identity stores are even capable of storing credential values, at least
>>> not in a form that can be queried.  Take LDAP for example; in this case
>>> we don't actually perform any credential validation logic ourselves, it
>>> is delegated to the LDAP server itself.  Plus who knows which other IDP
>>> solutions we may wish to support in the future - with the design we have
>>> now we separate the concern of credential management and validation from
>>> the IdentityManager itself, and make it easily extensible via a simple
>>> 3-method interface.
>>>
>> So, I guess you're up shit creek[1] if your protocol requires the
>> credential to be hashed with any part of your request or response, which
>> is what Darren was complaining about I think.  Again, I still think
>> you're better off being able to query for credential values.  Basic Auth
>> and other password protocols can use the Handler architecture.
>> Protocols like Digest, OAuth1 and Amazon S3 Auth[2] would use the query
>> API to get at the credential and fail gracefully if the IDM can't
>> support that model.
>
> This is exactly the problem that the CredentialHandler SPI was designed
> to solve.  I'm not sure what the resistance is here to using it?
>
>>
>> [1] http://www.youtube.com/watch?v=2GqNstUJ3uY
>> [2] http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html
>>
>>
>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>