Apple Pay Competitor CurrentC Breached
tranquilidad writes "As previously discussed on Slashdot, CurrentC is a consortium of merchants attempting to create a "more secure" payment system. Some controversy surrounds CurrentC's requirements regarding the personal information required, their purchase-tracking intentions and retail stores blocking NFC in apparent support of CurrentC. Now news breaks that CurrentC has already been breached. CurrentC has issued the standard response, "We take the security of our users' information extremely seriously."
It isn't alleged-- TFA states CurrenC sent out a notice saying email addresses were compromised.
"CurrentC Allegedly Breached" would have been a more appropriate headline, that also doesn't necessarily expose anyone to a lawsuit if it turns out to be bullshit.
Did you read the fine article? MCX confirmed that "unauthorized third parties obtained the e-mail addresses of some of our CurrentC pilot program participants and individuals who had expressed interest in the app." They also sent emails notifying their users, No "allegedly" needed; it's not bullshit.
After all, you can bet Google and Apple will try to resell ads and intelligence to the highest bidders, whoever those bidders might be, based purely on the data of the purchase history inside those stores.
No, you can bet Google will, and Apple will not.
It hasn't been breached... they just got a hold of their email mailing list! This is the crappiest bad summary of all crappy bad summaries.
cool frameworks and Languages too!
When are programmers going to wake up and smell the coffee!
You are screwing around with peoples money. You cannot just slap the latest cool frameworks together, write 50 lines of connection code and call it a system.
I would be willing to bet that there is a single database credential that has rights to insert/update/delete/select on all the tables in the system and its is stored in some xml file that the web application has access to and if the web application has access to it so do all the people trying to break in.
I cannot begin to count just how many times I have seen the following:
select * from users where id=? and password=?
and that returns everything about the user. Every modern database supports either functions or procedures to do something like:
validate_user(uname,upass);
and it simply returns true or false, 1 or 0 nothing more, nothing less.
Far far to often I hear, lets use [ fill in the blank ] framework because that is what everyone else uses and besides look how much more productive we are! And so it is taken upon nothing more than faith and 90% of the time the people saying vehemently that that is the way to go, understand perhaps 10% of the framework code and don't investigate any further. When you are considering a framework that is 100's of thousands of lines of code that more then likely wouldn't pass the particular languages version of Lint or Bounds or any other validation tool you have already lost the security war.
The people who are actively trying to break into large systems do their homework! They spend weeks or months looking at your generated web code looking for patterns that reveal the underlying frameworks and then comb through that code looking for even the most subtle vulnerabilities and then they make a plan and execute it.
When you are building systems like this if you don't start with security as priority #1, for the entire stack you will lose, it is just a matter of time.
Hey KID! Yeah you, get the fuck off my lawn!
There is another bit player in the field. Don't pretend like it's any more than that.
Apple Pay has been out for a week. It's done more business than Google Wallet did in, what, 3 years? How many banks signed on to Google Wallet vs Apple Pay?
There are two types of people in the world: Those who crave closure
Particularly when using CAPSLOCK, please be sure to use the correct term. Chip and Pin. Most English speakers are lazy enough in their pronunciation that it comes out as a homophone. But even if you couldn't hear the difference between "in" and "and", you ought to be able to work it out from context: you've got a chip, and you've got a pin; the chip does not reside in the pin.
Because Google Wallet and Apple Pay work in opposite ways.
For a retailer to support Google Wallet, they need to work with Google and their merchant processor to support Google Wallet. Because what really happens is the transaction details are forwarded to Google who then charges your payment method (credit card, debit, Paypal, bank account, etc). This is why Google knows everything about your transaction whenever you use Google Wallet. (Basically Google gets to know everything about what you're buying).
Apple Pay is nothing more than EMV so it's just an electronic credit card. Once you register your card through Apple Pay, Apple is no longer in the transaction. As long as the retailer takes credit cards, and has an NFC reader, Apple Pay will work. Most of the retailers listed by Tim Cook? They did diddly squat to support it. They just had working readers and probably someone came over and tried it and was successful.
Because to support Apple Pay means you need an EMV compatible terminal (swipe, chip+pin, NFC) and processor, and because of October 2015 legislation, people are supporting it by default since practically all new terminals have it. So all a retailer needs to do to get Apple Pay support is make sure their hardware (terminals) is upgraded (which they're doing anyways over the next year) and their processor supports EMV (which if they're doing chip+pin, they're going to have support for).
However, for Apple Pay to work, Apple needs to work with banks to ensure when a user scans a credit card,, they can get a token assigned in its place (the token is private between the user and the bank, and is basically just an index so the bank can determine who to bill).
So Google Wallet requires no effort by banks, etc., and effort by retailers to support. Apple Pay only requires hardware updates they're doing anyways which is minor, but effort by the banks to support EMV.
That's why Google Wallet's penetration has been low - there are probably more retailers that support Bitcoin than Google Wallet just because. (Though if your processor is adding support for Bitcoin, they probably have Google Wallet support as well).
For Apple Pay, because for retailers it "comes for free", which means its market penetration is far higher than what Tim Cook had in his presentation. Because retailers who already have NFC terminals practically already support EMV and that makes them Apple Pay compatible with zero effort.
So retailers may be inadvertently supporting Apple Pay when they don't want to because Apple Pay just shows up as a credit card.
CurrentC is Walmart. It is not Google nor Apple.
The proper term is not 'robbed', it's "civil forfeitured". By confusing the two terms, you sully the reputation of thieves who ply their craft without the aid of crooked DA's and the DEA.
Walmart organized MCX and leads it. http://www.forbes.com/sites/la... I don't know where you are getting the "evil" part but it most certainly is WalMart's design.