password safes for mac

[Nicolas Williams]

On Mon, Jun 29, 2009 at 11:29:48PM -0700, Jacob Appelbaum wrote:
> This would be great if LoginWindow.app didn't store your unencrypted
> login and password in memory for your entire session (including screen
> lock, suspend to ram and hibernate).
> 
> I keep hearing that Apple will close my bug about this and they keep
> delaying. I guess they use the credentials in memory for some things
> where they don't want to bother the user (!) but they still want to be
> able to elevate privileges.

Suppose a user's Kerberos credentials are about to expire.  What to do?

If Kerberos TGT renewable lifetime is set long enough then chances are
very good that the user will have to unlock their screen sometime within
a few hours of TGT expiration.  But what if TGT renewable lifetime is
set very short?  Or if the user doesn't lock then unlock their screen in
time?  You have to prompt the user.  But this could be an asynchronous
prompt coming from deep within the kernel (think secure NFS) -- not
impossible, but certainly tricky to implement.  And what if the user
were not using a graphical login (stop thinking Mac all the time :)?
You can't do async prompts on text-based consoles (though you can do
async warnings).

You can see where the temptation to cache the user's password comes
from.

The password can't be cached in encrypted form either (it could be
cached in string2key() form, but that's password-equivalent).  It could
be cached in scrambled form, or encrypted with a key that's stored in
cleartext or in a hardware token (think TPM), but ultimately it'd be
extractable by any sufficiently privileged process.  In any case, the
password must not end up in cleartext on unencrypted swap, and
preferably not on swap at all.

FWIW, Solaris doesn't cache the user's password.

Nico
-- 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com