Re: SecureString suggestion
From: Michel Comeau (darkbyte.pod_at_videotron.ca)
Date: Mon, 11 Jul 2005 19:24:46 -0400
It MIGHT not be the ultimate solution, but i'm going to accept that a binary
comparison returns to me true/false to tell me if the password matched much
better than having to decrypt the secure string and risk having it
unencrypted somewhere in code. I'm not uber insisting that the comparison be
binary, but they'd probably handle decryption and safe temporary storage
better then someone without experience would do it. Plus, it would make
comparing SecureString to string/SecureString much easier.
Personnaly, i dont see what would be exposed by having the code being part
of SecureString, which can access private members of both instances.
Where it matters to me is that i'd rather keep the typed password encrypted
then decrypt it and risk the decrypted text be part of a memory image, or
debug dump. Since the lenght of both encrypted string is known, it should be
easy to return false on a lenght difference, then if the length are equal,
return true if binary comparison was true, false otherwise. The encryption
is MS proprietary, they should be able to figure out the size of the
Apart from the possibility that microsoft uses a different key for each
secure string (which might be the case, i dont know), which other problem do
you see with the given suggestion ?
"Dominick Baier [DevelopMentor]" <firstname.lastname@example.org>
wrote in message news:email@example.com...
> Hello Nicole Calinoiu" calinoiu REMOVETHIS AT gmail DOT com,
> in addition to that - the strict binary comparison of encrypted strings is
> much dependent on the implemenation details of the encryption process,
> e.g. if the string is not always encrypted with the same master secret -
> at some point in time MS could decide to encrypt using session keys and
> entropy. Comparison wouldn't work anymore....
> Dominick Baier - DevelopMentor
>> Unfortunately, comparison of the encrypted strings isn't likely to be
>> very useful unless you're happy with a strict binary comparison.
>> Since binary string comparisons aren't generally particularly useful
>> (with the possible exception of passwords, which usually shouldn't be
>> stored in the first place), why should functionality that might expose
>> information about the stored string be added to the type?
>> "Michel Comeau" <firstname.lastname@example.org> wrote in message
>>> I was working on an Avalon sample using a PasswordBox, this control
>>> uses SecureString as its password storage media. The principle is
>>> very interesting except for what i consider a simple flaw in
>>> You can see the details in my suggestion on Feedback Center. I would
>>> appreciate if some of you did go and vote on this suggestion since i
>>> believe it would make SecureString even more secure, unless there is
>>> something i dont understand in SecureString.
>>> Here's the link to my suggestion:
>>> Michel "DarkByte" Comeau