And how exactly would that work? You would need to decrypt it use it - but then you need to store the decryption key in memory.

Gaining you exactly nothing.

Here is a concrete implementation : SecureString in .NET http://msdn.microsoft.com/en-us/library/system.security.secu...

It's using DAPI which derives the encryption key from the user password.

You could store the decryption key on the disk, only loading it when needed, and possibly byte-by-byte. This is all hackable, especially when such techniques are used mainstream, but it increases the amount of work needed to hack something. In the end it's the OS's responsibility of course.

What's the point of that? If you are going to do that, just store the original key that way.

Not that it helps in any way at all.

The .NET framework has a SecureString class which does this. It mitigates the risk of sensitive information being discovered through running 'strings' on memory dumps and the like. It's meant to prevent trivial recovery, not stop an attacker with sufficient time and skill.

You wouldn't need to encrypt it really.

Just don't store it character for character the same as the password when used to authenticate the user.

You could have the even characters in one array and the odd characters in another and this would make it a bit safer.

I'm not sure every app needs to be this paranoid but I offer it as an idea that can be easily implemented for those that do.

> Just don't store it character for character the same...

You've just described encryption here, whilst saying that its not encryption.

The principle is right though. A simple obfuscation will deter most attacks.

and how should that help? if you can read ram you can for sure read the executable file.