Re: Secure Credential's pwd handling

That stuff would help. It isn't in there now though, so it doesn't solve
your immediate problem.

For now, you'll probably have to have a somewhat compromised solution.

One thing that is nice is that the NetworkCredential object actually
encrypts the data it stores internally, so it is a little better than it
looks on the surface. You still need to pass plaintext strings to it
though, so they'll be in memory until they get collected, as will the
strings that are produced when you read the properties.

Joe K.

Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
"Paolo Pagano" <ppagano@xxxxxxxxxxxxxx> wrote in message
I totally agree. A managed secure "native mechanism" (attacker proof) from
UI elements to net requests credentials seems needed (it's easy obtain the
window handler of a pwd TextBox... and all the WM_KEYDOWN party!)

Ok for previous .NET release, but overload will save us! I think something
like new kernel objects 'EncryptedString' and 'EncryptedTextBox' (no
unsecure WM_ and no unsecure reflection possible) with property 'Password'
of type 'EncryptedString'; we just need a new ctor: NetworkCredential(
string userName, EncryptedString password ) and that's all, no breaking

What about this?

"Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx> ha scritto nel
messaggio news:uFuutqm6HHA.2312@xxxxxxxxxxxxxxxxxxxxxxx
I completely respect your desire to try to make sure you do the best you
can in terms of securing this information. As you've seen, you still need
to transition to a plaintext representation to feed into the
NetworkCredentials object, so at some point the value will be in memory.
There isn't that much that you can do to prevent that.

If you need to store the password for multiple operations, you might
consider storing it in a SecureString and then converting it back to
string just when you need it, but it isn't clear that doing so will
provide you with a significant amount of protection. It is probably
better than doing nothing though.

SecureString is added to .NET to support this use case. The main problem
with it is that so many APIs from the previous version of .NET don't use
it and they have to continue to exist for backwards compatibility, so the
solution you get is incomplete. There isn't too much you can do about
this though.

Joe K.

Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
"Paolo Pagano" <ppagano@xxxxxxxxxxxxxx> wrote in message
Starting from UI 'asterisk-covered password' TextBoxes I red things
like: "...there are some serious flaws in the methods that Windows
operating systems protect this information..." (memory lookup by
malitious code? resident spy utilities?)

further: managed environment (GC delayed runs, moved/copyed objects),
read/write of processes memory pages to disk, ecc.. are all things
considered not 100% secure...

I Honestly don't know if these are real threats, just asking to myself
"I'm asking the user for network credentials: am I coding a security
hole in my .NET application? What's the best can I do?'".

To conclude: why "SecureString" if keeping strings in my managed process
memory is secure enough?