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 majord...@metzdowd.com