4 ms·

All you can do if you don't trust the OS is to assemble the password at the point of use (each time) and erase the memory location directly afterwards. And eve

All you can do if you don't trust the OS is to assemble the password at the point of use (each time) and erase the memory location directly afterwards. And even that is not 100% foolproof (the OS can detect it in between these two steps).

mariusmg 14y ago
Or keep it encrypted in memory
- ars 14y ago
  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.
  - lucb1e 14y ago
    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.
    - ars 14y ago
      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.
  - biot 14y ago
    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.
  - mariusmg 14y ago
    Here is a concrete implementation : SecureString in .NET http://msdn.microsoft.com/en-us/library/system.security.securestring.aspx http://msdn.microsoft.com/en-us/library/system.security.secu... It's using DAPI which derives the encryption key from the user password.
- jayfuerstenberg 14y ago
  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.
  - ibotty 14y ago
    and how should that help? if you can read ram you can for sure read the executable file.
  - twelvechairs 14y ago
    > 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.
- ibotty 14y ago
  that was good!
Tichy 14y ago
Also, is there a way to erase specific memory locations, and a guarantee that in the meantime that memory location has not been cached somewhere else?

mariusmg 14y ago

Or keep it encrypted in memory

ars 14y ago
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.
- lucb1e 14y ago
  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.
  - ars 14y ago
    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.
- biot 14y ago
  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.
- mariusmg 14y ago
  Here is a concrete implementation : SecureString in .NET http://msdn.microsoft.com/en-us/library/system.security.securestring.aspx http://msdn.microsoft.com/en-us/library/system.security.secu... It's using DAPI which derives the encryption key from the user password.
jayfuerstenberg 14y ago
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.
- ibotty 14y ago
  and how should that help? if you can read ram you can for sure read the executable file.
- twelvechairs 14y ago
  > 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.
ibotty 14y ago
that was good!

Tichy 14y ago

Also, is there a way to erase specific memory locations, and a guarantee that in the meantime that memory location has not been cached somewhere else?