Google has the best PhD's money can buy
Unfortunately the ones they can't buy are much smarter.
A researcher at website categoriser zvelo has discovered Google Wallet's PIN protection is open to a brute-force attack that takes seconds to complete. And Google is powerless to fix the problem, it seems. The attack is limited to instances where physical access is available, or the phone has been previously "rooted" by the user …
Unfortunately the ones they can't buy are much smarter.
"the bonk triggers an encrypted exchange of information between the card and the till authorising the payment".
Good Moaning. I was pissing by and saw this article. When you say the bonk, does you mean the bank or the tap of the phones?
You made be laugh.
(anon, I am in disguise as a poor onion seller)
That's "bonk" as in "bonk on the head", or a short, sharp, tap, so no typo and no references to my Uncle's TV performance (he was also the dead body in Faulty Towers. and drove the bus for the Magical Mystery Tour, but enough of my family history).
...I would have been seriously impressed.
But connected to Fawlty is pretty impressive anyway.
Don't tell me they don't even salt the hash?!
It could be salted using some info on the Secure Element, thus allowing the PIN to be maganed by droid, or some such. I can't see how this could be so easily cracked unless they are either not salting or they are using an easy-to-find salt.
"unique user IDs, Google account information, and the PIN stored as a SHA256 hex-encoded string. " according to another article.
Salting is good, but where would you keep the salt? Either it would be encrypted on the phone (and thus either having the decryption key on the phone, or the person keys it in which would make it easier to just have a longer password.) A network connection is tricky because losing a connection leaves you out, plus it's rather roundabout. And you're screwed if the server dies.
Isn't the point of salting to prevent passwords from being revealed en-masse? In that case, it doesn't matter so much if the salt is stored together with the hash. This technique can't be used to protect a single password.
Even with a salt, there are still only 10,000 possible hashes of a PIN. The problem is that a four digit numeric password is just too friggin' short for modern cryptanalysis when an attacker has access to the hashed values; it's too easy to brute force.
Fyi, a salt only makes it hard to tell if two PIN hashes represent the same clear-text PIN.
They shouldn't be using sha as it's designed to be fast. Something like bcrypt is a much better idea as its designed to be slow. However, having only 10,000 combinations is asking for trouble. The only other other option is to authenticate it remotely where you can deal with brute force attacks.
if you have 10k possible combinations total. Just brute force generate w/ the said salt. The salt is always visible and real problem is keeping the PIN hash or not in any shape or form.
The design is just beyond retarded.
Salt can also reduce the effectiveness of rainbow table attacks and force the attacker back to brute force methodologies, but the inescapable fact is that there are only 10,000 candidate passwords, so brute force is not the PITA it would otherwise be.
I guess if you "bonk" the phone too much the salt will run out of the cracks.
(and no, I do know what it is, but allow me to put that joke in before someone incompetent does it - I haven't had my coffee yet).
It's pretty clear that Dr Mouse meant not a salt per se, but a secret that was unavailable to the attacker ("using some info on the Secure Element"), which would be combined with the user's PIN and then matched against the hash. That would indeed increase the work factor of offline brute-forcing the PIN.
Really, folks - learn to read.
Another solution would be to get rid of this archaic PIN crap, and allow (or, better, require) a proper passphrase. I'm guessing that most of the likely users of Google Wallet will be used to typing longer strings on their phones anyway.
Of course I still can't see any reason to use the damn thing myself. Kids, lawn, etc.
That is all
It's unfortunate that this identity theft risk can't be mitigated. But! Not to worry! For the low low price of ten dollars per month, we can sell you some identity theft insurance!
A 4-numeric character PIN?
Are they insane? (well, clearly they are but...)
Can't they just change it to a secure password instead?
would you prefer to enter your 512 character password or just provide me with a check and show me your driver's license?
Lengthening the password and/or adding salt can lengthen the time required for the attack to work, but given this one works in seconds, and it requires physical access to the phone in the first place, changing it to hours instead of seconds isn't really all that much help.
Personally, you won't find me using any Google Wallets for anything because my experience with it many moons ago was quite on par with many of the E-Bay horror stories you've heard: money gone, no merchandise, no person at Google for me to call, no refunds ever sent. Obviously YMMV.
The fault seems to lie in the fact that the hash is stored locally and is easily accessible by other applications (in this case the PIN cracker program).
Changing the PIN to a more secure password would take longer to crack (maybe a few minutes or a couple of hours as opposed to a few seconds) but the underlying vulnerability would remain.
Ironically it's the sheer power of handsets these days that makes this a real problem - back in the days of the eWallet on the venerable Nokia 6310i with it's (IIRC) 123MHz processor, this wouldn't have been a problem as it would take several hours or maybe days to crack even the simplest 4-digit PIN.
Having said that, it's a good option until a real fix is found; ask for an 8-character (or longer) password containing lowercase, uppercase, numbers and punctuation, and it should at least discourage random PIN-swiping attacks such as could take place in a coffee shop or similar (you leave your handset unattended on the table, a thief quickly installs the cracker app, sniffs the PIN, gets your CC data and buggers off leaving behind no trace).
Using Google to keep something secret is like using Windows to build a firewall. You're using a wallet based on an OS that has been designated to take over the WiFi spying Streetview "accidentally" began, and you give THAT your PIN codes? BWAHAHAHAHAHAHA.
One born every second...
Surely a better option would be just not to use Google Wallet (or any other NFC-enabled payment tech, for that matter)....
Not for the first time, I wonder who are the people whose time is no precious that they have to be able to pay by waving a card or a phone. Perhaps I'm a Luddite, maybe I'm stingy, but I prefer to know when I'm paying money out.
NFC payments look suspiciously like technology push to me - a solution in search of a problem.
And in fact at least Visa is pushing this, telling shop keepers that they will not have a transaction fee (or a lower one) if their customers pay by bonk. My question is why? Apart from reduced wear on the contacts on the cards or terminals, why should it be cheaper to send a few data packets over the air than by direct contact?
I'm guessing considering the fact this phrase could be used to refer to something completely different, it won't be the description of NFC transactions Visa will be using in the future...
cos they have spent a fortune buying the rights & the terminals etc & want to get some ROI?
On a separate note, the last time El Geg tested this contactless stuff it didn't actually deduct the payments from your balance- does that excellent feature still remain?
As it still costs VISA money to transact, the waving of a fee can only mean one of two things:
1 - the take-up isn't as great as expected in shops or with customers (personally, I seriously do NOT want that feature because you can actually read an NFC chip from about 30 meters with a good aerial)
2 - it's actually a covert way to make merchants refresh their terminals.
(possible "3" - they're PAID to get this in place - if you can poll an NFC card from such a distance you turn people into nicely identifiable and globally trackable objects, especially if you improve the reception when no transaction is pending).
Whatever the reason is, the only thing you can be sure of is that the no/low charges thing is only temporarily, a bit like the first few years of Microsoft school license policy.
Following that piece we bought a big round of pastries, from a place just near the London office, and got charged for those so perhaps it was just a Scottish thing.
I suspect it's an anomaly who's time is past.
I assume in the case of a rooted phone, a nefarious app would need to be allowed root access to grab this information? Something like SuperUser is baked into most roms to allow control over what can gain root access.
System wide root? That's madness. Just sayin'.
Stick to advertising, eh.
I really doubt Google would choose a 4 digit pin unless it was forced on them by the payment processing system. I imagine that to get transaction history it has to go through some PIN based transaction with the bank and therefore they need to store it on the device.
I wonder what risk there is in exposure. The report suggests it exposes transaction history and some personal info which might permit some social engineering but is not as bad as the phone being able to make payments of its own without your consent.
Perhaps there is a way to salt the pin, and optionally password or face recognition protect it. The password protection could be used to encrypt the salt and pin hash so even on a rooted phone where the file is visible it would not expose the value. Or install a proxy service on Google where the actual PIN is held and requests to the bank are made and the user just uses a passphrase or local cert to authenticate with the proxy. The advantage of a proxy service is that potentially Google could detect attacks more easily.
But we'll shove it down your throat anyway.
If both MPIAA and the banks insist the code on your handset is secure, reprogramming the phone will soon be illegal - or at least, the manufacturers won't be able to sell a root-able device.
It'll never be impossible. If you make something unrootable all you accomplish is drawing the attention of the people smart enough to find a way to root it. As proof of this concept, I offer the iPhone, iPad, Kindle Fire, Nook Tablet, most Motorolla phones, and every video game console made in the last 10 years (granted it's called 'hacking' on consoles, not 'rooting', but it's the same thing).
Kindle Fire was designed to allow rooting.
if you're only talking 10,000 possible combinations (of 0000 through 9999) then it is even easier to pre-compute a rainbow table once, and then simply do the matching of the captured hash to the table. The table itself would only have 10k rows and therefore has to be relatively portable.
Rainbow tables are an amazing idea. The only way around them is to have some crazy hash space where the space required to compute and store a rainbow table is prohibitive. Even then Amazon's compute cloud takes care of much of that as well.
Rainbow tables only work on unsalted hashes. If you salt the hash, then the tables become pretty much useless, as you need to compute the values each and every time, for every device.
That is the reason (for example) that WPA2 has not been able to be cracked so easily, the router (if you got a decent one, avoid the BT/Thomson ones at all costs) hashes the password with the ESSID (and sometimes the serial number) meaning that you can't use rainbow tables. You'd have to break the password for each router individually.
you use salt to defend vs rainbows, but the real issue is the terrible narrow amount of input values. The PIN or hash shall never be stored locally, that's it.
In these days of blazing-fast CUDA-capable GPUs, who needs to bother with rainbow tables?
What Eejit thought that a 4-digit PIN was sufficiently secure in the first place to secure access to credit card details, irrespective of whether you need a rooted phone to get to the hash?
It's not a card you're putting into a hole-in-the-wall machine, it's a phone! Jeez! Did someone go beat the google softies with a stupid stick or something?
Dunno about Chocolate Factory, perhaps we should now call them "Chocolate Fire guard" as they're obviously about as useful as one of those.
Pay by NFC is something that I've been hearing warnings against ever since the idea first came about. Add those inherent problems to a system that stores credit card data behind a 4 digit pin and you've got a recipe for disaster.
Just put all your personal information into Google+
So with this attack my Google wallet becomes as secure as my normal wallet. Well not quite, if someone steals my normal wallet they can use my cards immediately. If they steal my phone they will to do a far bit of manipulations on it before they can use my credit cards.
.. and get free calls to boot. Because you're worth it.
I know where my cards are. I don't know just how much Google is milking out of an Android phone, so I don't know where those PINs go..
if they've got your wallet, but you've still got your phone, then you can call and report your cards stolen before they have a chance to do very much with 'em. If they've got your wallet and your wallet *is* your phone, and (as seen in the article) it just takes a few seconds to work out your Google Wallet password, well, this complicates your life much further.
So to perform this hack you need physical access to the phone? Turns out that if you get hold of my wallet you will have all my credit card numbers, my driving license with my DOB and address. That sounds like a far easier way of obtaining this information.
Of course a nefarious app installed on a rooted phone is a bigger problem has it opens the potential for a remote attack. However I've yet to find a situation where pay by bonk is in any way better than cash or chip and pin.
Anyone remember how Verizon 86'ed Google Wallet on its upcoming phones... related maybe? If i remember correctly there was an article here on the register that quoted a Verizon rep who indicated security concerns regarding Google's product.
Anyway, i could be off base, but am actually impressed with Verizon for making a good call. Not surprised Google's product is crap, but none-the-less.still impressed with VZW for noticing a golden turd as turd regardless of its golden luster.
It's been abundantly clear for a while that Android is about as secure as Windows 98. iPhone too. I would never do anything financial on my Android phone. No quick trade broker apps for me.
The payment problem will be solved soon when the credit card companies replace magnetic strips with smart cards. And they will be MUCH harder to hack/crack than anything on a smartphone.
Smart Cards are vulnerable if they're Stupidly-Designed or Stupidly-Implemented.
That last bit seems to be a problem with many modern quote-security-un-quote mechanisms.