How can I encrypt a user's password in Silverlight?

views:

607

answers:

+3 Q:

How can I encrypt a user's password in Silverlight?

I have a Silverlight 3 app which connects to a server to perform various actions. My users log in using Forms Authentication but the actions they request are run on the server using the AppPool account so when they go in the audit logs they're recorded against the AppPool account. PCI DSS regulations now require that the user's own ID is in the audit logs which means the action must be taken using the user's creds. Now, I can save the user's creds when they log on and submit them with each request and the actions being taken by the server can use those creds. But the PCI regs say that if creds are saved they must be encrypted (to avoid someone taking a memory dump of the PC and getting the password).

The only way I can see of doing this is to get a public key from the server and encrypt the password with it, then submit the encrypted password and decrypt it on the server using the private key. But Silverlight doesn't have asymmetric cryptography.

I guess I'm too close to the problem and there must be another solution but I can't see what it is. Can anyone help?

CLARIFICATIONS

It's an internal application. Up until now, I've been using IIS Forms AuthN over SSL to Active Directory - I'm not worried about protecting the password in transit, just whilst it's held in memory on the client. As I understand it, because I'm using Forms Authentication, impersonation is not possible on the server unless I use LogonUser, which means I need the password on the server, so I need to transmit it each time, so I need to hold it in the client, in memory, until the app closes.

Encryption should never be used for passwords. When you encrypt something then it follows there should be a way to decrypt it. One way hashes should always be used for passwords. md5 and sha1 have been proven to be far too weak for any secuirty system. Sha256 should be used, and in silverlight this library will take care of it: http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha256%28VS.95%29.aspx

In fact storing passwords using "encryption" is recognized by the vulnerability family CWE-257. The use of a message digest is the ONLY way to safely store passwords. I didn't just make this up, this is coming from NIST. There are many other vulnerabilities that come up when storing passwords. Here is THE LIST that NIST has put together:

Rook 2010-02-09 18:21:46

This is fine in the transistory authentication process but its no use when the password needs to be stored, at some point somewhere a decryptable version of the password is needed.

AnthonyWJones 2010-02-09 20:32:30

@anthony you could not be more incorrect. the 2 message digests are always compared. The possibility of decryption opens the door to numerous attack vectors.

Rook 2010-02-09 22:38:01

@anthony, actually using hashes for transitory authentication could be bad becuase you could just replay the hash without having to break it. The use of a rolling salt could prevent a replay attack.

Rook 2010-02-09 22:51:52

@Michael: I don't recall mentioning anything related to hashes here. You're correct using some additional content in hash would prevent a reply attack, I'm not sure of relevence of this though. "2 message digests" what are you on about? You are suggesting that some "digest" thingy can be held over from one request to another and be re-used somehow? What is this "message digest" thing and how does it help the OP re-use previously entered credentials?

AnthonyWJones 2010-02-10 11:14:23

@anthony we are getting off topic here. "Transitory Authentication" is best done using SSL/TLS. A message digest function is the best for storage of passwords and the resulting hash should never be leaked to an attacker.

Rook 2010-02-10 17:21:16

@Michael: Ok I agree SSL/TLS is preferable. I'm still a little unclear on what a "message digest function" is exactly, how does this allow the password to be __stored__ for later use? And what do you mean by the "resulting hash" should never be leaked? Surely the resulting hash is needed to respond to a challange, how can that be then if can't send it back to the challanger. I'm confused please help?

AnthonyWJones 2010-02-11 07:48:32

Michael, I applaud your efforts to clean up SO with regards to correct and sound security solutions.@Anthony, Not to sound demeaning, but it sounds like you have a lot to learn with regards to security systems and cryptography. Why don't you invest in a good book or two, bone-up a bit on security, then come back and start "helping" others with their security questions. Check out: Intro to Modern Cryptography (Katz, Lindell) and Computer Security (Bishop).

Harley Green 2010-02-11 22:19:49

@Harley, thank you!

Rook 2010-02-11 22:40:45

@Harley: Alternatively, why don't you or Michael read through the questions I've raised above and actually answer them? After all if you are really that interested in cleaning up SO here is a perfect opportunity. So far I'm the only one here to actually offer the OP any form of a solution.

AnthonyWJones 2010-02-11 22:48:52

Thanks for the contributions. I'm sure you'll agree that it's impossible to provide all information when posting a question to a forum. Clearly, I missed out some critical stuff which I think Micheal/Harley you'll agree deals with your concerns. I was specifically concerned with the in-memory storage of the password and trying to be extra safe in that regard. Personally, I'd prefer to be using Windows Authentication but it's not an option. E.g. we're talking about elevated privilege creds which the users are not allowed to use to log onto their PCs.

ssg31415926 2010-02-19 07:44:49

@ssg31415926 My concerns where only if the password was being stored to the disk. If it is being stored in memory than any form of encryption will not help because it must be in plain text at the time of use. Thus a debugger can be used to observe the value by an attacker.

Rook 2010-02-19 14:37:11

Granted but the user's desktop is much more vulnerable than the server. The password would be encrypted on the desktop, transmitted in its encrypted form and decrypted on the server. No physical access to the server is likely and logical access is restricted to admin accounts.

ssg31415926 2010-03-10 11:05:15

+1 A:

Are you saying you need to store the password for re-use in the silverlight app? If you are concerned about the password appearing in memory un-encrypted then Silverlight then I think you're in trouble.

The .NET framework does have a SecureString class for exact purpose you outline.

Unfortunately the Silverlight version of the framework does not have this class. Hence even if you were to keep the logical storage of the password encrypted at some point your code would need to decrypt it before using it. At the point there is memory allocated containing the string in unencrypted form.

I don't know much about Forms authentication but if you can map the User principle to a domain user (which you seem to indicate you need) then you will want to use impersonation when running your code on the server.

Alternatively stop using Forms authentication and use Windows integrated authentication where you definitely can use impersonation server-side.

AnthonyWJones 2010-02-09 20:41:53

Message digests is the ONLY proper way to store passwords. By storing passwords using A block Cipher or Stream Cipher you are in violation of CWE-257 http://cwe.mitre.org/data/definitions/257.html. Please stop giving people insecure secuirty advice without a deep understanding of the exploitation process.

Rook 2010-02-09 22:41:33

@Michael: Your entilted to give your advice as you see fit and to comment and even downvote my advice. However please don't tell me what I should do. Security does seem to bring the zealot out of people however security a very relative thing. Good enough security from one perspective is entirely unacceptable in another.I haven't advised the OP to store an encrypted version of the string, I've pointed out that I don't think it can be done in Silverlight and given advice as to how the requirement might be avoided.

AnthonyWJones 2010-02-10 11:18:52

@Anthony The problem with security is that it "works" until you get hacked and there is no way for the OP to tell the difference. What you have proposed is a vulnerability according to NIST, and a CVE number could be issued if this was put into practice. This is very black and white. I respectfully ask you to stop answering questions relating to security and especially cryptography. I recommend reading "Piratical Cryptography".

Rook 2010-02-10 17:18:29

@Anthony It bothers me to see people that are asking legitimate secuirty questions and they receive security advice that is incorrect and as a result people get hacked. Security is very difficult and I have devoted a large part of my life working in this field. I am trying to clean up stack overflow and that makes me a zealot, I am sorry.

Rook 2010-02-10 17:35:24

@Michael: I can see that you feel very strongly about it but you can't force people to see things your way. The OP was asking how to store the password in encrypted form. I've found many years of answering questions that is best to first try to actually answer the question posed then if necessary steer the questioner away from a course that I feel may be unwise. If you read my answer carefully you will see I do the former but the latter and ulimately I indicated it could __not__ be done. I'm not quite sure why you've direct your zeal for the subject in my direction?

AnthonyWJones 2010-02-10 22:08:35

The OP doesn't know what he is doing and he is asking a fair question. You do not know the answer, but instead you are spreading dangerous knowledge to others. Further more, i am deeply unsettled that you fail to see why your approach is deeply flawed even when a higher authority (NIST) clearly states that it is. My motivation is simple, I'm trying to stop the spread of vulnerable code at the source. I hope that you read over the material that i have provided and learn from it so that you do not lead others astray.

Rook 2010-02-10 22:41:53

@Michael: Zeal is commendable, your approach is not. Your inability to be reasonable is undermining your cause. You repeatedly attack "my approach" which isn't in fact "my approach" its the OPs. My approach __as stated in my answer__ is to let existing authentication mechanisms do the work. BTW, how does windows handle this when it automatically sends windows credentials during NTLM challenge/response on an intranet? Since the user doesn't enter a password at that time where does it get the password in order to complete the response?

AnthonyWJones 2010-02-11 07:40:48

A vulnerability is not a solution.

Rook 2010-02-12 19:56:25

@Michael: I didn't offer a vunerability unless you consider the standard NTLM/Kerberos handshakes the vunerability? Perhaps you need to read my answer more carefully. I note with interest that you still remain silent on the questions I've included so far in this discussion and the one on your own answer above. If you want to remain credable you need to answer these technical questions not just give glib responses to your preference. I'm perfectly aware that I'm no expert, you want to swoop in clean things right? Get cracking then and answer the questions?

AnthonyWJones 2010-02-12 20:42:55

ansaurus

tags:

views:

answers:

How can I encrypt a user's password in Silverlight?

related questions