 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Security / August 2007Secure Credential's pwd handling
Hi, I need to provide my own network credentials to a web request (in a Windows Forms Application): HttpWebRequest req = ... req.Credentials = new NetworkCredential( userName, PWD, userDomain ); how to manage PWD from 'input by user' to 'NetworkCredential' in a security safe manner? Even using stuffs like 'CredUIPromptForCredentials' (rather than write a login dialog) the underlying String type is not secure. Also 'NetworkCredential' ctor's pwd parameter's type is a String. (Better if all this pwd passing could be done by 'SecureString'-like types, right?) thank you What threats are you trying to protect from? If this code is running on the user's workstation, then your biggest issue is that the user's plaintext password will be in memory there while you program is running. That may or may not be a problem, depending on what you are trying to protect against. Joe K.  SignatureJoe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- > Hi, > [quoted text clipped - 15 lines] > > thank you 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? > What threats are you trying to protect from? If this code is running on > the user's workstation, then your biggest issue is that the user's [quoted text clipped - 23 lines] >> >> thank you 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. SignatureJoe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- > Starting from UI 'asterisk-covered password' TextBoxes I red things like: > "...there are some serious flaws in the methods that Windows operating [quoted text clipped - 11 lines] > To conclude: why "SecureString" if keeping strings in my managed process > memory is secure enough? If the "attacker" runs in the same logon session - secure string won't buy you *anything*. try this tool http://www.acorns.com.au/Projects/Hawkeye/ ----- Dominick Baier (http://www.leastprivilege.com) Developing More Secure Microsoft ASP.NET 2.0 Applications (http://www.microsoft.com/mspress/books/9989.asp) > 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 [quoted text clipped - 15 lines] > > Joe K. 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 changes. What about this? >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 [quoted text clipped - 31 lines] >> To conclude: why "SecureString" if keeping strings in my managed process >> memory is secure enough? 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. SignatureJoe Kaplan-MS MVP Directory Services Programming Co-author of "The .NET Developer's Guide to Directory Services Programming" http://www.directoryprogramming.net -- >I totally agree. A managed secure "native mechanism" (attacker proof) from >UI elements to net requests credentials seems needed (it's easy obtain the [quoted text clipped - 44 lines] >>> To conclude: why "SecureString" if keeping strings in my managed process >>> memory is secure enough? Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.