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;
}

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