At Simple, we acknowledge that it’s our responsibility to be prudent about the extent to which we talk about how we ensure our customers’ safety. But there are many components of our business that are not appreciably strengthened by secrecy; obscurity is not a critically important part of our security program. In keeping with our core cultural commitment to be as open and transparent as possible, we’d like to take a few moments to describe some of the mechanisms that we use to keep our customers safe.
A rapid increase in web services that require the use of encryption has led to a proliferation of companies to fill that need. With the entry of firms that perform minimal validation of the owners of sites to which SSL/TLS certificates are granted, the barrier for obtaining a “valid” certificate has lowered significantly over the last decade. If your e-mail address is listed as the owner for a domain name, you can obtain a certificate for that domain that will be accepted by all major web browsers.
For services that involve financial transactions and information, that’s not good enough. Our customers need to have some level of comfort that their financial institution actually owns the certificate that’s being used to secure their financial data. Extended Validation (EV) certificates provide that extra level of assurance. Those certificates attest that the issuer, known as a Certificate Authority (CA), has performed more extensive validation of the certificate holder than is required of traditional certificates. CAs take steps to confirm the legal identity and operational and physical presence of the underlying entity of any EV certificate that they issue.
Most browsers indicate the use of a valid EV certificate with an enhanced display that generally includes the name of the company that owns the certificate, the name of the CA that issued the certificate and a distinctive color (e.g. green).
Valid, non-EV certificates are generally accompanied by just a lock icon.
Web browser and operating system vendors play an important role in the SSL/TLS ecosystem. A web browser trusts a certificate because that certificate has been vouched for (signed) by a CA that the browser is configured to trust. Although the user does have control over that list of trusted CAs, it is more frequently updated by the web browser or operating system vendor (e.g., Google, Apple, Mozilla, Microsoft).
In certain rare instances (although they are becoming more common) a trusted CA’s systems may become compromised and the compromiser may be able to issue certificates for sites that the attacker does not own. Because those certificates are issued and signed by a CA that a web browser is configured to trust (if the compromise is not immediately detected, reported, and browsers updated by their vendors), an attacker may be able to use those certificates to trick that browser into accepting the attacker’s certificate instead of the certificate provided by the intended provider. In what is known as a Man-in-the-Middle (MITM) attack, the attacker could intercept network traffic, decrypt it, read the data, re-encrypt it and send it on to its intended destination with neither side being the wiser.
Technologies are evolving around a concept called “pinning” that will help guard against CA compromises. The general idea is that a company can more specifically identify the certificate that a client should accept by preloading the public certificate on to the client device.
To be effective for use by web browsers in general, explicit pinning functionality will need to be added by the browser vendors (as described by the TACK proposal created by the TLS Working Group or by the Public Key Pinning Extension proposed by Google). For mobile applications where a company-specific application is loaded onto a device (e.g., the Simple iOS and Android applications), we can take matters into our own hands.
Simple’s iOS developers have made some improvements to AFNetworking, the networking framework used by our iOS mobile application, specifically to add pinning functionality. In this commit, those changes were merged into the public repository for that library and are in use today in the currently available versions of our iOS application. With those changes, our application will only establish connections with Simple servers and will reject any attempts to connect with an unauthorized system, even in the event of a CA compromise. Similar changes were also implemented in our Android application prior to its public release.
Host Strict Transport Security (HSTS)
Even a perfect implementation of SSL/TLS can be circumvented by an attacker who simply intercepts the traffic and strips the SSL/TLS before relaying it to the client. The client should notice that the relayed URL begins with “http://” instead of “https://”, but that could easily be overlooked. To protect Simple’s customers against that vulnerability, we’ve enabled HSTS for all connections to our application. When a browser receives an HSTS header for a site, that browser knows that it should never request that site without encryption, so thwarting future MITM attempts that strip the encryption between the client and the server.
Enabling the HSTS response header will not ensure that a browser’s initial connection is performed over HTTPS, however; there is a small window of time that an attacker could exploit the client browser’s lack of familiarity with a new site. To eliminate that vulnerability, Simple’s sites are included in a list of preloaded HSTS entries maintained by the Chromium project. That list is used by Chrome and other browser projects to seed their own lists, so customers that use those browsers will always make secure connections to Simple.
Content Security Policy (CSP)
Cross Site Scripting (XSS) is identified by the Open Web Application Security Project (OWASP) as the third most critical security risk for 2013. XSS has been a steady fixture on that list since at least 2004.
Simple developers have been working to implement CSP in to our products. Combined with existing controls that guard against XSS and other attack vectors (e.g., input/output validation, query parameterization, etc.), our deployment of CSP will contribute an additional layer of defense to help us keep our customers secure.
Every member of the team here at Simple is committed to providing world-class security to our customers and partners. Wherever possible, we strive to leverage the latest advancements in security and the most effective controls to adapt to the endlessly changing threat landscape. If you have any questions, comments, suggestions or concerns about security at Simple, feel free to email the Simple security team at firstname.lastname@example.org. To communicate sensitive information to the security team via e-mail, please use the GPG key posted here. Thank you!
Great! We're happy to hear that!
Do you have any feedback to pass along?
We've saved your response. Thank you for your feedback.
Please let us know how we can do better next time.
Thank you! We appreciate the feedback!
Disclaimer: Hey! Welcome to our disclaimer. Here’s what you need to know to safely consume this blog post: Any outbound links in this post will take you away from Simple.com, to external sites in the wilds of the internet; neither Simple or our partner bank, BBVA USA, endorse any linked-to websites; and we didn’t pay/barter with/bribe anyone to appear in this post. And as much as we wish we could control the cost of things, any prices in this article are just estimates. Actual prices are up to retailers, manufacturers, and other people who’ve been granted magical powers over digits and dollar signs.