I'd been asked by several people around about the equivalent to SecureString Class (as in .NET) in Java. Is there one, that behaves like SecureString Class, or can be by any means simulate one?
You know what, even I have never worked on .NET, but I wanted to clarify as lot and lot of people ask me about this.
Rob Prime wrote:I don't get its purpose. It may be secure, until you need to read it.
This is precisely its purpose - it stays secure when program does not need it.
If someone does a heapdump and analyse its content, secured string stays secure.
If program (for example an applet running on user machine) stores passwords in memory using strings,
it is very easy to discover them in java using standard JDK tools available to download for everyone.
Ulf Dittmer wrote:It would involve storing the encrypted string in a byte, and only decrypting it when it gets accessed (or whenever the contents of the string are altered, and then re-encrypting it). Any intermediate cleartext should be stored in local variables, not instance variables.
Ok Ulf, But I doubt this would be the way, how SecureString is implemented in .NET.
With native code it is possible to secure memory regions (although I don't remember how). That's what you'll need in the end.
However, in that case, we must keep the "Encryption Key" at a memory location, which is "Relatively Safe", may be in Kernel space (but I don't think it’s possible in Java to specify a specific memory location for a variable).
Frankly speaking, no idea! I never needed to assign a specific memory location to a Java variable.
Ah..!! Again, I am Stuck..!!
Ulf Dittmer wrote:What does it matter what .Net does?
He he.. ;-) It doesn't.
Clarence J M Tauro wrote:Well, if we have access to the char/byte array which is actually storing the string, (which actually would be a part of a class, say SString), then we can apply some block encryption algorithm on it, say DES or AES. So, even if our string gets captured, it is encrypted, and hence safe!!
But to add something you need to decrypt the current contents first, then add to it, then encrypt it again.
A clever man travelled the world with a jar making money from a particular bet that he made with those he came across. The man would fill his jar up with rocks and ask onlookers put their money in for double the return when they thought his jar was full. When the rocks piled to the top of the jar, most of the crowd would place their bets and think themselves a winner whilst others would look on in curiosity. To their disappointment the man would pull out some smaller stones, place them on top and give it a little shake till they fell in between the others. A few others make their bets then only to watch the man tip a handful of sand into the jar and still manage to fit more in. By now there seems to be no more free room in the jar and the lucky few left think they have it in the bag. But surprisingly, the man picks up his drinking water and tips the last few mouthfuls into the supposedly full jar. By now the man has become much the richer and he continues on to the next unsuspecting crowd.
If tl;dr, the point is there will always be a vulnerable window of opportunity in any security context. The idea is how small is small enough for your requirements.