Re: [GNU Crypto] Passwords Immutable?

[Casey Marshall]

>>>>> "Bryan" == Bryan Hoover <address@hidden> writes:

Bryan> Casey Marshall wrote:
>> Another idea: how about making passwords expirable? After a timeout
>> passes, the object could be automatically destroyed.
>> 
>> This could be a standard interface; an abstract class,
>> ExpirableObject, that implements destroyable and, on creation, is
>> registered with a timer that will call destroy() once the timeout
>> elapses.

Bryan> Yeah, good point.  I wasn't sure where to put the destructor
Bryan> call.  As it stands, the destructor is called when the
Bryan> mechanism is reset, in resetMechanism.

Bryan> I assume the objective is to cover for any situation in which
Bryan> resetMechanism is not called -- which could include client side
Bryan> crashing for instance, or just not calling it, which, asfaik is
Bryan> okay in terms of the SASL protocol specification (and perhaps
Bryan> something in addition to this?).

I think in general this sort of class will be useful, too. The idea
behind it being that if the programmer forgets that he has these keys
in memory, they will be wiped out after too long a timeout, in hope
that the memory there would not have been swapped to disk.

Bryan> In any event, in this light, resetMechanism is probably not the
Bryan> best place to put the constructor.

Bryan> So now that you mention it, why not destroy the password as
Bryan> soon as possible?  It's not needed beyond initialization is
Bryan> it?, so once that's done, perhaps that'd be the time to call
Bryan> the destructor.  Looks like that would be right after or within
Bryan> sendPublicKey.

I would say yes. Destroying sensitive data as soon as possible should
be the rule.

Bryan> I note that ClientMechanism implements dispose(), but it is
Bryan> empty, and is not overridden in SRPClient.  Perhaps this would
Bryan> be the place to put the destructor call?  But again, relies on
Bryan> client to make the dispose() call.

Bryan> There's also the ClientStore session timeout which causes the
Bryan> mechanism to be, if you will, ultimately reset -- that is,
Bryan> reset to the extent the session can't be reused.

I must admit that I'm not all that familiar with the SASL classes;
that was Raif's domain.

Attached is my first attempt at an ExpirableObject.

-- 
Casey Marshall || address@hidden

ExpirableObject.java
Description: Text document