> My point was that a would-be cracker would have access to both the > encryption key and the encrypted text. Using the pid as the key is > not made more secure by not storing it, since that cracker would also > have access to the hypothetical getpid() function; it just saves him > the trouble of accessing a variable to get the key. > > ~Matt
I'm not sure the point is really to stop a cracker. If someone has access to your terminal with your user privileges and the password is stored, encrypted or not, they can get at it, unless decrypting it requires typing a password which defeats the point, of course. Rather, I would think the value in this is more so that if you're working with somebody else observing and for some reason issue :let or such, your password doesn't magically appear on the screen in plaintext for all to see. Passwords usually don't appear on the screen in plaintext as you're typing them, and they shouldn't be easy to accidentally bring up in plaintext for anyone who happens to be watching to see. To solve the problem, the encryption needn't be strong--it just needs to be good enough that casual inspection wouldn't reveal it, i.e. not just rot13. Likewise, a plaintext password shouldn't be stored in a session file--better to store some garbage that can't be decrypted next time, and require the user to retype the password once per session. So, far from being an attempt to stop a cracker who has access to your session, which is a hard kind of cracker to stop, it's more an attempt to stop accidental discovery of your password, or to stop yourself accidentally revealing it (e.g. by saving a session--who'd have thought that could reveal your password?). That's my take on it, anyway. Ben. Send instant messages to your online friends http://au.messenger.yahoo.com --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
