Re: Credentials held unencrypted in memory during runtime
From: David Huang <khym_at_azeotrope.org>
Date: Tue, 12 Apr 2011 18:54:28 -0500
On Apr 12, 2011, at 6:17 PM, Ron Wilson wrote:
> On Tue, Apr 12, 2011 at 4:29 PM, David Huang <khym_at_azeotrope.org> wrote:
Well, then we're back to Stefan's question of how you think it could be improved. Earlier, you had suggested using a session key that perhaps could last through the work day, but I assume that means you'd need to reauthenticate when the session expired, so that's not going to work.
How are you going to encrypt a password so that SVN can decrypt it whenever it needs to, but another process can't do the same thing? SVN isn't any sort of privileged process; if it can get access to the decryption key, so can some other random process. Unless you go with some sort of executable-signing system where you *can* give SVN special privs to access its password store while keeping other processes out, but that's handled at the OS level, and is not something SVN needs to do.
As Stefan mentioned earlier, SVN uses the Windows CryptProtectData() function to encrypt passwords. The key is not fixed--it's apparently somehow based on the Windows login credentials. It is, however, easily regenerated--any process running under the same Windows login can call CryptUnprotectData(). The algorithm probably isn't extremely weak, although the algorithm used doesn't seem to be documented. So how do you propose to make the key something that's not easily regenerated?
This whole thing sounds like trying to find a problem where there is none. As others have mentioned, if an intruder can read your page file, or your hard disk, or has admin privileges, you have much bigger things to worry about already.
------------------------------------------------------
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
|
This is an archived mail posted to the TortoiseSVN Users mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.