cross-posted from: https://zerobytes.monster/post/2458702
The original post: /r/mullvadvpn by /u/Imaginary_Dot5703 on 2024-08-14 05:20:49.
Regarding password managers:
All password managers keep data unencrypted in memory. You can’t encrypt the data in memory because then the application cannot use the data while it is running. It’s an universal issue for password managers, and not something that can be fixed.
While you can obfuscate the data, this is really security theater, because it is trivial to reverse engineer the obfuscation. In the future, Proton Pass may also obfuscate, but it doesn’t actually add any security.
If you enable PIN lock, the data is encrypted locally and cleared from memory when the PIN lock is activated. The security benefit of this in the case of a compromised device is likely marginal, as malware on a device would be able to key log the pin and bypass it in that manner. However, PIN lock can be desirable on a shared device (although somebody with access to the shared device could also install a keylogger…).
In the previous version of Proton Pass, after the PIN lock, it can take up to 30 minutes to clear data from memory, while the new version clears it immediately. It was previously immediate, but a code regression set it back to up to 30 minutes, but this has now been fixed. In general, for the reasons previously explained, we would not advise people to rely upon the PIN to secure against malware or shared devices, and that’s why PIN is not enabled by default, as the security benefit is likely marginal.
By the way, to even take advantage of this, somebody would need to have access to the device and the ability to access the device memory, in which case the PIN is not going to be effective because the device is already compromised. Unfortunately protecting against this type of device compromise is beyond the scope of Proton Pass (or any other password manager).
The unencrypted data should only be in memory when needed (copied to clipboard, shown on screen etc). After use the objects handling sensitive should overwrite themselves.
A string falling out of scope in C++, or an object being left to the garbage collector is still readable and not overwritten by default. It’s a very easy problem to solve in C++, either through custom allocators or destructors. But it makes a bigger difference when objects having short lifetimes
