Re: secret strings

[Ted Zlatanov <tzz@lifelogs.com>]

On Sat, 02 Apr 2011 01:14:16 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Ted Zlatanov writes:
>> OK.  I'll buy that.  So how, then, does the the producer, the
>> auth-source API, encourage consumers to wipe their secrets?

SJT> That depends on the security model, it seems to me.  For some
SJT> purposes, ROT13, with no secret at all, is sufficient "security".  In
SJT> other cases, the user is given a secret to be used once (eg, a
SJT> temporary password).  In other cases, the user may never see the
SJT> secret at all (public key methods).

OK.  All the code is already written to hide it in a lexical closure.  I
think it's possible at least to encode the secret and decode it on the
funcall.  It will, obviously, still be somewhere in memory but at least
not as visibly.  Then the consumer can use `with-secret-strings' in
their local scope.

SJT> The problem, as I see it, is that the auth-source doesn't know what
SJT> the consumer is going to do with it, or how long the secret will
SJT> remain valid.  I don't really see how this is the auth-source's
SJT> business.

It should at least try to hide secret data and help the consumer protect
the secrets from accidental revealing (thus the secrets closure it uses
currently).  Good neighbors can warn you if you leave your door open,
even if it's not strictly their business.

SJT> The `with-secret-strings' macro I suggested is the only fairly generic
SJT> kind of thing I can think of, but it's not really very general.

I'll put it in auth-source.el and suggest it in auth.texi; I'll also
crawl through the places that use auth-source and rewrite them to use
the macro.  So it will be useful--thank you for the suggestion.

Ted