[security-dev] Undertow / IdentityManager and Digest Authentication

[Shane Bryzak]

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.

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

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.

>
> I guess I'm back to suggesting that anything should be queryable that's
> stored in the IDM.  I do remember your chained IDM usecase, maybe
> instead of a validation() API a visitor API would be better?
>
> public interface IDM {
>
>      void accept(IdmVisitor visitor);
> }
>
> public interface IdmVisitor {
>      void visit(SecurityContext context, IdentityStore store);
> }
>
> Then somebody could still do whatever they wanted and be aware of the
> chaining.  Credential validation fits into the visitor pattern as well.
>