CurrentC Has Been Hacked, Testers’ Email Addresses Stolen
techcrunch.com
techcrunch.com
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)
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
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.
In other words, for their users, not them.
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.
And then there's the possibility of XSS in which case neither lack of MitM access or use of HTTPS will be sufficient protection.
Just checked again and when I go to the card number screen it is now HTTPS.
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.
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.
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.
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.
You'll find security to be a far less daunting challenge when you chip away at the "unknown-unknowns."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
Imagine if we asked doctors for hints.
Don't you think it's time to get off your high horse?
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.
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.
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...
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.
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.
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.
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.
Both are bad. You can maybe prevent yourself from having to make this decision by being security aware from day0
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.
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.
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.
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.
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.
Your average web startup that's providing jazzy ringtones and a new poke app, sure, should leave security for last.
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.
Option 3) Spend the day fixing the security problem, then write a transparent post about it thus improving revenue/traction with new/existing users.
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.
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.
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.
... 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.
1: https://plus.google.com/+RipRowan/posts/eVeouesvaVXIt'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.
"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.
http://www.apple.com/pr/library/2013/09/10Apple-Announces-iP...
"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."
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...
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.
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.
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.
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.
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.
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.
That said, they're supposed to be a payments provider. They should be able to cope with being 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.
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...
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.
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.
Interesting example of applied public relations here - you want to do foo but you don't want to be blamed for doing foo, so you create a scapegoat organisation and have them take the blame."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.
This is the brilliance of this PR tactic - it seems just like that, doesn't it? I mean, when you sign a cell phone contract the contract you can't negotiate it, it's offered to you take-it-or-leave-it, right?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.
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.
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.
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
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!
So sounds like one or the other.
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".
Except I doubt you'll ever see anyone actually use CurrentC.
[1] - https://itunes.apple.com/us/app/currentc/id912922036?mt=8
[2] - https://play.google.com/store/apps/details?id=com.currentc
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.
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).
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.
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.
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.
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 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.
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.
Anyone who has account information stored in their care should pull it now.
I don't get it why they are not using proven NFC payment card systems like in japan...
Which is stupid. Apple Pay is the most available way to pay for something that is as secure as chip & pin in the USA.
It doesnt sound very enticing to me that I can't pay that taxi when it's raining because my battery ran out.
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.
He's talking about the consumer side, not the merchant side.
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.
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'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.
Not just a small target...