Slashdot Mirror
Google Wallet Stores Card Data In Plain Text
nut writes "The much-hyped payment application from Google on Android has been examined by viaForensics and appears to store some cardholder data in plaintext. Google wallet is the first real payment system to use NFC on Android. Version 2 of the PCI DSS (the current standard) mandates the encryption of transmitted cardholder data encourages strong encryption for its storage. viaForensics suggest that the data stored in plain text might be sufficient to allow social engineering to obtain a credit card number."
At least it's not storing, oh say, your login details in plain text... which certain(*cough* Sony) companies do. The details that it stores aren't anything that can be actually used to formally break into an account(yeah, sure, it can be used for stalking purposes/phishing, but that's almost always a vulnerability).
-- (this is a sig) My Computer Programming Forumhttp://www.programers.co.nr/
No Fucking Clue?
"Stores Card Data In Plain Text"
isn't quite the same thing as
"suggest that the data stored in plain text might be sufficient to allow social engineering to obtain a credit card number"
Bitcoin uses encrypted wallets which are not linked to your name or address. It is the strongest computer in the world and it supports p2p DNS through namecoin. It is much more secure than online banking with ACH, and much harder to usurp than centralized BIND servers. Plus they won't print 1,000,000,000,000 of them this year.
Kharma is like a boomerang. Mine is broken.
viaForensics suggest that the data stored in plain text might be sufficient to allow social engineering to obtain a credit card number.
Correct me if I'm wrong, but isn't social engineering the art of tricking people into giving information or access they wouldn't normally? If the security is breached through human gullibility I don't see what method of storing the data is going to protect against that, unless it's storing it where nobody but PCs have access to it and no humans have access to said PC's.
I can socially engineer the card holder to give me their card info and you can't encrypt against that.
It stores the last 4 digits of the credit card, so you know which card was used in your google wallet. My telephone company does this, as does paypal if I remember correctly. Whilst it may not be stored easily in plain view of anyone, I think someone breaking into either of those accounts would be more likely than someone first stealing my phone, rooting it then access the sqlite DB.
To be honest, I am more afraid of my local 7/11 employee who swipes my credit card every day in plain view when I buy milk, newspaper and mamma noodles. I think even some POS systems display the card number on their terminal screen!
These days, I think most credit cards have secondary verification systems in place so even if someone did get my card number, it would be very difficult to use. I already have a hard enough time booking airline tickets online and trying to remember what my Verified by Visa password is. Stupid story and I read somewhere that even some stupid phone provider in the US (Verizon maybe?) has delayed the sale of the Nexus because of this.
Caller: Hi, I'm calling from... er... Google... and it says here in this text file that you have a credit card number on file with us. Is that right?
Victim: Yes, that's right.
Caller: Cool. Would you mind giving me that account number so I can verify your identity?
Victim: Let me get my card...
From TFA:
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 same last 4 digits that are printed on your credit card receipts and show up as plain text on many web sites that store credit cards.
Doesn't seem like a big deal - people should know better than to give their card number to someone that has the last 4 digits of their card number since they could have gotten them anywhere. (or just guessed - send a spam email to 10 million people with a randomly generated 4 digit number, and you'll have guessed right for 1000 of those people.)
And so what? Your phone must be able to decode the stored data, so it must somehow acquire decryption key.
That means that this decryption key must be transmitted over the network or stored on the device itself. And if it's stored on the device, then the whole encryption scheme is nothing more than complex obfuscation.
...to start raising big concerns after reading just the title and not RTFA.
So what if it's stored in plaintext on the phone itself? What matters is what's transmitted off of the phone.
iaForensics suggest that the data stored in plain text might be sufficient to allow social engineering to obtain a credit card number.
This is very, very vague.. Something as simple as a email address could be used for this purpose.
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
It's rot32 encrypted.
*twice*.
'Cause it's the only way to be sure...
Android phones in here in japan have had mobile suica using sony felica NFC comms since early 2011...(toshiba, panasonic, sharp, etc)
This might be the first to use the samsung/google nfc tech, but definately definately not the first NFC payment system on androidn
Leaving a receipt laying around from an ATM transaction is more worrisome. Even then, a bank rep wouldn't need to ask you for your card data, considering they already have it on file. Anyone who falls for a social engineering trick in which the operator requires data is clearly a fool.
to even follow the link and lookup the summary..... here it is:
- A fair amount of data is stored in various SQLite databases including credit card balance, limits, expiration date, name on card, transaction dates and locations and more.
- The name on the card, the expiration date, last 4 card digits and email account are all recoverable
- [Fixed in Version 1.1-R41v8] When transactions are deleted or Google Wallet is reset, the data is still recoverable.
- The Google Analytic tracking provides insights into the Google Wallet activity. While I know Google tracks what I do, it’s a little frustrating to find it scattered everywhere and perhaps in a way that can be intercepted on the wire (non-SSL GET request) or on the phone (logs, databases, etc.)
- [Fixed in Version 1.0-R33v6] The application created a recoverable image of my credit card which gave away a little more info than needed (name, expiration date and last 4 digits). While this is not enough to use a card, it’s likely enough to launch a social engineering attack.
So it is as safe as anything else you use to pay stuff!
Shit... it is easier to just swipe someone's credit card bill! ^^
I'm confused because you don't explain why "Stores Card Data In Plain Text" is a stupid headline. The statement you apparently cited as evidence restates that the data is stored in plain text and therefore may be vulnerable to social engineering attacks. Are you suggesting the headline is somehow contradictory to that? I mean, they both say that the data is stored in plain text, so what exactly is stupid about the headline?
Do you also feel that there aren't enough different three letter acronyms?
FTFA: "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."
Sheesh, big deal about nothing. You know how many gasoline sales receipts end up in the garbage can next to the automated upmp.
Join the Slashcott! Feb 10 thru Feb 17!
My credit card.
I'm going to steal someone's phone to get their credit card number? Why not take their wallet?
I don't want to use Wallet, it's too intrusive and I have to give too much information to them.
For this reason I have stopped buying apps from the Market. I don't like this, but I don't want Wallet.
When I pay for an app, the only thing needed should be my CC number. No street address, no phone number, etc. That's the dealbreaker.
...I do work in security for a telecoms product manufacturer and maintainer and there are a HUGE number of companies out there that store credit card data in plain text.
However, you cannot just look at that one particular issue to make a determination as to whether or not the data is secure - it's also about how the system on which that data is stored is isolated from the real world, what firewalling and access controls are in place to restrict who can get to that data, whether or not they update the systems regularly, etc. etc.
This is NOT a security exploit, there's no report of any security hole that makes that data available to the rest of the world, unlike what happened to Sony - so some prespective needs to be put on this.
Any wise company conducts regular Risk Assessments on their infrastructure to determine what potential security risks exists, how big those risks are and how much it will cost to fix it. In this particular case, it might be that using encrypted credit card information might entail having to upgrade very expensive applications to a later version, all of which will factor into the cost of fixing the issue. If Google has determined that the risk of an outside party getting to that data is extremely low, then they may not consider it worth the expense of the upgrade.
Every company will do this, even Apple and Microsoft, and many of them do choose to adopt PCI (Payment Card Industry) guidelines on storing this kind of data correctly.
It could be argued that someone stealing a file of encrypted credit card data from a company is a much bigger issue than someone (so far) not being able to steal unencrypted data from a company - so it's always wise to put some perspective around these kinds of statements.
Windows 10 is great - I used it to download Linux.
Google Checkout (now Google Wallet) is PCI DSS compliant as a Level 1 processor.
Given their compliance, no one has any basis to question the understanding the Google Wallet team has of PCI DSS requirements.
As someone responsible for PCI DSS compliance at their organisation, I can confirm that Google are not doing anything wrong here. Whoever posted this needs to do some reading, understand what they've posted and apologise.
Whoever accepted this submission for publishing needs to do the same.
They say the info is only available if the device has been rooted: the malicious software has root access. And their "solution" is that Google should store the local data in encrypted form. Anyone notice a fundamental flaw in this "solution", or heck, in the assumptions underlying their alleged problem?
If you rooted your device and therefore you disabled the security, what good is encrypting data locally? Any hack worth its salt would... well, I won't elaborate, but to software running as root, by definition, any locally accessible data and software is accessible. (And of course the same goes for an attacker having leisurely physical access to the hardware.) Basic security facts.
Honestly this all strengthens the argument for keeping all sensitive data only & always in the cloud: then the meagre security of your local device (pc, phone, whatever) might well not be the weakest link in the chain. This aspect did get a brief mention in the article, sort of, but it should have been the focus.
The last 4 digits of your credit card number, that are often printed on your receipts as "plain text" are also stored as plain text by Google Wallet.
So?
Agree. I'm already carrying my credit card around unencrypted anyway. If NFC becomes widespread I can stop using the physical card and only risk losing 4 digits.
Valid point. This does smell a little of "security flaws" which start with "first, get root access"... ("It rather involved being on the other side of this airtight hatchway", as Raymond Chen puts it).
If you have someone's phone or trick them to run code on it that steal their Wallet database, that can be used to obtain some information which you might be able to use to trick them to revealing their credit card details? It's possible, but rather convoluted, and requires the user to make mistakes more than once; I'm sure there are far easier ways to commit fraud.
The Payment Card Industry Data Security Standard requires that the account number be encrypted when stored, but it does not require name or expiration date to be encrypted. It does say they must be protected, meaning the environment in which they are stored should have the same protection as the environment used to store the encrypted card number (such as an isolated subnetwork that is regularly monitored and undergoes annual penetration testing).
https://www.pcisecuritystandards.org/pdfs/pci_ssc_quick_guide.pdf
Mug them and take their real wallet?
Actually even if PCI does apply to the mobile app, based on the article the storage does meet the PCI storage guidelines, which are not as stringent as you might imagine. PCI actually does not require encryption of the credit card number as long as it is truncated to the last 4 digits. And cardholder name and expiration date may be plain text. This is explained on p. 8 of the PCI-DSS v2.0 spec, and in Requirement 3.4.
That said, the plain-text storage is incredibly stupid, and any payment apps on a phone should go above and beyond PCI requirements. And apart from the storage, the rest of the data path needs to be examined to look for other unencrypted links.
If they have your phone and have gained enough access to gather this information, why don't they just use your phone to empty your accounts? Why bother going through all the trouble to snarf data and social engineer the owner? The article should be more clear on if an installed application other than Google Wallet can access the Sqlite3 file. If that is the case, encrypted or not, it is broken. If that is not the case then they didn't find anything very useful. Who, that is capable of rooting a phone and installing alternative OS, is going to fall for social engineering attempt after loosing their phone. You would have to be the dumbest geek on earth.
Having to work for a living is the root of all evil.
My credit card.
I'm going to steal someone's phone to get their credit card number? Why not take their wallet?
Because someone's real wallet is not connected to the Internet and cannot run my malware. Android on the other hand is quite accomodating to malware and various exploits.
I would assume the concern is more with malware harvesting the info from thousands of phones via some security hole, rather than someone stealing phones one at a time.
My wallet stores my credit card details in plain text - does that mean it's not PCI compliant?
Isn't that the important part? If someone steals my phone (which is encrypted btw - galaxy nexus ftw) they're going to have an easier time just grabbing my wallet to make fraudulent charges.
Absolute power corrupts absolutely. indymedia
AFAIK Google is only 1 notch more trustworthy than Facebook. I can't see anyone in their right mind, who isn't rationalizing to accept a convenience, willingly turning over their financial information to either organization.
I wonder who financed this "news."
I wonder is biased blogs should be used for "news."
And slashdot thinks this is news.
fire the stupid programming engineer crack monkey!
HOLY CRAP. EVERYONE'S WALLET HAS A HUGE SECURITY HOLE!!!
If you take our your card you will notice that all of your credit cards have account numbers on them and your card holder information stored on plain text!!!! SECURITY BREACH!!!! EVERYONE RUN AROUND AND SCREAM!!!!
Theif - Hi I'm from chase and we have noticed some wierd activiy on your card, could you read me the numbers from the front of your card to verify...
Target - Dude, we're in line at the conveinience store are you brain damaged?
Theif - Well I just thought I could give this whole social engeneering for credit card information thing a try, but it takes a little too much effort (guy leaves store and waits outside with a bat...)
I think the target's real wallet has worse security than his smart phone...
viaForensics suggest that the data stored in plain text might be sufficient to allow social engineering to obtain a credit card number
You can encrypt the crap out of all the data you want, and social engineering can still obtain your credit card number. Social engineering is like hacking a person. The only thing you can do to stop that is educate yourself and take precautions. Unencrypted data doesn't help, but it's not what makes social engineering successful.
Had anyone ever seen the movie "Idiocracy"? It the film, a sports drink company, named "Brondo" (similar to Gatorade) owns the goverment, FAA, FCC, USDA, etc. Google is headed in that same direction.... FYI...
This is so not a big deal. The last four should already be considered compromised given how often they appear on receipts, both physical and digital. Even with the last four known there's still plenty of entropy in the unknown digits. As long as there aren't any other massive fails on Google's part, you're safe. Also, most retailers store this info unencrypted and it doesn't violate any PCI DSS rules. Source: http://codinginmysleep.com/2011/12/on-the-google-wallet-problem/
i mean, if it was encrypted, how the hell would they index it for search?!?!