Atwill.Com

Updated BlogEngine today because of a remote code execution (RCE) vulnerability, CVE-2019-10719 in versions 3.3.7 and earlier.  Good thing I am subscribed to the Full Disclosure mailing list (I highly recommend it.) otherwise I wouldn't have know about it.   Good luck to the other BlogEngine users out there.  I was unable to find any mailing list that would have sent a notification of this. 

You will have to download the latest release from the github repository directly.  Last time I checked the website link wasn't updated with the latest version.

Security Metrics has a good article about it here.

If your looking to use SSL/TLS with MySQL in .Net most tutorials will tell you to set the SSL Mode value in your connection string to Require.  This may make you think that you are good to go with authentication and encryption but you would be wrong.  This setting only enables encryption.  You must use VerifyFull if you want to add any type of authentication using certificate validation.

Connection string

Server=myServerAddress;Database=myDataBase;Uid=myUsername;Pwd=myPassword;SSL Mode=VerifyFull;

SSL Mode has the following values:

private bool ServerCheckValidation(object sender, X509Certificate certificate,
                                              X509Chain chain, SslPolicyErrors sslPolicyErrors)
{
      if (sslPolicyErrors == SslPolicyErrors.None)
        return true;

      if (Settings.SslMode == MySqlSslMode.Preferred ||
          Settings.SslMode == MySqlSslMode.Required)
      {
        //Tolerate all certificate errors.
        return true;
      }

      if (Settings.SslMode == MySqlSslMode.VerifyCA &&
          sslPolicyErrors == SslPolicyErrors.RemoteCertificateNameMismatch)
      {
        // Tolerate name mismatch in certificate, if full validation is not requested.
        return true;
      }

      return false;
}

Since there is a lot of talk and work recently on email encryption I thought I would attempt to list the requirements.  These requirements are a combination of things that I would want and some things that others have asked for.

1. Easy to use - Everybody and their Grand MOM should be able to use it.  That means it shouldn't take 20 minutes to apply for and setup keys and certificates.
2. TKO (Trust No One) - There can't be any organization responsible for holding encryption keys.  All keys need to be generated by the client and never leave the client.
3. Key Negotiation (Perfect Forward Secrecy) - No key should be able to decrypt a message after the fact.  That fact that your machine and key is compromised it shouldn't be able to decrypt all your messages from the past. 
4. Meta data protection - Headers must be encrypted.  The email headers can reveal a lot of information in addition to the Sender and Recipient information. 
5. Key Management - Keys need to be revoked and updated.  Losing your private key shouldn't mean you lose all your messages.
6. Compatibility - Should be able to work with most existing mail clients.  Without compatibility you will not get everyone on board.
7. Spam Free - Spam filtering techniques need to be leveraged to block unwanted encrypted emails.  These need to work as well as those available today on non-encrypted email.
8. Standardization – There needs to be a single agreed upon standard that allows all mail clients to compatible with each other.

 As you can see some of these are tuff requirements while some seem to contradict each other.  There is going to be a long road ahead for those attempting to standardize this. 

Not only should you follow the recommended way to hash passwords you should be using proven code that does it the correct way.   Now that these "proven methods" exists there is no need to write your own code because chances are you will make mistakes.   Crackstation explains this and provides source code that you can use. 

Here is Sophos minimum recommendation for safe storage of your users' passwords:

• Use a strong random number generator to create a salt of 16 bytes or longer.
• Feed the salt and the password into the PBKDF2 algorithm.
• Use HMAC-SHA-256 as the core hash inside PBKDF2.
• Perform 10,000 iterations or more. (November 2013.)
• Take 32 bytes (256 bits) of output from PBKDF2 as the final password hash.
• Store the iteration count, the salt and the final hash in your password database.
• Increase your iteration count regularly to keep up with faster cracking tools.

Whatever you do, don't try to knit your own password storage algorithm.

Top Security/Privacy Concerns Today – Not a complete list but some important items that not everyone is aware of.

Metadata – Metadata is the information found about data.  Even if your data is encrypted there is still a lot of metadata that can be just as revealing as the data itself.  Some examples include…

• Sending encrypted email – Hackers will still know whom it went to and when it went to them. 
• Bitrates - Certain traffic bitrates can be linked to movies, music, etc.…  
• Proxy Servers - Using an anonymous proxy?  Without random packet delay the traffic going out is easily match to the traffic going in. With this it’s not too hard to figure out what data is going where.

Lack of Perfect Forward Secrecy (PFS) usage - Many TLS implementations have refused to offer PFS.  Without this if a hacker ever obtains the private key even after the key expires all communications it ever encrypted could be decrypted.  Where do most people store their expired SSL keys?  Do they keep them just as secure as their active ones?

Lack of (PIE) Pre Internet Encryption – Unless the data you are putting on the Internet is encrypted securely using a secret key that is not stored on the internet your data is not truly secure.  

Difference of opinion – If company 1 needs the last 4 digits of your credit card in order to reset your password and company 2 gives you the last 4 digits of your credit card so you can see what card you are using this makes social reverse engineering very easy.  With enough pieces to the puzzle you can take over all accounts owned by a single entity.

Java/Java script – So many holes in the past and there will continue to be holes in the future.  Now that everything uses JavaScript.  Mozilla even removed the ability to disable this from their UI.  There are going to be many problems to come in this area.


References:

How Apple and Amazon Security Flaws Led to My Epic Hacking http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking/

Wikipedia JavaScript Security
https://en.wikipedia.org/wiki/JavaScript#Security

Pre-Internet Encryption - Gibson Research Corporation
https://www.grc.com/sn/sn-307.txt

Perfect forward secrecy
https://en.wikipedia.org/wiki/Perfect_forward_secrecy

There are lots of articles online that will teach you, "How to connect to a mail server using telnet and send an mail."  Lots of them have good information on SMTP command syntax.   The problems start when you are trying to do something that is hard or can't be done using telnet.   Because of this I wrote this handy telnet replacement tool for debugging SMTP.  Below are the top reason to use this to test with instead of telnet.

1. Authentication - Sending encoded strings using telnet requires you to build the authentication strings yourself using a mime tool.   This tool has authentication built in so you can just specify the user name and password.
2. TLS Encryption - This tool has the ability to connect using SSL directly or issue the StartTLS command and work securely.
3. Telnet protection - Many servers do not allow commands to be send one character at a time.  When they detect this they will disconnect you thinking you are a hacker.   This tool will buffer the response while you type and send the full command when finished.
4. Multihomed IP Address selection and binding - Telnet will always use the main IP on the machine.   When using this tool you can choose from any IP address on the local machine.  This makes trouble shooting IP address reputation issues very easy.   For example if a single IP is black listed you can easily test using that IP.
5. Remembering SMTP Commands - This tool has macros built in for MAIL FROM, RCPT TO, DATA, and many other commands so you don't need RFC 2821 with you while testing. 

The SMTP Server Connection Diagnostics Tool, released by SocketLabs, Inc. can be found here: http://www.socketlabs.com/smtp-server-connection-diagnostics-tool/

Here is a useful command for moving bulk IP's from one windows machine to another.

Export the ip's to a file.

c\>netsh interface ipv4 dump > c:\ipstomove.txt

then import the list to another machine.

c:\>netsh -f c:\ipstomove.txt

Things to note:  When exporting to the file it will export using the existing interface name.  If the new machine has a different interface name this will cause problems.  You can open the file in notepad and do a replace to correct this if needed.\

Additional Tip.  If you are adding a range of IPs you can use a loop.  The below command adds a C block of address or a /24 CIDR (255 ip addresses).  Again make sure you use the correct network adapter name.

FOR /L %I IN (2,1,254) DO netsh interface ip add address "Local Area Connection" 10.0.0.%I 255.255.255.0

There is a great blog post on the SocketLabs web site that everyone should read.  Its not about software but anyone involved in email should know the consequences of sending to a purchased email list.

Atwill.com is now the home of my new software development blog.  This will focus mainly on email related software development.