[security-dev] Undertow / IdentityManager and Digest Authentication

[Shane Bryzak]

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
>
>