StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I'm not aware of any specific <em>design patterns</em> regarding security of information on your .NET server application, however, ultimately, you can only do so much to secure any information that you request from the user, and specifically, <em>store</em>.</p> <p>If you are storing any user passwords that will be used for authentication that your own application will perform, the best way of storing this is with a salted one-way hash function. This way, the user is going to provide the password, manually, in plain text every time they authenticate with your application, and you will immediately hash that plain text password and compare that with the hashed password that you have stored. Any attacker, even one with access to the raw database, would have to brute-force reverse engineer all of your salted hashes. Not impossible (given enough computing power), but certainly improbable in all reality.</p> <p>If you're storing usernames/passwords that the user is providing to you, such that your application can then use these credentials to automatically "log into"/"authenticate with" another application or service on the user's behalf, well, I would suggest that you don't do this if security of that data is paramount.</p> <p>Put simply, even if you encrypt these credentials (whether that be symmetric or asymmetric encryption) ultimately, that data has to be used somewhere and for that to happen, it needs to be decrypted. This is the "weak link" in the security chain so to speak.</p> <blockquote> <p>Reduce the risk of user's sensitive information getting compromised if the .Net server's host operating system, in this case Window's Data Center Edition, is compromised.</p> </blockquote> <p>If this were to happen, all bets are off. Having the data stored in an encrypted form no longer means anything, as if Windows can decrypt that data, so can an attacker once he has access to the machine/OS. He wouldn't even need to attempt to "export" the private key from the Windows certificate store, as he could inject his malicious code further down the decryption chain and simply intercept the decrypted data as it comes out of the decryption process.</p> <p>Of course, the finest way of protecting your user's sensitive data is to never store it at all. Request it from the user each and every time, use it for whatever purpose you need it for, then dispose of it immediately. In the UK, the <a href="http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard" rel="nofollow noreferrer">PCI (Payment Card Industry) Data Standards</a> adopt this policy with regard to the <a href="http://en.wikipedia.org/wiki/Card_Verification_Value" rel="nofollow noreferrer">CVV</a> codes on credit cards. Merchants can store the credit card numbers, but never the CVV codes in their databases.</p> <p>If you <em>must</em> store the data, then by all means encrypt it, but be aware that encrypting it doesn't necessarily "secure" the data, it just adds another layer of what is effectively obfuscation for an attacker who can potentially compromise your physical machine or Operating System.</p> <p>If you are storing the data, you'll have to have as strong <em>perimeter security</em> (ie. <a href="http://en.wikipedia.org/wiki/Network_Security" rel="nofollow noreferrer">Network security</a>) as you can possibly get, precisely to prevent the potential for an attacker to gain access to the server's OS.</p> <blockquote> <p>Export the certificate and key and store them on a USB key which will be locked in a treasure chest and guarded by dragons,</p> </blockquote> <p>As well as a solid firewall and perhaps <a href="http://en.wikipedia.org/wiki/Intrusion_Detection_System" rel="nofollow noreferrer">IDS</a> system, you might want to get one of those dragons to guard your server, too! :)</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload