On Wed, 2007-08-15 at 11:26 +0100, Darren J Moffat wrote:
> Alan Wright wrote:
> >> It's also worth noting that there is much existing practice which
> >> doesn't meet this standard, but there are also new mechanisms available
> >> that weren't there when much of that prior art landed in Solaris.
> >
> > If that is a requirement, we will use an existing reversible
> > encryption on the plain text before it is stored.
>
> But then where would you store the key to decrypt it ?
While this is definitely another case of "reduce to previously unsolved
problem", there is some value here -- if the key and the ciphertext are
separated even by a little bit, that reduces the risk when a partial
accidental disclosure occurs.
Recall that the "reusable passwords" policy cites one threat as:
While obfuscating the password will not protect the information
against a targeted attack, it will help mitigate the risk of
accidental disclosure (e.g., due to a system administrator using
'grep' on the directory in which the file is located).
Substitute "svccfg listprop" for "grep", and assume that there's an
untrusted user getting help from the sysadmin when the sysadmin
fat-fingers a command. If the property value is encrypted, the user
sees binary hash encrypted in a key that wasn't disclosed at the same
time. If the property value contains the cleartext password, the user
sees the memorable "xyzzy". If the sysadmin doesn't realize what
happened, "game over".
- Bill