Square Cash is a new service that allows individuals to send and receive cash via email (simply and easily). This comes from the company that brought merchant credit card processing to mobile devices with a credit card reader that utilizes a device’s ubiquitous headphone jack. However, utilizing email for this task seems like a fairly large gap in the security design. …Let’s take a look
Composing Cash
At the most basic level, Square Cash allows one person to initiate a payment to another person using a simple email. New users of the service, including the sender and the recipient, then receive links by email to enter their debit card information using Square’s SSL enabled web app. This links the email address and the debit card in Square’s system. There is no limit to the number of email addresses or debit cards that may be linked. As a merchant processor, Square is already aware of (and presumably compliant to) the various Payment Card Industry (PCI) requirements to securely accept, store, and process debit based transactions. For example, similar to Amazon and other services, Square saves debit card information in their system using encryption to protect the data, and a whole slew of other protection mechanisms and layered defenses. The question is: how does putting email in front of such a system affect the security? …According to Square it doesn’t, but I don’t see how.
Potential Pitfalls For simplicity, I will go on the assumption that the backend systems are fully compliant and mitigate every threat through technology, process, or procedure. The biggest problem I see is that email is not secure:
- Sending addresses can be spoofed
- Emails sent over unencrypted, or insecurely encrypted, connections can be tampered with
- Phishing sites are so prolific because they work.
- Sending a payment from the local coffee shop’s shared insecure wireless connection could be inviting fraud (anyone remember Firesheep?)
- A compromised email account could allow an attacker to send anyone payments
- Malicious websites could trick users into unwittingly making payments they didn’t authorize
- Compromised computers and mobile devices with saved email credentials suddenly become a payment gateway
Square’s web app server also appears to be configured to use the aging RC4 cipher suite to protect HTTPS connections. And, on top of all this, your use of Square Cash contains no limit to your liability for such transactions. It’s also not clear at this point (without trying it) what type of authentication is performed for subsequent transactions- but most everything I’ve read uses the word “automatically”.
Inane Insistence
So, how do these pitfalls play out? Well, first let’s not forget that nobody is perfect. While Square claims this process is secure, they’ve made that claim in the past and were called out on it. The Square mobile merchant device that uses the audio jack to transfer data between the magnetic card reader and the merchant’s mobile device originally used raw audio. Magnetic card data is typically read off the card as an “audio” signal that can be converted into the proper data- similar to older magnetic tape backup systems and compact cassette tapes of years past. The problem was that despite Square’s insistence that they were aware of the potential threat but deemed it a non-issue, the design easily allowed the creation of a “skimming” device that would allow an unscrupulous merchant or employee to skim their own copy of that data for any number of nefarious purposes while processing a legitimate transaction. Skimmers are a problem from a number of standpoints, including insider threat and third party tampering. Under pressure from Visa, newer versions of the device now utilize encryption. Are you comfortable entrusting your debit card information to:
- A company that insists it knows better than Payment Card Industry standards?
- A service that is looked upon by security professionals with a mixture of disbelief and a sense of impending doom?
I’m not, and that’s why I haven’t tried it out yet… even for the purposes of this blog! Unless there are some serious mitigating processes and controls in place, and until more details are made public, I would steer clear of the service lest one becomes the victim by which an expensive lesson is learned.
