A few times over the last couple of days discussion about a tool on the Internet which can attach to your process and dump out the contents of your SecureStrings has come up. If this tool can exist, then what benefit does SecureString really provide?
The fact that this tool can exist is not a hole in the SecureString feature. Presumably at some point you'll want to be able to access the data you're storing in your string (after all, if you didn't want to ever access that data again, why store it in the first place?). If you're going to want to access it, then the process that did the encryption on the string data will need a way to decrypt the data again. So it's not a failure that code in your process can decrypt the SecureString contents, it's by design. (Note that to access the Marshal APIs which do decrypt the string, you need to be have SecurityPermission/UnmanagedCode -- or essentially be fully trusted. This means that arbitrary partial trust code in your process cannot in fact access the plaintext contents of your string).
Back in my original post about SecureString I mentioned several problems with storing sensitive data, such as a password in a standard System.String. SecureString solves these problems. Namely:
While the SecureString class does not prevent fully trusted code which is running in your process from decrypting the contents of the string and doing whatever it wants to do with it, it does provide several other features. It's all about risk management -- keeping the sensitive data as inaccessible as possible when it's not being used, and being able to erase your records of it when it is no longer needed.