Category Archives: Web

Credit Karma Security

This review was performed on January 19, 2014 and is part of a series of comparisons of financial management sites.

Credit Karma is primarily a site that allows you to receive free weekly credit reports from TransUnion, but it also has financial management features.

creditkarma.com uses a EV certificate with a 2048 bit RSA key.

creditkarma.com receives an A- on the Qualys SSL Test run on February 11, 2014. They support TLS v1.1 or v1.2 and have also disabled SSL v3.0.

Security Claims

  • Our Security Practices
    • Secure Connection using 128 bit encryption/li>
    • Secure Connection using a DigiCert EV certificate
    • “Our data center is monitored around the clock by security personnel.”
    • “We enlist independent, third-party experts in the field of application security to assess our site for vulnerabilities.”
    • “Read-only Access”
    • “Firewalls and Other Security Precautions”
  • FAQ
    • “industry-leading security precautions”
    • “security is independently assessed by third parties.”
    • “128-bit encryption”
    • “servers are physically protected”
    • “We only use your SSN for this first score retrieval, and we do not store it in our database.”

Analysis of claims

Credit Karma says most of the right things, although more details would make me feel better about what they do say. Their claims about connections to their web server are consistent with the SSL Test. They mention the physical security of their data center and firewalls. The 3rd party assessment and testing of their site security is where I would like to have a little more detail. What are the qualifications of the 3rd party testers and what types of vulnerabilities are they looking for. The Credit Karma web interface is also designed so it is read only and does not provide a method to transfer money. It is comforting that Credit Karma does not store Social Security Numbers. They must establish some sort of authenticated token with TransUnion when retrieving a credit score for the first time.

The two things that Credit Karma does not discuss are protection of bank passwords and an Intrusion Detection System (IDS).

Inconsistencies

I only identified one relatively minor inconsistency between Credit Karma’s security claims and the observable security of the site:

  1. None.

Conclusion

Without protecting bank passwords or using an IDS, I can only give Credit Karma a C for their security policy.

Personal Capital Security

This review was performed on January 17, 2014 and is part of a series of comparisons of financial management sites.

Personal Capital is a relatively new service with the following goal: “to build a better money management experience for consumers. That’s why we’re blending cutting edge technology with objective financial advice.”

personalcapital.com uses a EV certificate with a 2048 bit RSA key.

personalcapital.com receives an B on the Qualys SSL Test run on February 11, 2014. They do not support TLS v1.1 or v1.2. Overall, not a major concern, but areas where they could easily increase the security of the connection to the site.

Security Claims

I wasn’t able to find much about Personal Capital’s security.

Analysis of claims

Personal Capital’s description of their security is concerning. There is only one very high level descriptions of their security. Their privacy policy claims they describe their security and answer common questions; however, none of those links work. Personal Capital does not describe any protections for protecting usernames and passwords stored in their database. The positives are that they have multi-factor authentication and constantly watch for suspicious activity.

Inconsistencies

With the very limited security claims, I was still able to identify

  1. “best technology” – Personal Capital does not use the “best technology.” They do not support TLS v1.1 or v1.2. Both of these provide better security than TLS v1.0 or SSL v 3.0.
  2. “military-grade encrypted algorithms” – Personal Capital supports triple DES which is only allowed if required by legacy technology of the (US) military.
  3. Linking to non-existent pages that claim to describe security.

Conclusion

I find the number of problems in Personal Capital’s almost non-existent description of security very alarming. I give their claims a F.

Mint.com Security

This review was performed on January 16, 2014 and is part of a series of comparisons of financial management sites.

Mint.com is run by Intuit, well known makers of Quicken and QuickBooks.

mint.com uses a EV certificate with a 2048 bit RSA key.

mint.com receives an A- on the Qualys SSL Test run on February 11, 2014.

Security Claims

  • Home Page
    • McAfee Secure Seal
    • VeriSign Security Seal
  • Safe and Secure
    • Bank-level security
    • “128-bit encryption”
    • Security Audits – VeriSign
    • Read-only
  • Safe and Secure “Watch security video”
    • Bank-level security
    • Security Audits – HackerSafe, VeriSign
    • Read-only
  • Security FAQ
    • “…bank login credentials are stored securely in a separate database using multi-layered hardware and software encryption.”
    • “Your bank account and credit card numbers are stored securely.”
    • read-only – “Your online banking user names and passwords are never displayed”
  • Security Technology and Practices
    • “Your bank login credentials are encrypted”
    • “Our servers are housed in a secure facility protected by biometric palm scanners and 24/7 security guards.”
    • “We apply bank-level data security standards. This includes encryption, auditing, logging, backups, and safe-guarding data.”
    • “We hack our own site. Intuit runs thousands of tests on its own software to ensure security. We scan our ports, test for SQL injection, and protect against cross-site scripting. We also employ Hackersafe to test our site daily.”
    • “Mint.com has received the VeriSign security seal.”
  • Privacy and Security Policy #12
    • “…use a combination of firewall barriers, encryption techniques and authentication procedures, among others…”
    • “…servers are in a secure facility. Access requires multiple levels of authentication, including biometrics recognition procedures.”
    • “…databases are protected from general employee access both physically and logically.”
    • “…encrypt your Service password so that your password cannot be recovered, even by us. All backup drives and tapes also are encrypted.”
    • “No employee may put any sensitive content on any insecure machine.”
    • “Intuit has been verified by Verisign for its use of SSL encryption technologies and audited by TRUSTe for its privacy practices. In addition, Intuit tests the Site daily for any failure points that would allow hacking.”

Analysis of claims

Overall, Mint.com says the right things. “Bank level security” is more of a marketing term that a real security claim, but 128 bit encryption is good enough for most uses. Looking at the SSL Labs scan, 128 bit AES or RC4 is the smalles key size mint supports.

In case an attacker can obtain your password, it is good that the standard user interface is read-only and does not display account numbers, usernames, or passwords.

It’s good that their site is tested by themselves, McAfee, VeriSign, and HackerSafe; because this is the most likely way an attacker could potentially access the database which contains bank credentials. Fortunately bank credentials are encrypted; however, the security practices do not discuss how the encryption key for bank credentials is protected. Firewalls are good, but a properly secured web-server shouldn’t really need a firewall. It would be nice if they also had an Intrusion Detection System (IDS) since an IDS has some chance to detect zero day exploits.

Physical site security of mint’s data centers and personelle policies are impossible to say much about how determined an attacker might be. Even with policies against copying customer data onto an unsecured laptops, humans always seem to be the weak link (e.g. Edward Snowden).

Everything Mint.com says about their security sounds good, except for the lack of an IDS. I give their security claims a B.

Inconsistencies

The only inconsistency in Mint.com’s security claims are the 3rd party tests and certifications performed. Mint.com consistently claims they have the VeriSign Security seal, but it is unclear whether the site is tested by McAfee or Hackersafe.

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.

Editing the WordPress Comment Form

I don’t collect email addresses or URLs for my comments, but never removed the default ‘Your email address will not be published.’ text from my comment form.

Removing the email address and URL fields was simple using the 'comment_form_default_fields' hook with the following code in my theme’s functions.php:

add_filter('comment_form_default_fields', 'remove_email_url');
function remove_email_url($fields) {
        if (isset($fields['url'])) {
                unset($fields['url']);
        }
        if (isset($fields['email'])) {
                unset($fields['email']);
        }
        return $fields;
}

I couldn’t find a simple tutorial for editing other aspects of the comments form and I didn’t want to dig into the theme and edit the /wp-content/themes/twentytwelve/comment.php file.
After poking around http://codex.wordpress.org/Function_Reference/comment_form and looking at the /wp-includes/comment-template.php, I realized the difference between the 'comment_form_default_fields' and 'comment_form_defaults' hooks.

'comment_form_default_fields' allows operation on the $fields of the comment_form.
'comment_form_defaults' allows modification on the $args of the comment_form.

Addition to my theme’s functions.php:

add_filter('comment_form_defaults', 'remove_publish_email');
function remove_publish_email($args) {
        $args['comment_notes_before'] = '
All comments are moderated.
';
        return $args;
}