OWASP Top 10 for .NET Developers

http://www.troyhunt.com/2011/12/free-ebook-owasp-top-10-for-net.html

This article includes a link to a free eBook​ that includes content from all the related blog posts.

Excerpts from the author:
I knew – and many of us know – that unsalted hashes are vulnerable to a rainbow attack but I’d never actually executed one of these attacks myself. So I did. Same again on sniffing packets; knowing that lack of transport protection leaves network traffic vulnerable is one thing, sitting in the car outside McDonald’s and actually capturing wifi traffic and hijacking the session (my own, that is!) is another thing altogether.

My analysis:
Completed just the first topic so far. It's nice to see a step-by-step approach that shows the vulnerabilities being exploited, and ways to reduce those risks.

SQL Server encryption issues with mirrored db

We wanted to store some encrypted data in some fields. So, went ahead with this approach.

DBA creates a MASTER KEY encrypted with a password known only to him.
DBA creates a SERVER CERTIFICATE encrypted with this MASTER KEY.
DBA creates a SYMMETRIC KEY encrypted with this SERVER CERTIFICATE.

And then, we just have to open the SYMMETRIC KEY and provide it the name of this SERVER CERTIFICATE before executing any

OPEN SYMMETRIC KEY KeyName DECRYPTION BY CERTIFICATE CertName
-- Include this in a SELECT command
-- CONVERT(varchar(128),DECRYPTBYKEY(@encrypted_value))
CLOSE SYMMETRIC KEY KeyName

This worked well in dev & test environments. But, in prod, we would have a mirrored server as failover to improve availability. And hence when we tried this out before we went live, in perf/staging environment, we got these errors when we attempted to manually failover the primary db server.

Please create a master key in the database or open the master key in the session before performing this operation.
The key 'KeyName' is not open. Please open the key before using it.

When the use the DBA's master key, the queries work fine. But, we wouldnt like our queries to use the master key, would we?

So, it seems the DBA had created a certificate on each server with the same name. But, that means having 2 different certificates, one on each server, with just the name being common.

To get this in place properly, the DBA has to create a certificate on one server, take a backup, copy it to the other server, and then restore it on the failover partner. This way, both the servers would actually use the same certificate.

Some of these best practices are also mentioned here.
http://technet.microsoft.com/en-us/library/cc917681.aspx

Secure Network Protocols

SSH - Secure SHell
used to execute remote shell commands over a secure network
replacement for rsh (remote shell) protocol
http://en.wikipedia.org/wiki/Secure_Shell
SSH Communications Security (now Tectia) is a Finnish company that developed the Secure Shell protocol.

SCP - Secure CoPy
http://en.wikipedia.org/wiki/Secure_copy
uses SSH, used to securely transfer files between a local and a remote host
replacement for rcp, which stands for remote copy command in Unix
command-line arguments are based on the cp command to copy files locally

SFTP - Ssh File Transfer Protocol
http://en.wikipedia.org/wiki/SSH_file_transfer_protocol
extension of SSH2 to provide secure file transfers
not to be confused with FTPS which is FTP over SSL
http://en.wikipedia.org/wiki/FTPS

More to read
http://en.wikipedia.org/wiki/Portal:Cryptography

TLS/SSL
http://en.wikipedia.org/wiki/Transport_Layer_Security

TCP
http://en.wikipedia.org/wiki/Transmission_Control_Protocol

UDP
http://en.wikipedia.org/wiki/User_Datagram_Protocol

Packet analyzer
http://en.wikipedia.org/wiki/Packet_analyzer