Category Archives: Encryption

Comparison of Financial Management Sites

This compares the observable security and the security claims of popular financial management sites. The security policy reviews were spread over a period of time; however, all Qualys SSL Labs tests were re-run on February 11, 2014 to ensure consistent grading.

The following aspects of each site were considered:

Summary

Service / Site EV Qualys
Grade		 Security
Policy		 Inconsistencies Date Checked
mint.com Yes A- B 1 January 16, 2014
PersonalCapital Yes B F 3 January 17, 2014
Yodlee MoneyCenter Yes A- 1 A- February 5, 2014
LearnVest Yes B C 1 February 1, 2014
CreditKarma Yes A- C 0 January 19, 2014

If you have other sites you would like added, please add them to the comments.

Methodology

EV – Extended Validation

Extended Validation (EV) is important, because it provides additional assurance that you are communicating with the site you believe you are. A corporate-proxy, cannot (with the exception of InternetExplorer) impersonate an EV certificate. This is a simple yes/no whether the site uses an EV certificate to identify itself.

Qualys SSL Server Test

The Qualys SSL Server Test provides a good snapshot of the Certificate, Key Exchange, cipher suites, and protocol version supported by the servers to secure the connection between the web server and your browser. This is the Qualys SSL Server Test letter grade (A–F).

Security Policy Review

The connection between your browser and the web server is only one aspect of site security. The design of the website and its supporting database contribute to security. Without being able to sit down with a developer and analyze the the internals of the website, the posted security policy and practices are the best the general public can review. This is my letter grade of whether the security policy includes feasible protections and adequately addresses security threats.

Inconsistencies

To try to determine whether the security policies can be taken at face value, I’ve compared the security polices agains security aspects of the site that can be observed and verified by the general public. This provides a feeling of how accurate, and therefore trustworthy, the security policies are. Granted, some of the inaccuracies might be to make the security policies understandable by the average person. This is the number of inconstancies identified between different areas of the security policy and/or the actual website.

United’s Insecure Login Page

One of United Airlines login pages potentially sends login credentials in plaintext. www.united.com/web/en-US/apps/account/account.aspx (login page accessed by clicking “Sign In” in the upper right of the homepage)can be accessed over HTTP or HTTPS and the login form sends (POST) its contents to signin.aspx over whichever type of connection account.aspx was served from.

For a long time I didn’t think realize this was a problem, because even when www.united.com/web/en-US/Default.aspx is served over HTTP, it submits usernames and passwords over HTTPS.

It appears all United Airlines pages support HTTPS, so I recommend starting your use of United.com by browsing to https://www.united.com/.

Specifying an SSH Key Exchange Algorithm

I was doing some testing were I needed to test an SSH server’s support for various key exchange algorithms. I know PuTTY for Windows supports the configuration of key exchange algorithms, but I was testing in a Command Line only VM environment that already had a number of Linux clients running. It’s not obvious from the ssh man page or my searches (I found one site that said it’s not possible), it turns out to be almost as straightforward as setting your cipher or MAC algorithm. Just use the
-o KexAlgorithms=<comma_separated_list_of_algorithms> option.
<comma_separated_list_of_algorithms> can be any of the following:

  • ecdh-sha2-nistp256 – (elliptic curve nist-p256), limited support.
  • ecdh-sha2-nistp384 – (elliptic curve nist-p384), limited support.
  • ecdh-sha2-nistp521 – (elliptic curve nist-p512), limited support.
  • diffie-hellman-group-exchange-sha256 – (discrete log bits are negotiated), limited support.
  • diffie-hellman-group-exchange-sha1 – (discrete log bits are negotiated), limited support.
  • diffie-hellman-group14-sha1 – (discrete log 2048 bits), should be good for now, and widely supported.
  • diffie-hellman-group1-sha1 – (discrete log 768 bits), might not be strong enough, but widely supported.

Note: The elliptic curve algorithms are believed to be as strong or stronger than the standard Diffie-Hellman discrete log cryptography; however, they are newer and have not been as thoroughly analyzed.

Example: ssh -o KexAlgorithms=diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384 kenji@192.0.0.45

Securing Administration of Shared Hosting

If you didn’t already know, ssh can be used to tunnel a single TCP port from the client to the server. I wanted to use this ability to prevent my site credentials and cookies from being sent in plaintext over the internet (since I’ve been trying to avoid paying for SSL/TLS). This works on Dreamhost, but should work on pretty much any shared hosting provider that allows you to ssh into the server.

In short it takes a few hacks to get everything to play together and requires super user privileges on the machine you are connecting from, but does not require any special privileges on the remote server.

First establish a specific subdomain (or alternative domain) to ssh into (for example ssh.tidgubi.com). This will prevent DNS conflicts with the main domains (www.tidgubi.com and tidgubi.com).

Next edit your local hosts file. Create entries so your computer resolves your webserver to your local machine (127.0.0.1 www.tidgubi.com).

Login with an administrator account or console session (for a long time I didn’t realize you could just open a console and type login <admin_account>).

Create an ssh tunnel between your computer and your webserver by running command sudo ssh kenji@ssh.tidgubi.com -L 80:www.tidgubi.com:80
This command breaks down as follows:

  • sudo – requires root permissions to listen on local port 80
  • ssh – run the ssh client program
  • kenji@ssh.tidgubi.com – username and ssh server
  • -L – specifies local port forwarding
  • 80 – local port to listen for data on
  • www.tidgubi.com – remote webserver. This is resolved by the ssh server, so it does not conflict with the hosts file change
  • 80 – remote port to forward traffic to. Assuming you’re forwarding traffic to a standard webserver, this should be port 80

Notes

  • This does not work well if you try to use a different local port, because different servers and web-apps redirect traffic differently and may override explicitly set ports in the URL
  • This commands only forwards traffic coming from the local client. You can add the -g option to the ssh command if you want to allow other computers to send data to the webserver
  • Ideally you can ssh directly into your webserver, so the forwarded traffic does not get sent out on any network once it is plaintext again.

Next use .htaccess to restrict access to administrative pages.