Best practice SecureString and pswd collection -- dotnet security

dotnet security : Best practice SecureString and pswd collection

Mitch Gallant
3/30/2006 8:49:48 AM

Using .NET 2 managed code only, what is the best that
can be done security-wise in collecting a password from
the user (as console or some pswd control dialog) and
passing to a function (like X509Certificate.Import)
which can accept a SecureString?

What about pinvoking to access a secure password dialog
input? Going out of managed code, but does this remove
immutable string input ?

- Mitch

Mitch Gallant
3/30/2006 10:37:45 AM

Hi Henning,

Yup .. I'm already aware of pinvoking like that ..
looked at 2 references herein:
http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/156736d67df0b2e9/7d58cd0be12e5d4c

But there should obviously be a managed simplified wrapper fn which
simplifies this procedure. Should be a nice simple .net implementation
to prompt a user for providing a pswd which securely manages the memory of
the string and returns a SecureString to be used by (granted few)
functions that accept a SecureString arg.

Cheers,
- Mitch Gallant

[quoted text, click to view]

Mitch Gallant
3/30/2006 10:56:54 AM

Thanks Henning. Good article.

I'm looking for some commentary from MS on this also .. to see what
plans exist to implement secured credentials prompting in future
..NET releases.

Trying to dig into the api used in the generic IE export to pfx
and the pswd dialog that is used there (probably some internal
fn based on CredUIPromptForCredential ).
I'm updating the keypal.exe .NET tool to include pfx exportation,
so am idling on how to implement the pswd prompting :-)

Cheers,
- Mitch Gallant
MVP Security
jensign.com

[quoted text, click to view]

Henning Krause [MVP]
3/30/2006 5:02:33 PM

Hello,

you can use the CredUIPromptForCredential function.

If you google for this, you will find plenty of implementations. I've one on
my website, too :-)

http://www.infinitec.de/software/nettoolbox/infinitec.security.aspx

Greetings,
Henning Krause

[quoted text, click to view]

Dominick Baier [DevelopMentor]
3/30/2006 5:20:42 PM

Hi,

there will be more classes that use SecureString in .NET 3.0

Avalon (WinFX) contains a Password Textbox that returns a SecureString -
not sure if SS is used anywhere in WCF or WF

---------------------------------------
Dominick Baier - DevelopMentor
http://www.leastprivilege.com

[quoted text, click to view]

Henning Krause [MVP]
3/30/2006 5:45:45 PM

Hello,

my implementation is a CommonDialog, which can be dragged on a form and
invoked easily...

Greetings,
Henning Krause

[quoted text, click to view]

Henning Krause [MVP]
3/30/2006 6:01:02 PM

Hello Mitch,

you're right.. this should have been in .NET 2.0. Along with broader usage
of the SecureString class (SqlConnection, etc.)

Henning Krause

[quoted text, click to view]

Mitch Gallant
3/30/2006 11:53:56 PM

Just noticed that there's a useful .NET 2 sdk SecureString console sample app:
http://msdn2.microsoft.com/en-us/library/07b9wyhy.aspx
which uses a lot of the greatly expanded Console capability .. to parse single
keystrokes. The sample has some other useful parts; interesting title:

Console.Title = "Fanatical Health Entry System";

The basic code for building the SecureString from keystrokes is:
----------------------
SecureString password = new SecureString();
...
ConsoleKeyInfo cki = Console.ReadKey(true);
....
password.AppendChar(cki.KeyChar);
-----------------------

By comparison, this is the simpler approach:
-----------------
String pswdstr = Console.ReadLine();
Char[] chars = pswdstr.ToCharArray() ;
SecureString password = new SecureString();

for(int i = 0; i <= chars.Length - 1; i++)
password.AppendChar(chars[i]) ;
-------------------

From a security perspective, are these equivalent? i.e. does the
ConsoleKeyInfo actually expose any string content related to
the clicked key characters that is immutable?

- Mitch Gallant
MVP Security

[quoted text, click to view]

Henning Krause [MVP]
3/31/2006 12:00:00 AM

Hello Mitch,

[quoted text, click to view]

This way, you again have the password in string representation, and you
don't know when that instance is garbage collected.

Greetings,
Henning Krause

[quoted text, click to view]

Mitch Gallant
3/31/2006 12:00:00 AM

Yes I know this. I was wondering about the other implementation
(with ConsoleKeyInfo class) which looks like a safe way to get
user data into the SecureString object.

- Mitch

[quoted text, click to view]

Henning Krause [MVP]
3/31/2006 12:00:00 AM

Hello Mitch,

you asked whether the two implementations are equivalent. And I would say
no, because ConsoleKeyInfo just keeps one char in it's structure.

There is never a string exposed. So I would assume this as a (relatively)
safe way to get the password.

Another option here would again be the Credential API:
CredUICmdLinePromptForCredentials. Unfortunately, this version is not as
configurable as the CredUIPromptForCredential method.

Greetings,
Henning Krause

[quoted text, click to view]

Valery Pryamikov
4/1/2006 12:00:00 AM

Hi,

I believe that SecureString is actually overrated. All it can protect
against is side channel attacks i.e. password exposed by:

a. adversary is able to read memory of your process.

b. adversary is able to read page file when the memory page containing the
password is paged to the file.

c. much more advanced, processor dependent and quite unrealistic attacks,
like measuring cache line re-initialization delays and correlating them to
clear text password.

but the bottom line is: Adversary either has to high privileged process or a
physical access to your computer.

Protecting the password in this threat model is kind of misnomer.

If someone can read page file by booting from separate media - what stops
them from changing your password, or injecting new local account, or just
plain reading all the secrets from your harddisk? You say - full volume
encryption, but in this case - the page file will be encrypted as well and
the secure string gives you nothing...

And if someone has access to your process memory, then secure string is not
going to protect your password either, because in the latter case it is
possible to recover encryption key which is used for encrypting the
password. It probably would not be a trivial attack, but it is still
possible (think for example of a debugger's breakpoint on memory access).

The thing is that SecureString takes its origin from middle of 90th when
someone reported that Windows NT stores clear text passwords on hard disk...
which appeared to be just a page file... and to access this page file one
had to boot from separate disk (it was floppy disk that time) ... and to
reproduce that one had to cut off the power of Windows NT box at precise
point of time... Very unrealistic attack scenario! But nevertheless it
caused a lot of noise including publication in the big new media and
newspapers. Since than Microsoft started to encrypt passwords in memory and
that grown up to a SecureString nowadays.

Secure string could only mean something if Windows would support mandatory
access control and set of protective features similar to IBM 4758
cryptographic processor (see http://www-03.ibm.com/security/cryptocards/ ).
But we all know it will never going to happen (it simply is unreasonable to
expect that level of protection without reliance on highly customized and
extremely expensive hardware).

-Valery.

http://www.harper.no/valery

[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages about dotnet security

home · blog · groups

Questions? Comments? Contact the dn