Google Wallet Stores Some Payment Card Data In Plain Text
'Significant' amount of unencrypted data leaves Android phones at risk, researchers say
December 12, 2011
Google's much-anticipated mobile payment application locally stores some sensitive user information unencrypted, such as a cardholder's name, transaction dates, email address, and account balance, new research released today reveals.
Researchers from viaForensics tested the security of Google Wallet -- which lets consumers transact credit-card charges, redeem gift cards, and use loyalty membership cards in stores from their phones -- on rooted Android smartphones and found that the app leaves sensitive data in the clear. While Google Wallet hides the full credit-card account number, the last four digits reside in plain text in the app's local SQLite database.
The good news is that viaForensics confirmed that the app does repel man-in-the-middle attacks, and is protected by a PIN to conduct transactions with the cards.
But the apps' SQLite databases resident on the Android phones included credit-card balance, limit, expiration date, cardholder name, and transaction locations and dates -- information that viaForensics says could be used, for example, as a way to social-engineer the actual credit-card account from the cardholder.
[ A debate is whirling around the hype of mobile malware and the solutions we have to fight it. See "Rethinking Mobile Security." ]
"They underestimated the value of data that consumers are not comfortable with [being exposed]," says Andrew Hoog, chief investigative officer for viaForensics. "I'm not comfortable with someone knowing my credit limit or when my payments are due ... If you had that type of information, you could effectively do a social-engineering attack that could get [an attacker] access to an account."
Meanwhile, a Google spokesperson points out that the viaForensics report is based on research conducted on a rooted Android smartphone. The report also applauds the layered security built into the OS and app, the spokesperson says. "The viaForensics study does not refute the effectiveness of the multiple layers of security built into the Android OS and Google Wallet," the spokesperson says. "But even in this case, the secure element still protects the payment instructions, including credit card and CVV numbers.
"Android actively protects against malicious programs that attempt to gain root access without the user's knowledge."
But Andrew Hoog, chief investigative officer for viaForensics, says dismissing security weaknesses in Wallet just because they were discovered on rooted phones is moot. Some 10 to 15 percent of smartphone users "root" their devices, he says, and his firm had to root the phones in their research in order to access data under the app data directory, he says. Plus there's plenty of malware that roots phones remotely, he says.
"If you think about the number of folks who have root and the fact that on every single major iOS and Android released people have been successful at getting root quickly, and that there are remote exploits capable of doing this remotely over a network ... we feel that these threats" of exposed data are relevant, he says.
The bottom line is Google needs to either encrypt all of the sensitive cardholder data or not store it locally, he says.
"We give Google credit for putting a PIN on the app," Hoog says. "But if you have to store [sensitive] data, don't store it plain text."
Meanwhile, Google did fix a couple of other flaws viaForensics had pointed out: where data was still recoverable after a transaction was deleted or Google Wallet was reset, and a feature where a recoverable image of a credit card showed name, expiration date, and last four digits of the account. Both of these issues were fixed in Version 1.0-R33v6 of Wallet.
"With the amount of data that can be pulled off and the fact that this is a payment app, Google has to be held to a higher level" of security with Wallet, he says.
ViaForensics posted its full analysis of Google Wallet's security issues here.
Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.
Read more about:
2011About the Author
You May Also Like
Unleashing AI to Assess Cyber Security Risk
Nov 12, 2024Securing Tomorrow, Today: How to Navigate Zero Trust
Nov 13, 2024The State of Attack Surface Management (ASM), Featuring Forrester
Nov 15, 2024Applying the Principle of Least Privilege to the Cloud
Nov 18, 2024The Right Way to Use Artificial Intelligence and Machine Learning in Incident Response
Nov 20, 2024