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