[security-dev] Undertow / IdentityManager and Digest Authentication

[Bill Burke]

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.

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

[1] http://www.youtube.com/watch?v=2GqNstUJ3uY
[2] http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com