CurrentC Has Been Hacked, Testers’ Email Addresses Stolen(techcrunch.com)
techcrunch.com
CurrentC Has Been Hacked, Testers’ Email Addresses Stolen
http://techcrunch.com/2014/10/29/retailer-backed-apple-pay-rival-currentc-has-been-hacked-testers-email-addresses-stolen/
173 comments
Startups optimize for fast growth and monetization with limited resources. Time spent securing a site is considered time wasted not improving SEO or user experience. It's already well known that people will sign up for an insecure site because they really don't care until something happens, and apologies after you've gotten traction (and their money and/or data) are less risky than potentially going live later than sooner.
In other words, not only do many startups not care, they would consider application security to be actively harmful.
This is of course assuming they know. Vulnerabilities may exist in libraries, packages and frameworks which are not known about, or in the case of PHP, old and unsafe practices are easier to copy and paste and tend to proliferate on tutorial and Q/A sites.
In other words, not only do many startups not care, they would consider application security to be actively harmful.
This is of course assuming they know. Vulnerabilities may exist in libraries, packages and frameworks which are not known about, or in the case of PHP, old and unsafe practices are easier to copy and paste and tend to proliferate on tutorial and Q/A sites.
Considering AppSec harmful is ridiculous.
I know a particular startup that received millions of dollars in VC to start a payment processor. I RCE'd them in under 5 minutes and they remained vulnerable for more than a month after I reported it (this was within the last two months). This is frankly ridiculous and is a good extreme that shows why appsec being harmful is just not the case.
There is a difference between emphasizing only security, and building software with appropriate security measures in place.
I know a particular startup that received millions of dollars in VC to start a payment processor. I RCE'd them in under 5 minutes and they remained vulnerable for more than a month after I reported it (this was within the last two months). This is frankly ridiculous and is a good extreme that shows why appsec being harmful is just not the case.
There is a difference between emphasizing only security, and building software with appropriate security measures in place.
You're misunderstanding the point. Pretend you're a cash-strapped startup, still financially in the red. You discover a security hole in your software. You have these choices on what to do today:
1) Spend the day implementing a new feature that will very likely improve revenue/traction
2) Spend the day doing preventative security measures to protect you from something that might only be a problem when you're actually making lots of money
You choose option #1. Choosing #2 is "harmful" to you and your investors.
1) Spend the day implementing a new feature that will very likely improve revenue/traction
2) Spend the day doing preventative security measures to protect you from something that might only be a problem when you're actually making lots of money
You choose option #1. Choosing #2 is "harmful" to you and your investors.
A payments startup had better get security right from the start, because that is their business.
Your average web startup that's providing jazzy ringtones and a new poke app, sure, should leave security for last.
Your average web startup that's providing jazzy ringtones and a new poke app, sure, should leave security for last.
This might be tough to answer due to survivorship bias, but can anyone name a startup, payment focused or otherwise, that failed because of a security vulnerability/vulnerabilities?
Would you consider DigiNotar a startup? It's certainly a famous example. Also, I happen to know of "RockYou", the facebook app people who were pretty much demolished not long after their massive account breach. Co-incidence or cause? They may be still alive but under new management.
A number of Bitcoin services have gone under after being hacked. http://www.theguardian.com/technology/2014/mar/18/history-of...
I don't see a point to arguing this. Both are harmful. You can end up like CurrentC at the top of hacker news, or you can be 1 day behind.
Both are bad. You can maybe prevent yourself from having to make this decision by being security aware from day0
Both are bad. You can maybe prevent yourself from having to make this decision by being security aware from day0
You are ignoring the argument - a fundamental tenet of economics is there is a scarcity of resources - this is even more true with a startup, and, you need to make a decision as to where you will spend those incredibly limited resources.
The point being made is that in the beginning, the primary focus has to be getting traction with your potential customers.
Yes, you need to take make commercially reasonable efforts to secure your website, but, dedicating too much effort to prevent criminals from hacking you, to the point that you are not focussing on building your business, is counter productive. You may end up with a perfectly secure site that absolutely nobody is using - far better to have an incredibly popular site, that may have some security issues, that you can then lock down once you have the resources to do so.
But, this is about startups. CurrentC has millions and millions of dollars to spend - they have zero excuse for getting hacked.
The point being made is that in the beginning, the primary focus has to be getting traction with your potential customers.
Yes, you need to take make commercially reasonable efforts to secure your website, but, dedicating too much effort to prevent criminals from hacking you, to the point that you are not focussing on building your business, is counter productive. You may end up with a perfectly secure site that absolutely nobody is using - far better to have an incredibly popular site, that may have some security issues, that you can then lock down once you have the resources to do so.
But, this is about startups. CurrentC has millions and millions of dollars to spend - they have zero excuse for getting hacked.
Well, it depends on the cost of a breach, and the probability thereof. Those in turn depend on how you choose to calculate them.
If my company leaks our customer's e-mail addresses and plaintext passwords, how much cost is incurred? Is it a huge cost, because some of the customers have reused their e-mail password and they lose a bunch of personal data and accounts on dozens of sites? Or is it a small cost because they should have followed good security practices by using different passwords on different sites, so it's their fault they had more than an e-mail address leaked? Or is no cost incurred at all because hey, it's our customers not us who suffer from this. It's not like we're going to pay them any compensation!
Likewise, if there are hundreds of people scanning the web trying to exploit the security problem and it's easy to automatically detect, it's almost certain to get hit - on the other hand if it's difficult to find or exploit the risks may be lower. Of course, if you coded the bug in the first place, you might not be informed enough to assess this accurately.
If my company leaks our customer's e-mail addresses and plaintext passwords, how much cost is incurred? Is it a huge cost, because some of the customers have reused their e-mail password and they lose a bunch of personal data and accounts on dozens of sites? Or is it a small cost because they should have followed good security practices by using different passwords on different sites, so it's their fault they had more than an e-mail address leaked? Or is no cost incurred at all because hey, it's our customers not us who suffer from this. It's not like we're going to pay them any compensation!
Likewise, if there are hundreds of people scanning the web trying to exploit the security problem and it's easy to automatically detect, it's almost certain to get hit - on the other hand if it's difficult to find or exploit the risks may be lower. Of course, if you coded the bug in the first place, you might not be informed enough to assess this accurately.
The unfortunate truth is that the long-term costs to startups of compromised security is low because most people don't really care about it anyway. Target, Home Depot, Adobe, et al aren't seeing a massive loss of revenue due to being compromised.
There's a lot of press about incidents for a day or maybe three, it gets posted to HN and everyone has a <stuffy>very serious and very academic</stuffy> discussion about it, and within a week it's forgotten entirely.
People just don't care. It's nothing more than a temporary nuisance to most people. There aren't any consequences that seriously impacts anyone's life.
In the real world, startups are probably correct to focus first on new features and then patch security later. In an ideal world, that would be a mistake that would kill them.
There's a lot of press about incidents for a day or maybe three, it gets posted to HN and everyone has a <stuffy>very serious and very academic</stuffy> discussion about it, and within a week it's forgotten entirely.
People just don't care. It's nothing more than a temporary nuisance to most people. There aren't any consequences that seriously impacts anyone's life.
In the real world, startups are probably correct to focus first on new features and then patch security later. In an ideal world, that would be a mistake that would kill them.
Regarding Target, http://www.foxbusiness.com/industries/2014/05/21/target-post... and http://www.cbsnews.com/news/data-breach-costs-take-toll-on-t...
The costs to Home Depot i would argue are not known.
The danger to a startup in the payments business that gets breached before they open their doors could in fact have a long-lasting effect.
It's nothing more than a temporary nuisance to most people. There aren't any consequences that seriously impacts anyone's life. My friend who is an FDA consultant who gets called when medical device manufacturing lines get shut down would very much disagree with that statement.
The thing about the Adobe breach is that it hurts the ecosystem. Folks who put an email and a password out there that happened to use that same password for a bank or other critical resource are now more vulnerable. And the trick with the Adobe thing is that most of the folks that I surveyed that have emails out there don't remember signing up.
People just don't care. And that is the crux of the problem.
The costs to Home Depot i would argue are not known.
The danger to a startup in the payments business that gets breached before they open their doors could in fact have a long-lasting effect.
It's nothing more than a temporary nuisance to most people. There aren't any consequences that seriously impacts anyone's life. My friend who is an FDA consultant who gets called when medical device manufacturing lines get shut down would very much disagree with that statement.
The thing about the Adobe breach is that it hurts the ecosystem. Folks who put an email and a password out there that happened to use that same password for a bank or other critical resource are now more vulnerable. And the trick with the Adobe thing is that most of the folks that I surveyed that have emails out there don't remember signing up.
People just don't care. And that is the crux of the problem.
The point is that the incentives are such that it's not necessarily rational for a young startup to ensure their product stays perfectly secure.
Startups are so precarious and need so much attention on other areas that for most types of startups, security holes are not the biggest existential threat.
And those incentives partially come from users who are more than happy to sign-up for a website someone threw together in a month without any thought about whether it's secure.
Startups are so precarious and need so much attention on other areas that for most types of startups, security holes are not the biggest existential threat.
And those incentives partially come from users who are more than happy to sign-up for a website someone threw together in a month without any thought about whether it's secure.
CurrentC is ramping up and isn't even taking real customers yet. There target user doesn't read Hacker news. This doesn't affect their business at all except for the slow down of trying to figure out the attack.
Security is one of those things you can't just toss in at the very end. In order to do it right, you really have to include security in your design from the ground up.
It seems like bullshit at first. The model of "secure software development" tends to culminate in notably different software designs. For instance, a proper payments service would have security at its forefront. A naive one might process all requests that come its way; OTOH, a secure payments service might choose to process only those requests that seem trustworthy (does the request look suspicious? does the requester have a history of abuse? etc.).
Security is something that will fundamentally shape the architecture and design of your system. You can't just go back and make these types of gigantic changes.
I guess it all comes down to whether you are willing to accrue technical debt by not designing securely from day 1. If you get funded, you can go back and change things, but (in practice) you can only change so much.
It seems like bullshit at first. The model of "secure software development" tends to culminate in notably different software designs. For instance, a proper payments service would have security at its forefront. A naive one might process all requests that come its way; OTOH, a secure payments service might choose to process only those requests that seem trustworthy (does the request look suspicious? does the requester have a history of abuse? etc.).
Security is something that will fundamentally shape the architecture and design of your system. You can't just go back and make these types of gigantic changes.
I guess it all comes down to whether you are willing to accrue technical debt by not designing securely from day 1. If you get funded, you can go back and change things, but (in practice) you can only change so much.
Isn't this a false dichotomy?
Option 3) Spend the day fixing the security problem, then write a transparent post about it thus improving revenue/traction with new/existing users.
Option 3) Spend the day fixing the security problem, then write a transparent post about it thus improving revenue/traction with new/existing users.
No, this isn't an option.
Writing a blog post about "fixing security problems" will not attract new customers for 99.99% of startups, unless security is a core value prop for your product (Stripe, for example).
Your average Airbnb user does not read Hacker News, waiting to signup for security conscious services.
More so, writing a blog post about how you spent all day preventing XSS, SQLIs and similar vectors wouldn't even get to the top of Hacker News because these are mundane and basic problems with simple fixes. The reaction by a technical audience like HN would a simple "congrats...?" pat on the back.
Writing a blog post about "fixing security problems" will not attract new customers for 99.99% of startups, unless security is a core value prop for your product (Stripe, for example).
Your average Airbnb user does not read Hacker News, waiting to signup for security conscious services.
More so, writing a blog post about how you spent all day preventing XSS, SQLIs and similar vectors wouldn't even get to the top of Hacker News because these are mundane and basic problems with simple fixes. The reaction by a technical audience like HN would a simple "congrats...?" pat on the back.
There is also the consideration that you will never know your security was insufficient until the day you do.
You can take reasonable efforts to secure your site. You can follow the best practices that you find. You may even have the best programmers money can buy.
But, in the end, until you are caught with your pants down, you may have no idea that you are actually vulnerable.
We make mistakes. Some of them are stupid.
You can take reasonable efforts to secure your site. You can follow the best practices that you find. You may even have the best programmers money can buy.
But, in the end, until you are caught with your pants down, you may have no idea that you are actually vulnerable.
We make mistakes. Some of them are stupid.
you may have no idea that you are actually vulnerable as in Home Depot who found out that they were hemorrhaging from the Secret Service.
[deleted]
[deleted]
[deleted]
AppSec doesn't solve their problems.
The startup problem is that they need a good product to attract users. If they have no users, poor security doesn't affect many people and can be tolerated. So all their efforts go into improving the product from an end-user standpoint, and security is left for a time when there are enough users to justify.
Security and moving fast are often at odds.
The startup problem is that they need a good product to attract users. If they have no users, poor security doesn't affect many people and can be tolerated. So all their efforts go into improving the product from an end-user standpoint, and security is left for a time when there are enough users to justify.
Security and moving fast are often at odds.
This is true, and you can easily view this as a form of abuse against userbases: your data will be exploited and not properly secured while a company profits and you suffer the consequences.
[deleted]
Worse than stupid web vulnerabilities of the sort you mention, but many startups don't even practice a modicum of best practices.
My coworkers recently tried a new New York-based food delivery startup and found that their auth wasn't even HTTPS. Forget XSS or SQLI, this is basically propping your front door wide open with a sign "please take whatever you want".
Worst part is when we emailed them they tried defending the use of HTTP for auth. Took a bit of convincing to get them to take us seriously.
There are a lot of startups out there whose security practices aren't just deficient, they're straight up amateur hour.
My coworkers recently tried a new New York-based food delivery startup and found that their auth wasn't even HTTPS. Forget XSS or SQLI, this is basically propping your front door wide open with a sign "please take whatever you want".
Worst part is when we emailed them they tried defending the use of HTTP for auth. Took a bit of convincing to get them to take us seriously.
There are a lot of startups out there whose security practices aren't just deficient, they're straight up amateur hour.
I think I know the food delivery service you're talking about (free delivery, no tips). They use Stripe as their processing backend, and they said that their connection to Stripe is over HTTPS, however, I gave up trying to explain that of the initial transmission to their servers is unencrypted, it doesn't matter.
I thought about reporting this to Stripe, but I don't know if that is an appropriate thing to do.
I still gave them a try, but I generated a virtual card number to use.
I thought about reporting this to Stripe, but I don't know if that is an appropriate thing to do.
I still gave them a try, but I generated a virtual card number to use.
I had the same discussion with a new parking management company at my apartment complex. I told them I wasn't going to put confidential information on a site that doesn't use https, and they tried to tell me that they used a third party for authentication so my data wasn't stored there... I don't even know how to explain to them.
"You're telling me that once you have my information you throw it away immediately. That's great, but you are still forcing me to give you my information in the first place by standing in the middle of the street yelling it through a loud hailer".
If the form is POSTed directly to stripe (which is the recommended usage), your info is never seen by a third party. The site in question would only potentially store a token. Are you sure this wasn't the case?
If the form itself was delivered over http then it doesn't matter. An attacker could easily change the POST address to something else. And how could you even tell? Browsers don't display the URL that a submit button is going to POST to...
Of course if an attacker can MitM any HTTP web page on a site (ie. if a site is not all SSL) then it really doesn't matter if they serve the form over HTTPS because the attacker can set up another form over HTTP and the victim will be none the wiser.
And then there's the possibility of XSS in which case neither lack of MitM access or use of HTTPS will be sufficient protection.
And then there's the possibility of XSS in which case neither lack of MitM access or use of HTTPS will be sufficient protection.
This is true. You'd have to look for a script tag with src of https://checkout.stripe.com/checkout.js. Alternatively, you could try to follow the onclick handler for the button (Event Listeners in Chrome).
At the time I had to enter my card number it wasn't the case.
Just checked again and when I go to the card number screen it is now HTTPS.
Just checked again and when I go to the card number screen it is now HTTPS.
The reason it's amateur hour is security is an expertise and it's so easy for everyone else to screw it up that that's basically the default.
I hope one day tptacek or someone will distill web application security down to a really simple checklist that even the dumbest of developers can refer to so that at least we make less of the stupid mistakes.
I hope one day tptacek or someone will distill web application security down to a really simple checklist that even the dumbest of developers can refer to so that at least we make less of the stupid mistakes.
That's one of the goals of owasp linked in the above post.
Unfortunately the OWASP website is a mess... took me a while to even find the relevant articles on web app security from the landing page.
I do like that link but it leaves it to us, the people who don't know or care deeply about this stuff, to study the problems further and come up with our own solutions. Ideally we'd be given answers instead of just a starting point for additional research.
It's hard to invest yourself in something you're not interested in.
It's also difficult to know where to begin when there are so many "unknown-unknowns."
That in mind: Don't try to be an expert. Start with awareness.
Even if they just become "known-unknowns," you'll then know where to focus your attention and be better able to ask the right questions.
[1]: For example, http://guides.rubyonrails.org/security.html
It's also difficult to know where to begin when there are so many "unknown-unknowns."
That in mind: Don't try to be an expert. Start with awareness.
1. Don't roll your own security solutions. Leave it to the experts (i.e. a mature web framework).
2. Learn the best practices for your web framework of choice.[^1]
3. Have a basic understanding of the attacks.
Even if they just become "known-unknowns," you'll then know where to focus your attention and be better able to ask the right questions.
[1]: For example, http://guides.rubyonrails.org/security.html
Why should we treat security like it's something we can google our way through in an afternoon? That's why sites and servers are compromised in record numbers every week.
Imagine if we asked doctors for hints.
Imagine if we asked doctors for hints.
> even the dumbest of developers
Don't you think it's time to get off your high horse?
Don't you think it's time to get off your high horse?
Perhaps you should be less defensive about the incredibly low amount of knowledge/talent/intelligence required to put together many web or mobile apps?
If you read the rest of that sentence I included myself in that group since when it comes to security I've not many clues.
If you read the rest of that sentence I included myself in that group since when it comes to security I've not many clues.
Well, it's arguably rational, if perhaps unethical.
Any time not spent working on security can be spent working on the startup, and presumably increasing the chances they get used. Most startups die because they don't get used, not because they weren't secure enough.
Any time not spent working on security can be spent working on the startup, and presumably increasing the chances they get used. Most startups die because they don't get used, not because they weren't secure enough.
Why even waste your time with them if they won't listen?
Because they're a VC-funded startup that seems to have a pretty good grasp of marketing and will no doubt attract users even if their security apparatus is a cruel joke.
In other words, for their users, not them.
In other words, for their users, not them.
Is there a reason you're not naming them? You disclosed it responsibly, and presumably they have now fixed it. I don't understand the rationale for _not_ naming them.
No particular reason - I hadn't decided if I wanted to name and shame them directly (though if you really wanted to find out, there aren't that many food delivery startups in NYC...), and in the absence of intent to name and shame, my default inclination is to not.
The issue was reported a while back, and after convincing them that, no, HTTP auth is a terrible idea, they did switch to HTTPS. This is not an open vulnerability.
Hint: tcas seems to be referring to the same company.
The issue was reported a while back, and after convincing them that, no, HTTP auth is a terrible idea, they did switch to HTTPS. This is not an open vulnerability.
Hint: tcas seems to be referring to the same company.
For all we know, he disclosed it 4 days ago. Merely disclosing a vuln doesn't mean an appropriate amount of time has passed where it could be patched. Remember, real users' info is at stake.
Fair point. I got the impression it had been fixed, but that may have been wrong. Hopefully, once it is fixed, they will be named, otherwise I don't see how things can ever get better.
While I totally agree this is important to know, CurrentC isn't a startup, it's a new program from an established company. These guys have made themselves a target, and it is very likely that no amount of good security would leave them totally invulnerable. The community's desire to make CurrentC look foolish is very high.
I don't see it as any different than "it's own thing". CurrentC is a new product built from scratch essentially.
Building things from scratch means you end up having to worry about how your code is organized to make good secure programming decisions.
I have no desire to make CurrentC look foolish, only to help people write better software which they currently aren't doing
Building things from scratch means you end up having to worry about how your code is organized to make good secure programming decisions.
I have no desire to make CurrentC look foolish, only to help people write better software which they currently aren't doing
I suspect the point was that this was this program comes from established companies that have no place making the same mistakes that startups make, or for the same reasons.
I'm reminded of this quote from Steve Yegge's platform rant[1]
... I'll argue that Accessibility is actually more
important than Security because dialing Accessibility
to zero means you have no product at all, whereas dialing
Security to zero can still get you a reasonably
successful product such as the Playstation Network.
"Move fast and break things" then just look for an exit and it will be someone else's problem.
Granting one understands, generally, how these vulnerabilities work (read up on that site) - what would then be a good next step? Oftentimes these small companies are focused on getting the data-flow to work and have not coded in all the edge cases. What are reasonable (easy would be nice too) steps one can take to help mitigate the most vulnerable edge cases? Or is it something that should just immediately be hired out just before you want to go live?
Best advice I could provide if the devs aren't too knowledgeable on application security, is use a framework where possible, know where it's likely to fail you and focus there and then make sure you stay on top of patching all your framework components to catch vulns in that layer
So for example rails handles basic things like SQL injection, XSS in standard forms fine, then you can use devise or similar for authentication and get a reasonable level of security. What you're left with are areas like authorisation which tends to be app. specific so still requires work, but you probably have less to focus on.
Also watch out for what I'd call "dangerous" functionality, things like file uploads or user generated content where you want users to enter HTML tags but still avoid XSS. Things like that need specific consideration to avoid common security issues.
Of course if you're doing something that will attract real bad guys (anything to do with payments, anything to do with bitcoin, anything to do with Intellectual property management etc) then I'd strongly recommend getting an app security person on staff as soon as you can 'cause you will get attacked probably sooner rather than later...
So for example rails handles basic things like SQL injection, XSS in standard forms fine, then you can use devise or similar for authentication and get a reasonable level of security. What you're left with are areas like authorisation which tends to be app. specific so still requires work, but you probably have less to focus on.
Also watch out for what I'd call "dangerous" functionality, things like file uploads or user generated content where you want users to enter HTML tags but still avoid XSS. Things like that need specific consideration to avoid common security issues.
Of course if you're doing something that will attract real bad guys (anything to do with payments, anything to do with bitcoin, anything to do with Intellectual property management etc) then I'd strongly recommend getting an app security person on staff as soon as you can 'cause you will get attacked probably sooner rather than later...
This is doubly true for PHP. Upgrading an (already likely secure) database class in a framework that uses PDO is a lot easier than changing a thousand calls to mysql_query after the fact. You don't have to worry about wrapping every echoed variable in htmlspecialchars() when you're already using twig. PHP developers keep running afoul of what are already mostly solved problems. Imposing a bit of structure and modularity now will make responses to issues easier later.
Although the downsides of this are the possible vulnerabilities in the framework itself (as well as the potential learning curve and lock-in) there are likely to be more people using, and finding, those vulnerabilities than would be in your quick-and-dirty handrolled quasiframework. Even if the latter is more fun.
And if you're on shared hosting... umm... you should probably reconsider that. If that's not likely to happen soon, then database-driven sessions, regular backups and SSL are a must.
Although the downsides of this are the possible vulnerabilities in the framework itself (as well as the potential learning curve and lock-in) there are likely to be more people using, and finding, those vulnerabilities than would be in your quick-and-dirty handrolled quasiframework. Even if the latter is more fun.
And if you're on shared hosting... umm... you should probably reconsider that. If that's not likely to happen soon, then database-driven sessions, regular backups and SSL are a must.
I think OWASP does a good job explaining this stuff if you know how to build a web-app, you should be able to understand the vulns (they give PoC code and examples).
OWASP could be doing a lot more but their PoC and descriptions are pretty good.
Your next step is to think about how you will be preventing them. An example, If you are writing a PHP site without a framework, how will you generate, validate, and store CSRF tokens? How will you filter output? How will you architect your web-app to prevent SQLi?
Security consulting is ridiculously expensive and I've seen companies pay a lot to get told very little. If you want to run security concerns by me, I am free to contact.
OWASP could be doing a lot more but their PoC and descriptions are pretty good.
Your next step is to think about how you will be preventing them. An example, If you are writing a PHP site without a framework, how will you generate, validate, and store CSRF tokens? How will you filter output? How will you architect your web-app to prevent SQLi?
Security consulting is ridiculously expensive and I've seen companies pay a lot to get told very little. If you want to run security concerns by me, I am free to contact.
The big problem with tech startups is that they are by and large technologically clueless. Security is just one of the more obvious symptoms.
It's always been the case that a lot of tech startups are started by "idea people" who just may or may not get lucky with their choice of technical co-founder or first hire, but I get the feeling it's been getting a lot worse the past few years. You can go to startup meetups and have a hard time finding anyone with half a clue about the actual technology.
Feels like we are regressing back to 1999.
It's always been the case that a lot of tech startups are started by "idea people" who just may or may not get lucky with their choice of technical co-founder or first hire, but I get the feeling it's been getting a lot worse the past few years. You can go to startup meetups and have a hard time finding anyone with half a clue about the actual technology.
Feels like we are regressing back to 1999.
We offer a free startup plan at https://www.tinfoilsecurity.com to help with this exact problem.
Mcx is a publicly traded company
http://en.m.wikipedia.org/wiki/Multi_Commodity_Exchange
http://en.m.wikipedia.org/wiki/Multi_Commodity_Exchange
Different MCX here: https://en.wikipedia.org/wiki/Merchant_Customer_Exchange
Straight from the horse's mouth [1]:
"On the data security side, the technology choices we’ve made take consumers’ security into account at every aspect of their core functionality. We want to assure you, MCX does not store sensitive customer information in the app. Users’ payment information is instead stored in our secure cloud-hosted network. Removing this sensitive information from the mobile device significantly lowers the risk of it being inappropriately disclosed in a case that the mobile device is hacked, stolen or otherwise compromised."
There are simply not enough faces to palm.
[1] http://www.mcx.com/blog/answers-to-your-questions/
"On the data security side, the technology choices we’ve made take consumers’ security into account at every aspect of their core functionality. We want to assure you, MCX does not store sensitive customer information in the app. Users’ payment information is instead stored in our secure cloud-hosted network. Removing this sensitive information from the mobile device significantly lowers the risk of it being inappropriately disclosed in a case that the mobile device is hacked, stolen or otherwise compromised."
There are simply not enough faces to palm.
[1] http://www.mcx.com/blog/answers-to-your-questions/
Disturbingly, this is even more dangerous than them storing credit cards on their servers, since the MCX system uses raw bank account information. If you think it's bad dealing with reversing charges and changing numbers when you get a credit card stolen, try dealing with ACH fraud.
Isn't that same "raw bank account information" on every check you write?
It's funny that they say that, considering that storing tens or hundreds of millions of credit card information or e-mail addresses in the "cloud" represents a much higher risk than storing everything locally, in a secure enclave in devices, with little to no exposure to the OS, the way Apple does it, in terms of potential for total damage.
They worst part is that they aren't even going to store credit card details because they aren't launching with credit card support. They want to tie into your checking account and do ACH! (This being the big pitch to the retailers, not only can you track across stores but you can forget about credit card fees). This is an instant fail company.
> This is an instant fail company.
This is a project largely driven by Walmart with some buy in from other merchants. Walmart has recently announced it'll provide low cost checking accounts to its customers[1]. Walmart's profits are basically driven by volume and beating up their vendors for low prices so they can in turn sell to customers at low prices - the margins are razor thin. Cutting out 2-3% from credit card fees has got to look attractive.
I'd never touch this product, because it's got shitty implementation and security written all over it, but I'm not so sure if it'll be instant fail or not. If they offer a portion of what they save in credit card fees in flat discounts to people, they might be able to make it work.
Of course, I don't really see what non-Walmart merchants are gonna get out of this. Helping them improve their margins seems like it'd only make things worse for places like Target or grocery stores.
[1] http://www.nytimes.com/2014/09/24/business/finding-a-door-in...
This is a project largely driven by Walmart with some buy in from other merchants. Walmart has recently announced it'll provide low cost checking accounts to its customers[1]. Walmart's profits are basically driven by volume and beating up their vendors for low prices so they can in turn sell to customers at low prices - the margins are razor thin. Cutting out 2-3% from credit card fees has got to look attractive.
I'd never touch this product, because it's got shitty implementation and security written all over it, but I'm not so sure if it'll be instant fail or not. If they offer a portion of what they save in credit card fees in flat discounts to people, they might be able to make it work.
Of course, I don't really see what non-Walmart merchants are gonna get out of this. Helping them improve their margins seems like it'd only make things worse for places like Target or grocery stores.
[1] http://www.nytimes.com/2014/09/24/business/finding-a-door-in...
So far, what I've heard about CurrentC reminds me of Circuit City's failed attempt to push their proprietary pay-per-view DVD scam.
Like any number of similar schemes, up to and including Microsoft's attempt to force-feed Metro to desktop users, it's all about what the company wants, rather than what the consumer wants. That always works out so well for the company.
Like any number of similar schemes, up to and including Microsoft's attempt to force-feed Metro to desktop users, it's all about what the company wants, rather than what the consumer wants. That always works out so well for the company.
> it's all about what the company wants, rather than what the consumer wants.
This is definitely true, but I'm not sure how much it matters.
I, as a consumer, definitely prefer using credit cards because of the protection it affords me, plus I get rewards for what I buy - I never use a debit card to pay for things. I'm also a bit leery of the marketing surveillance state that's cropped up in the US over the past few years, and a scheme like this sets off alarm bells immediately. And I'm sufficiently well off that I'm unlikely to be enticed to try it out just to get some discounts.
But I'm also not a typical consumer. I could see where - if properly and/or luckily done - this might appeal to a not insignificant number of people. If I'm getting a bank account at Walmart, it's likely because I have difficulty getting one somewhere else. Those discounts might seem more attractive to me. Maybe you could argue that's the type of consumer who's also less likely to pay with their phone (or have a phone capable of handling the payments). Dunno, but it seems like even though nobody particularly wants this, it could work because there's a lot of folks who might not dislike it enough to make a difference. DIVX failed because the idea of DVDs that are single use is just a blatant cash grab. It's less obvious here, from the consumer's perspective.
My gut says clusterfuck, though.
EDIT: added a sentence.
This is definitely true, but I'm not sure how much it matters.
I, as a consumer, definitely prefer using credit cards because of the protection it affords me, plus I get rewards for what I buy - I never use a debit card to pay for things. I'm also a bit leery of the marketing surveillance state that's cropped up in the US over the past few years, and a scheme like this sets off alarm bells immediately. And I'm sufficiently well off that I'm unlikely to be enticed to try it out just to get some discounts.
But I'm also not a typical consumer. I could see where - if properly and/or luckily done - this might appeal to a not insignificant number of people. If I'm getting a bank account at Walmart, it's likely because I have difficulty getting one somewhere else. Those discounts might seem more attractive to me. Maybe you could argue that's the type of consumer who's also less likely to pay with their phone (or have a phone capable of handling the payments). Dunno, but it seems like even though nobody particularly wants this, it could work because there's a lot of folks who might not dislike it enough to make a difference. DIVX failed because the idea of DVDs that are single use is just a blatant cash grab. It's less obvious here, from the consumer's perspective.
My gut says clusterfuck, though.
EDIT: added a sentence.
I find it hard to believe that the consumer benefits of CurrentC (pretty much just that it works on phones without NFC) outweigh the PITAness of the system. A Walmart-issued card could be directly linked to a Walmart account and people inside that closed ecosystem that bypassed the credit card companies (saving Walmart that precious 2%) would be easier and safer using a Walmart card than CurrentC, at least as currently described.
It looks to me like a very expensive way for some midlevel executive at Walmart to collect huge bonuses for a few years and then get fired after burning through billions with no appreciable change in the mix of payment systems.
It looks to me like a very expensive way for some midlevel executive at Walmart to collect huge bonuses for a few years and then get fired after burning through billions with no appreciable change in the mix of payment systems.
From all the "protection through credit cards" talk (which is a new concept to my German socialization - credit cards have a pretty bad rap here), it seems to me that in the US it's easier to counter risks by adding a middle man (yay, layers of abstractions, all with extra costs) than fixing the root cause.
Because here, we enjoy a reasonably fast, cheap and secure electronic direct debit system since the early 80s (only now replaced by a EU wide system that works pretty much the same) that was built by merchants and banks. Credit cards never managed to seriously make a dent in that market.
Because here, we enjoy a reasonably fast, cheap and secure electronic direct debit system since the early 80s (only now replaced by a EU wide system that works pretty much the same) that was built by merchants and banks. Credit cards never managed to seriously make a dent in that market.
I'm not sure the unbanked demographic aligns well with a smartphone app that requires a data plan. If they are giving out debit cards to their customers they wouldn't be paying the interchange fees anyway (that's why companies like Target are always pushing the store branded cards).
Sadly, that same demographic is going to be paying for a large portion of their Walmart purchases with an EBT card (Walmart is the largest receiver of food stamp benefits). Maybe they will integrate that into CurrentC, but that sounds like a GOP wedge issue if I've ever heard one.
Sadly, that same demographic is going to be paying for a large portion of their Walmart purchases with an EBT card (Walmart is the largest receiver of food stamp benefits). Maybe they will integrate that into CurrentC, but that sounds like a GOP wedge issue if I've ever heard one.
Just being pedantic, but the more accurate term is: secure element. The SE has its own OS (JavaCard) and is usually directly wired to the NFC controller (no iOS in-between).
http://globalplatform.org/mediaguideSE.asp
http://globalplatform.org/mediaguideSE.asp
"Secure Enclave" was (is?) the term Apple was using for the "element" storing fingerprints for Touch ID.
http://www.apple.com/pr/library/2013/09/10Apple-Announces-iP...
http://www.apple.com/pr/library/2013/09/10Apple-Announces-iP...
The iPhone 6 has both a secure enclave, for Touch ID, and a secure element.
"Every time you hand over your credit or debit card to pay, your card number and identity are visible. With Apple Pay, instead of using your actual credit and debit card numbers when you add your card to Passbook, a unique Device Account Number is assigned, encrypted, and securely stored in the Secure Element, a dedicated chip in iPhone."
https://www.apple.com/iphone-6/apple-pay/
"Every time you hand over your credit or debit card to pay, your card number and identity are visible. With Apple Pay, instead of using your actual credit and debit card numbers when you add your card to Passbook, a unique Device Account Number is assigned, encrypted, and securely stored in the Secure Element, a dedicated chip in iPhone."
https://www.apple.com/iphone-6/apple-pay/
It's a lot simpler to steal a million people's identities in one shot than it is to mug a million people -- and that's not even getting into phone security.
MCX's privacy policy is a hoot, and worth a read if you like picking such things apart: http://currentc.com/50D6A97C-4B72-44D6-9021-BE0884ED2F8D/pri...
Where you see "enhance services", read it as "mine the hell out of your data and sell it". Amongst all of that "service enhancement", there's this gem: We do not respond to web browser “do not track” signals at this time.
They'll also track which pharmacy you go to, and the time and frequency of when you get your prescriptions. And so on, and so on. Apple and the rest of the NFC stakeholders could have a lot of fun with this. But I think they'll wisely just sit back for now and watch the whole thing blow up on its own.
Where you see "enhance services", read it as "mine the hell out of your data and sell it". Amongst all of that "service enhancement", there's this gem: We do not respond to web browser “do not track” signals at this time.
They'll also track which pharmacy you go to, and the time and frequency of when you get your prescriptions. And so on, and so on. Apple and the rest of the NFC stakeholders could have a lot of fun with this. But I think they'll wisely just sit back for now and watch the whole thing blow up on its own.
The fact that they've already had a data breach within the first week or so of launch is not exactly a strong argument for how secure their platform is.
I'm sure this is directly connected to the outrage at NFC payments being disabled in CVS, etc. - effectively, they've become a target.
That said, they're supposed to be a payments provider. They should be able to cope with being a target.
That said, they're supposed to be a payments provider. They should be able to cope with being a target.
I'm sure this is directly connected to the outrage at NFC payments being disabled in CVS, etc. - effectively, they've become a target.
If they weren't a target because of the NFC stuff then they would have become a target because they're a payment platform. The only difference is probably how quickly the hack happened (or how public it became). If it had been the Chinese or Russians they possibly would have just pilfered and sold personal data.
If they weren't a target because of the NFC stuff then they would have become a target because they're a payment platform. The only difference is probably how quickly the hack happened (or how public it became). If it had been the Chinese or Russians they possibly would have just pilfered and sold personal data.
They're not just supposed to be a payments provider. They're going to ask people to actually link their bank accounts so that the merchants don't have to pay credit card fees.
and the best bit -- the very best bit -- is should you be so stupid as to trust these idiots, you provide them direct access to your bank account. So when these morons donate your data to some smart hackers, instead of your credit cards getting drained, your checking account balance vanishes. It's not entirely clear what protections you have in that case.
Tell your friends and family not to be stupid -- never use a payment method on the internet besides a credit card. It's really simple: by law, you have no more than $50 liability for a fraudulent credit card transaction, vs $500 for a debit card. Plus in the former case, no money vanishes from your checking account, while in the latter, it may take several weeks for your money to come back. And while you are protected, in theory, under nacha rules and regulation E from liability for fraudulent ach transfers, you may still be out the money for a very long time while you fight with your bank. Here's a useful summary: http://www.fatwallet.com/forums/finance/1023728/m15101053/#m...
Tell your friends and family not to be stupid -- never use a payment method on the internet besides a credit card. It's really simple: by law, you have no more than $50 liability for a fraudulent credit card transaction, vs $500 for a debit card. Plus in the former case, no money vanishes from your checking account, while in the latter, it may take several weeks for your money to come back. And while you are protected, in theory, under nacha rules and regulation E from liability for fraudulent ach transfers, you may still be out the money for a very long time while you fight with your bank. Here's a useful summary: http://www.fatwallet.com/forums/finance/1023728/m15101053/#m...
You don't have protections. With MCX + CurrentC, the customer is liable for all fraud.
These idiot executives in MCX are so blind in their zeal to track customers everywhere, they never stopped to think of how reckless it is to make the customer liable.
These idiot executives in MCX are so blind in their zeal to track customers everywhere, they never stopped to think of how reckless it is to make the customer liable.
> These idiot executives in MCX are so blind in their zeal to track customers everywhere, they never stopped to think of how reckless it is to make the customer liable.
Do you mean reckless or potentially lucrative? My god! suddenly we don't have to eat fraud from credit card transactions (in increasingly large amounts come 2015 when liability gets pushed down to merchants by the card companies). They get extra customer data AND reduced liability. Sounds perfect.
Do you mean reckless or potentially lucrative? My god! suddenly we don't have to eat fraud from credit card transactions (in increasingly large amounts come 2015 when liability gets pushed down to merchants by the card companies). They get extra customer data AND reduced liability. Sounds perfect.
Apple won't ever admit it, but I'm sure they're loving this turn of events. Having potential competitor stumble before it's even launched is great publicity.
Probably from all the backlash. Reminds me of when Sony updated their PlayStations to not support Linux and subsequently got hacked.
But then those retailers disabled NFC at their registers,
ending their unofficial support for Apple Pay. The
problem, apparently, stemmed from the fact that
retailers’ contracts with MCX states they’re not
supposed to accept rival mobile payment products.
The FAQ (http://www.mcx.com/blog/answers-to-your-questions/) has a very evasive answer to the question "Does MCX Require its Merchants to Only Offer CurrentC?":
"MCX merchants make their own decisions about what solutions they want to bring to their customers; the choice is theirs. When merchants choose to work with MCX, they choose to do so exclusively and we’re proud of the long list of merchants who have partnered with us. Importantly, if a merchant decides to stop working with MCX, there are no fines." (emphasis mine)
The important part here, that they've clearly buried, is that yes, if you go MCX, you have to go all the way. While merchants can choose whether to use MCX or not, they cannot choose to use MCX and NFC. Any implication that they can is absolutely false.
"MCX merchants make their own decisions about what solutions they want to bring to their customers; the choice is theirs. When merchants choose to work with MCX, they choose to do so exclusively and we’re proud of the long list of merchants who have partnered with us. Importantly, if a merchant decides to stop working with MCX, there are no fines." (emphasis mine)
The important part here, that they've clearly buried, is that yes, if you go MCX, you have to go all the way. While merchants can choose whether to use MCX or not, they cannot choose to use MCX and NFC. Any implication that they can is absolutely false.
Any implication that they can is absolutely false.
But MCX is retailer owned - and even if it wasn't, there is nothing stopping MCX from varying the contract at a retailer's request. If Wal-Mart came along and said they would sign a contract, but only if the exclusivity language was removed, do you think MCX would turn them down? Of course they wouldn't, they can and they would change the contract.
The exclusivity clause is there because the retailers want it there.
> The exclusivity clause is there because the retailers want it there.
More accurately, I'd contend the exclusivity clause is there because every other retailer wants it there. You don't want it applied to yourself, but the only way it would work is if it bound everyone.
More accurately, I'd contend the exclusivity clause is there because every other retailer wants it there. You don't want it applied to yourself, but the only way it would work is if it bound everyone.
The tricky bit is that MCX is owned by the merchants. It's not like some third-party payment processor. So if you pay for a share of MCX, it's not going to be something you want to walk away from.
CurrentC will not fail because of this, they will fail because they use QR codes. An old lady could probably write a check faster than most people can scan a QR code.
I completely agree with this. QR codes are cumbersome and I refuse to allow any app using with QRCs at its core to touch any of my money.
To be fair it works the other way around--the retailer scans your phone with the QR code on the screen. Like Starbucks' app. It's still clumsy, especially compared to Apple Pay, but you don't have to use your camera for anything.
I looked for the picture I saw somewhere on the MCX website, but can't find it, so I'll have go with the same pic but from the MacRumors site: http://www.macrumors.com/2014/10/27/currentc-mobile-payments...
If I'm reading that diagram correctly, not only does the consumer have to scan a code, but the vendor then scans another code. So not one, but two QR code scans. The success is built in!
If I'm reading that diagram correctly, not only does the consumer have to scan a code, but the vendor then scans another code. So not one, but two QR code scans. The success is built in!
The TechCrunk article that MacRumors get their info from says: "When it’s time for a user to check out, they request to pay with CurrentC. The consumer then unlocks their phone, opens the CurrentC app, opens the code scanner, and scans the QR code shown on the cashier’s screen. In some case, the reverse may happen where the consumer’s CurrentC app displays a payment code and the cashier scans it."
So sounds like one or the other.
So sounds like one or the other.
Hmm, okay, I guess it could be just one scan.
But unrelated, the steps you quote: gawd dahyum. I'd rather stand behind the old lady writing a check, as mentioned by another commenter. Thing is, retailers have mostly solved the check-writing problem (but they still can't make Mr. OldSkool fill out everything but the amount before he gets to the front of the line). No more "I need check approval on aisle 3", no more 3 pieces of ID, just scan it and stick it in the drawer. It sounds like there's a strong possibility that they're bringing us back to the time when those behind get to roll their eyes and sigh as we all wait for the person at the front because "oh, gawd, they're using that thing".
But unrelated, the steps you quote: gawd dahyum. I'd rather stand behind the old lady writing a check, as mentioned by another commenter. Thing is, retailers have mostly solved the check-writing problem (but they still can't make Mr. OldSkool fill out everything but the amount before he gets to the front of the line). No more "I need check approval on aisle 3", no more 3 pieces of ID, just scan it and stick it in the drawer. It sounds like there's a strong possibility that they're bringing us back to the time when those behind get to roll their eyes and sigh as we all wait for the person at the front because "oh, gawd, they're using that thing".
> It sounds like there's a strong possibility that they're bringing us back to the time when those behind get to roll their eyes and sigh as we all wait for the person at the front because "oh, gawd, they're using that thing".
Except I doubt you'll ever see anyone actually use CurrentC.
Except I doubt you'll ever see anyone actually use CurrentC.
The MCX org can always pivot to some other payment system, that is still not Apple Pay.
Like what?
Sure, they don't have to re-do the backend, but there's still figuring out how to actually effect the transaction between the customer and merchant. They're already talking a 2015 launch date for this, possibly longer (can't find the article, but people involved in the project are shooting to get it done within 2 years). Changing out the front end app and store support hardware/software would just make the thing more likely to fail.
Sure, they don't have to re-do the backend, but there's still figuring out how to actually effect the transaction between the customer and merchant. They're already talking a 2015 launch date for this, possibly longer (can't find the article, but people involved in the project are shooting to get it done within 2 years). Changing out the front end app and store support hardware/software would just make the thing more likely to fail.
For instance, they could use a proprietary NFC solution. Works just like Apple Pay, just instead of a credit card number, it's a CurrentC account number. Sure it doesn't too well on iPhones, but I bet they could pay Samsung, etc. to include native support in their hardware, and that's a good chunk of the market.
Sure, but that's also adding several years and a huge amount of development time/risk - it's creating a whole new spec, implementing it in both handsets and payment terminals, and deploying those updates. During which time, the non-halfassed standard will be chugging along just fine, increasing marketshare and generally not sucking.
It's technically possible, but one of those things that's deeply unlikely to happen, particularly given the lead that Apple (and, very likely, Android in the near future) and the credit card companies have in rolling out a solution.
EDIT: added a missing word
It's technically possible, but one of those things that's deeply unlikely to happen, particularly given the lead that Apple (and, very likely, Android in the near future) and the credit card companies have in rolling out a solution.
EDIT: added a missing word
Since CurrentC blocked NFC technology at the terminal, it would be funny if Apple and Google blocked CurrentC from their app stores.
It would be funny for about a day, then you'd realize that the new Kings (Apple/Google) are being bad platform owners. They do enough of the blocking apps game on the sharecroppers.
With that said, CurrentC should go away but it isn't too bad to have some competition right now as this is such a huge change for the US finally. Paying from your phone will be the norm in 1-2 years and it will seem strange before that. We are finally joining the rest of the world, Finland has been doing it since the 90's. Whoever wins the riches should have to work for it a bit. I just hope it is the consumer friendly version that wins out.
With that said, CurrentC should go away but it isn't too bad to have some competition right now as this is such a huge change for the US finally. Paying from your phone will be the norm in 1-2 years and it will seem strange before that. We are finally joining the rest of the world, Finland has been doing it since the 90's. Whoever wins the riches should have to work for it a bit. I just hope it is the consumer friendly version that wins out.
I actually don't mind CurrentC on the playing field; I just don't agree with their terms to block all NFC transactions. I would like to see all of the payment methods play out; CurrentC may even offer something of value that Google and Apples products don't although that remains to be seen right now.
I don't think there's any point to this. It's going to fail on its own, why give them a place to point fingers?
Isn’t CurrentC a “physical-only” payment system, i.e. not supported for online transactions?
You're correct, but like Jeremy said, they have mobile apps in both the Apple [1] and Google [2] Store. Funny enough, they both have over 2000 ratings at 1 star.
[1] - https://itunes.apple.com/us/app/currentc/id912922036?mt=8
[2] - https://play.google.com/store/apps/details?id=com.currentc
[1] - https://itunes.apple.com/us/app/currentc/id912922036?mt=8
[2] - https://play.google.com/store/apps/details?id=com.currentc
Yes, but they need to have their payment apps on the devices to make those physical transactions.
[deleted]
You know what works every time, is accepted everywhere, has no processing fees, and won't leak your personal data?
Cash.
Cash.
It takes up more space in my wallet. If my wallet gets stolen then that money I'll never get back. And sometimes it takes up more time when making a transaction.
I always prefer cards. It's nice that all the transactions are recorded for when I'm reviewing taxes and my budgets.
When I had moved to SF my biggest annoyance was how my bank only had a few locations in the entire city. To escape ATM transaction fees I'd either have to haul my ass to one of these faraway ATM locations or get cash back from a store. I could've applied with another bank or credit union, but mostly didn't have to because the convenience of a credit card made mostly solved this issue as I never have to be concerned about how much cash I had on hand.
Furthermore, getting % back on my card is better through rewards than 0% using cash.
I always prefer cards. It's nice that all the transactions are recorded for when I'm reviewing taxes and my budgets.
When I had moved to SF my biggest annoyance was how my bank only had a few locations in the entire city. To escape ATM transaction fees I'd either have to haul my ass to one of these faraway ATM locations or get cash back from a store. I could've applied with another bank or credit union, but mostly didn't have to because the convenience of a credit card made mostly solved this issue as I never have to be concerned about how much cash I had on hand.
Furthermore, getting % back on my card is better through rewards than 0% using cash.
But if you carry too much of it around, you're a drug dealer and the police or TSA will steal it. Kind of a downer.
In reality, as a consumer, I average 3% back on credit cards. I probably average 2% fees on cash, between ATM fees and driving to free ATMs.
Plus if you lose you wallet, or something horrible happens when you have cash, it's gone. There is a bit of a hassle replacing cards, but you don't just lose your money.
Has no processing fees for the customer. Business banks charge dearly for cash handling.
* Plenty of online retailers won't take cash
* Both coins and high-denomination bills can be and have been refused by brick-n-mortar stores (not all or most but they are within their rights to refuse it as payment).
* Both coins and high-denomination bills can be and have been refused by brick-n-mortar stores (not all or most but they are within their rights to refuse it as payment).
The strangest part of my recent trip to Canada was places using cash. It was odd having that bulky stuff in my wallet, I haven't paid in cash for at least 5 years, for anything.
However, New Zealand has the world's largest use of card based payments - everyone takes cards, from the supermarket to the food trucks which are just taking off here.
Credit cards aren't widely accepted though, because of the fees. The bulk of the transactions are via EFTPOS, which has low to no fees for both parties.
However, New Zealand has the world's largest use of card based payments - everyone takes cards, from the supermarket to the food trucks which are just taking off here.
Credit cards aren't widely accepted though, because of the fees. The bulk of the transactions are via EFTPOS, which has low to no fees for both parties.
"Currency" would have been a better answer.
Except now I have to deal with shitty coins when I get back change...
They were hacked before even launching publicly. I suppose they're trying to build trust in their service early on.
We can only hope this uber-data mining [1] app has a swift death.
[1] - http://techcrunch.com/2014/10/25/currentc/
[1] - http://techcrunch.com/2014/10/25/currentc/
Good riddance. Leave the difficult problems to capable companies and let this be a lesson.
[deleted]
Considering the already known issues with CurrentC, where the customer is liable for any type of fraud and they want to connect directly to your bank account, not to mention potential issues with health information, I was already feeling roughly hell no on having anything to do with these guys. Having a data breach in like the first week only makes it look more dangerous.
I know it's just email addresses - this time. Sounds like next time, the hackers might be able to clear out the connected bank account, and you'll bear full liability.
I know it's just email addresses - this time. Sounds like next time, the hackers might be able to clear out the connected bank account, and you'll bear full liability.
I have more trust in Apple Pay and hope that wins.
Seems like CurrentC have a great product on their hands. Effectively they are cutting out the middle man and tying in a rewards program, not groundbreaking, but still a better deal than Apple's offering. If all else fails for them in the payments space, they have a great name that would allow them to pivot into the bottled juice market as well.
The fact this thing has not even launched fully just yet, worries me they have already been hacked. Just wait until CurrentC is rolled out to more vendors and adoption increases (if it happens), it will just make them a bigger target. To some of those vendors supporting CurrentC, I bet Apple Payments is looking more appealing right about now.
Pretty rookie error, lets hope they get their act together before a more widespread launch.
The fact this thing has not even launched fully just yet, worries me they have already been hacked. Just wait until CurrentC is rolled out to more vendors and adoption increases (if it happens), it will just make them a bigger target. To some of those vendors supporting CurrentC, I bet Apple Payments is looking more appealing right about now.
Pretty rookie error, lets hope they get their act together before a more widespread launch.
A "great product" from the perspective of a merchant who wants to not pay credit card processing fees. Not a great product from the other side of the transaction.
A great product for retailers perhaps (track the hell out of you customers and stop paying fees!), but that's only one side of the coin. T
he other side is who controls all the money and a less fast and less secure way to pay for things so that you have the privilege of being marketed to is not exactly "great product" territory.
There is a decent chance that CurrentC will fail before it ever launches.
he other side is who controls all the money and a less fast and less secure way to pay for things so that you have the privilege of being marketed to is not exactly "great product" territory.
There is a decent chance that CurrentC will fail before it ever launches.
how is this a good product? It's essentially making the payment workflow even more complicated for users. NFC or chip+pin is the way to go, as it's more user-friendly.
I actually like the idea of cutting out the middle man and tying in a rewards program. It is not a new idea as it follows reward incentive programs that everyone from airlines to retail stores have had for years. While we can not be sure that the saved credit card fees will not be pocketed, if they are not, then CurrentC could become something great.
The premise itself I am a fan of. Using QR codes however, not so much. The infrastructure can be changed though, if QR codes become too cumbersome, they have the power to change it.
I was being partially sarcastic in my initial comment, but partially serious.
The premise itself I am a fan of. Using QR codes however, not so much. The infrastructure can be changed though, if QR codes become too cumbersome, they have the power to change it.
I was being partially sarcastic in my initial comment, but partially serious.
They expect CurrentC users to get discounts that you wouldn't get with using a normal credit card.
Based on the fact that it will save merchants the credit card processing fee. They'll most likely pocket the difference instead of passing along the savings to the consumer, especially since there's no risk that their competitors will pass along the savings.
This is just the beginning.
Anyone who has account information stored in their care should pull it now.
Anyone who has account information stored in their care should pull it now.
Not typically possible with such systems.
And then you read what they show with just email addresses: http://www.imore.com/depth-look-currentc-and-personal-data-t...
Well at least this system is open with saying that it exists for the retailers to mine customer data. Looking at the technology, it seems it would just be faster to pay with a card than rely on my phones camera to make a payment.
[deleted]
However no personal data or payment card data was breached http://www.techworm.net/2014/10/currentc-hacked.html
Courtesy of Apple
The entire cellphone based NFC payment system is retarded. Money needs to be free from electricity and endure the elements.
I don't get it why they are not using proven NFC payment card systems like in japan...
I don't get it why they are not using proven NFC payment card systems like in japan...
As far as I can tell, they work exactly the same way. I was able to use my iPhone 6 at an NFC terminal (built for MasterCard PayPass/VISA PayWave) at Dublin Airport where nobody had ever used it before in that fashion.
I suspect it's the same as well. I think CurrentC wanted to stop Apple Pay and the rest were just collateral damage.
Which is stupid. Apple Pay is the most available way to pay for something that is as secure as chip & pin in the USA.
Which is stupid. Apple Pay is the most available way to pay for something that is as secure as chip & pin in the USA.
I have a feeling the MCX participants and card issuers are going to come to an impasse over their respective agreements. All the issuers have to do is require that terminals capable of NFC (for the purpose of accepting PayPass/PayWave) not have the functionality disabled. This will put the merchants in a bind and force them either to replace the terminals altogether, or re-enable NFC.
So what is the benefit of having it on a breakable heavy device with limited battery life?
It doesnt sound very enticing to me that I can't pay that taxi when it's raining because my battery ran out.
It doesnt sound very enticing to me that I can't pay that taxi when it's raining because my battery ran out.
Security and convenience; it's been covered ad nauseam elsewhere. And you can always use the plastic as a backup if you like.
How do you use "proven NFC payment card systems" without electricity? This isn't a sarcastic question, I'm genuinely curious.
You don't get why they're not using the system you just called "retarded"? You'll forgive me if I'm a bit confused.
Nah i mean in Japan i buy a credit card sized card. It is waterproof and I don't need to take care of it in any way. It has no battery, it does not stop working when dropped. It can stay in my wallet (just swipe the wallet) and you can buy small stuff with it (public transportation, corner store, supermarket, electronics store etc...).
I called it retarded to put the exact same technology into something that is heavier and prone to more defects.
The downvotes are plain silly because putting the same tech into a cellphone, while technically feasible, is inferior to those cards in (almost) every way. The only benefit is recharging over air or direct debit from your bank account. They should rather allow me to charge the card itself with the cellphones NFC.
I called it retarded to put the exact same technology into something that is heavier and prone to more defects.
The downvotes are plain silly because putting the same tech into a cellphone, while technically feasible, is inferior to those cards in (almost) every way. The only benefit is recharging over air or direct debit from your bank account. They should rather allow me to charge the card itself with the cellphones NFC.
Thanks for the clarification. I swear I read it twice trying to make sense of it. :-) I hear what you're saying, but we're unlikely to get that in the U. S. Hell, just getting chip-and-PIN has been moving along with all of the gracefulness and agility of a glacier.
5.) Walmart is like a monopoly. Tax deals as well as real estate location.
CVS, Walgreen are like a monopoly. Especially in Florida where 1/3
of population is older, retired or using Medicare.
6.)Identity theft is rising due to Affordable Health Care LAW, aka 'Obamacare.'
7.)Try to open an independent pharmacy in Florida and compete with the 24 hour, cut throat pricing of CVS, Walgreens. Like an EFFECTIVE monopoly.
8.)Your Grandma is NOT tech smart and lists her phone number in the phone book EXPOSED. She uses her name in her e-mail address. I use mail redirectors like 33mail and others as well as 'changing configurations.'
9.)As a non-public USA Citizen, it is AMAZING how many ROBOT phone calls I get on an unlisted phone number and how much spam and malware oritented stuff.
10.)why? The easiest and richest WHO OWN A HOUSE AND a BANK ACCOUNT that is public rrecord are the SAND STATES.
11.)why? why? the Sand States are fast growing and have retirees like Florida, Carolinas, Arizona (think Senator John McCain). and even California.
Not a lot of folks who love to LIVE IN North Dakota Winter. Unless you are a oil drilling FRACKER who is making 250 thousand a year and living in a trailer.
18.) SUMMARY: Attitude - CurrentC hires security codes for 'close to minium wage' - SO THE QUALITY IS FAR ABOVE THAT OF GOOGLE???? note: alleged and even stupidity can be relative in context. Top Management Stupidity - the top are marketers of HIGH END Soda. CVS pharmacy competes head to head against Publix Shopping Chain. The BIG FLASHING SIGN marquee says 'special deal on Coca Cola Soda. If Target and Home Depot Top Management have Never heard of BSD OS or even linux command [ lsof -i ], then there is little hope for the KEY PHARMACY SUPPLY CHAINS of the USA, in my opinion. Add in the screens of the hospital waiting rooms that SHOW WINDOWS XP or old version Windows NT which can cause some of HN to laugh out loud.
New chaos + Monopoly + Attitude + Rise of Botnets + Testers= YOUR Grandma + Old White Hair Consultant (think Captain Crunch) + Top Manager Stupidity == No Surprise
Do I expect the SWAT RAIDS on Grandma's house?... errr no rare that someone would borrow her identity as a 'tester' and
where are you hiding 'the pills' grandma?
*all respect to Grandma, she is used as a generalization. 1st amendment. fiction, no specialized mention of YOUR GRANDMA's name and no animals were hurt in the making of this message.
6.)Identity theft is rising due to Affordable Health Care LAW, aka 'Obamacare.'
7.)Try to open an independent pharmacy in Florida and compete with the 24 hour, cut throat pricing of CVS, Walgreens. Like an EFFECTIVE monopoly.
8.)Your Grandma is NOT tech smart and lists her phone number in the phone book EXPOSED. She uses her name in her e-mail address. I use mail redirectors like 33mail and others as well as 'changing configurations.'
9.)As a non-public USA Citizen, it is AMAZING how many ROBOT phone calls I get on an unlisted phone number and how much spam and malware oritented stuff.
10.)why? The easiest and richest WHO OWN A HOUSE AND a BANK ACCOUNT that is public rrecord are the SAND STATES.
11.)why? why? the Sand States are fast growing and have retirees like Florida, Carolinas, Arizona (think Senator John McCain). and even California.
Not a lot of folks who love to LIVE IN North Dakota Winter. Unless you are a oil drilling FRACKER who is making 250 thousand a year and living in a trailer.
18.) SUMMARY: Attitude - CurrentC hires security codes for 'close to minium wage' - SO THE QUALITY IS FAR ABOVE THAT OF GOOGLE???? note: alleged and even stupidity can be relative in context. Top Management Stupidity - the top are marketers of HIGH END Soda. CVS pharmacy competes head to head against Publix Shopping Chain. The BIG FLASHING SIGN marquee says 'special deal on Coca Cola Soda. If Target and Home Depot Top Management have Never heard of BSD OS or even linux command [ lsof -i ], then there is little hope for the KEY PHARMACY SUPPLY CHAINS of the USA, in my opinion. Add in the screens of the hospital waiting rooms that SHOW WINDOWS XP or old version Windows NT which can cause some of HN to laugh out loud.
New chaos + Monopoly + Attitude + Rise of Botnets + Testers= YOUR Grandma + Old White Hair Consultant (think Captain Crunch) + Top Manager Stupidity == No Surprise
Do I expect the SWAT RAIDS on Grandma's house?... errr no rare that someone would borrow her identity as a 'tester' and
where are you hiding 'the pills' grandma?
*all respect to Grandma, she is used as a generalization. 1st amendment. fiction, no specialized mention of YOUR GRANDMA's name and no animals were hurt in the making of this message.
Am I the only one that sees this as somewhat promising? They've become a massive target because of all the recent news with apple pay and whatnot, so it's not that surprising that there are people attacking them and all that was stolen (so far) was email addresses, but no actual important data. This is a pre-release system, it wouldn't be surprising to me if they just stole some logs off an under-protected email server that is being used to testing or something. Plus they're actually being open about it rather than just sweeping it under the rug like so many try.
Yes, it's never good when any amount of personal info is stolen, but it's just email addresses and if you're not already getting spam, you just haven't been using that address long enough.
Yes, it's never good when any amount of personal info is stolen, but it's just email addresses and if you're not already getting spam, you just haven't been using that address long enough.
They've become a massive target because of all the recent news with apple pay and whatnot
They're a payments platform, they should expect to ALWAYS be a HUGE target no matter WHAT the news is. If it's not the Apple & Google fans it will be the Chinese & Russians.
This is a pre-release system, it wouldn't be surprising to me if they just stole some logs off an under-protected email server that is being used to testing or something
Why would a pre-prod system even be accessible to the outside world? It shows a lack of judgement and experience in security that they either made an known insecure pre-production system accessible by the outside world OR they were not competent enough to secure the server properly. They are either ignorant or incompetent, neither of which are good when talking about a payment processor.
They're a payments platform, they should expect to ALWAYS be a HUGE target no matter WHAT the news is. If it's not the Apple & Google fans it will be the Chinese & Russians.
This is a pre-release system, it wouldn't be surprising to me if they just stole some logs off an under-protected email server that is being used to testing or something
Why would a pre-prod system even be accessible to the outside world? It shows a lack of judgement and experience in security that they either made an known insecure pre-production system accessible by the outside world OR they were not competent enough to secure the server properly. They are either ignorant or incompetent, neither of which are good when talking about a payment processor.
They're not just a payments platform that contains 16 digit CC#s, they also contain SSIDs, Drivers Licenses, Checking/Routing #s and the PID that goes along with that. My god, if you had that data, you could create all the 16 digits credit cards you would want, by forging those people's IDs. You could even create bank accounts in their name, and probably get a Passport.
Not just a small target...
Not just a small target...
I've reported so many serious web vulnerabilities to startups it isn't even funny (4-5 S14 YC batch alone). Account hijacks, XSS, SQLi. Everywhere.
If you are starting a startup (or writing any web software software), PLEASE read OWASP to at least get an idea of what types of issues can exist in Web Applications. Their top 10 is a good place to start (https://www.owasp.org/index.php/Top_10_2013-Top_10)