[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xdi] $word(s) for digest-based comparison
If we are passing around the plaintext password, something is wrong. We don't want to be responsible for holding and possibly leaking this - authentication components should encapsulate the hashing and comparison.On May 21, 2013, at 2:21 PM, Drummond Reed <drummond.reed@xdi.org> wrote:From the minutes of last Friday's TC telecon:***************Markus then ran through the scenario of the XDI endpoint interfacing with an external password store. This exercise highlighted that even if the XDI message authentication token is sent via a secure transport (such as HTTPS), it is not accurate for an XDI link contract policy to use an $equals comparison operator because that operator is for to compare equivalent literal values, and the external password store has a hashed/salted value.
We ran out of time to complete the discussion, but agreed to the following action item:
# ALL: Suggest a new $word to express the semantics of “secure comparison”.
*****************In thinking about this action item, I like the idea of using XDI specialization, i.e., the ability to modify an entity, attribute, or relation by putting it in the context of another.In this case, the relation is $equals. The base definition of $equals is an exact match between two XDI literal values. The modification we need for this use case is that it's not an exact match between literal values, but a match between the digest of one literal value and a second literal value (that is already a digest).So one natural language way to say this in English is "digest comparison", i.e., make a digest, then compare it. To convert that into XDI specialization would suggest:$digest$equalsAlthough this specializes a $equals comparison to become a digest comparison, it is still very general, i.e., the XDI endpoint evaluating a $digest$equals comparison operator still needs to call code (or an external authentication service) that knows what kind of digest to compute for the comparison. That's fine, but if a particular link contract policy needs a particular kind or strength of digest comparison, it can further specialize $digest$equals. For example:$sha$384$digest$equals$salted$sha$256$digest$equalsThoughts?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]