Category — security
ECHELON is a code word for an automated global interception system operated by the intelligence agencies of the United States, the United Kingdom, Canada, Australia, and New Zealand, and led by the National Security Agency (NSA). I’ve seen estimates that ECHELON intercepts as 3 billion communications every day, including phone calls, e-mail messages, Internet downloads, satellite transmissions, and so on. The system gathers all of these transmissions indiscriminately, then sorts and distills the information through artificial intelligence programs.
Bruce Schneier, Secrets and Lies,2004, 2nd ed.
July 15, 2013 No Comments
Mint.com is a great website in a lot of ways. It’s great to be able to track all your financial data in one place, it has a really nice user interface, and it’s free. But when a company has access to so much of your sensitive data, it is an understatement to say that they need to be really careful with that data. Today Mint did something to lose my trust forever, something that led me to cancel my account immediately.
Early this morning I received six blank emails from email@example.com. Being in the business, I immediately recognized that this was likely coming from Mint’s staging (test) server. I went to their support forums, searched for this issue, and found this thread. I was the eighth person to comment and now there are over 200 comments and counting. The main frustration seems to be with the fact that Mint tried to reassure users that no customer data is stored on the test system from which these emails originated. That begs the question: then why did it store our email addresses?
The websites I work on store far less sensitive user data than banking and credit card information, and yet we never EVER store real user email addresses (or mailing addresses or passwords) in our test environments. The fact that Mint screwed this up reveals a major lack of competence in the area of security. And security needs to be their top priority, or at the very least a core competency. If they aren’t getting this right, what else aren’t they getting right? Consequently, I cancelled my Mint account just about as fast I as could.
The lesson here is not so much that companies shouldn’t store real user data on their test systems, but that if they do, they need to clearly communicate that to customers. If Mint had said, we store no customer data in our test systems other than email addresses, I may have questioned why they needed our emails on the test environment, but I still might have trusted them. When they said they stored NO customer data on stage, and yet somehow that environment had my email address, well, then all trust is lost.
October 13, 2010 13 Comments
When I first read about Blippy on TechCrunch in December of last year, my first thought was “Oh God, this sharing thing has gone way too far.” My next thought was, “Note to self: stay far away from Blippy.”
For those who don’t know, Blippy is a “transaction sharing” site. You enter your credit card details and the site scrapes your account activity and posts it for your friends to see. Yay, my friend just bought a new toaster oven.
Apparently, they also, in a small number of cases, posted full credit card numbers on the Internets, which Google subsequently, dutifully, crawled.
This situation is utterly awful. Credit card theft is rampant (my wife just got notified yesterday of a fraudulent charge on her Visa card). Those roughly sixteen numbers are sacrosanct.
I don’t know who is stupider in this situation:
- Blippy, for creating a website that accesses user’s credit card accounts, scrapes their information, and broadcasts it for eternity (and does all of those things really badly, exposing sensitive data in the process)
- Blippy users, for signing up for such a dumbass idea and willfully handing over their credit card data
- Credit card companies, for creating a system where the only thing stopping someone from using my credit is not knowing the sixteen-digit number boldly printed on its face
Last night, Blippy issued an apology as well as a corrective plan of action. But this is too little too late. If you’re creating a website based on sharing my credit card transactions with my friends, isn’t your first and most important concern the security and privacy of the data? Or does that come down the road, after they’ve duped enough users into signing up?
An apology is simply not good enough. Nor is a corrective plan. Blippy needs to shut down their borked service and pack up the wax and feathers on which they’ve built their clusterfuck of a startup.
Related articles by Zemanta
- Blippy Issues, Resolutions, Plan (Ashvin Kumar/The Blippy Blog) (techmeme.com)
- Mint founder Aaron Patzer makes a slight jab at Blippy’s privacy woes (social.venturebeat.com)
- Give Blippy Another Chance, They Deserve It (thenextweb.com)
- Blippy claims credit card leak plugged. We find one more number (venturebeat.com)
- Blippy users’ credit card numbers exposed in search results (cnn.com)
April 27, 2010 No Comments
The reference to “Vista Basic” should’ve been a dead giveaway, but if I had stopped the video there I never would’ve gotten to the part about “but it was a Linksys, in my neighborhood!”
I’m a big fan of Leo Laporte’s podcasts This Week in Tech and Security Now, but I don’t usually listen to The Tech Guy. Maybe I should though because the way he handles this call is just so perfect. Not too condescending, very calm and reasonable, and, of course, just plain right.
February 23, 2010 2 Comments
As Internet users, many of us blindly trust that companies are making reasonable efforts to protect our privacy and our data. And then you read a story like this and you consider never signing up for another “Web 2.0″ service again.
RockYou, social network application developer, suffered a major SQL injection attack in which a hacker was able to retrieve email addresses and passwords for millions of user accounts. To make matters worse, since RockYou integrates with other platforms like Facebook and MySpace, users’ passwords for those networks were exposed as well. Part of the reason why it was so easy for the hacker to obtain the passwords was that RockYou was storing them unencrypted in their database.
This is very upsetting on many levels:
- It is beyond negligent to store your user’s passwords in plain text. Strong encryption is easy.
- Better yet, let someone else handle authentication for you. That’s what OpenID is for.
- After signup, RockYou would email its users with the username and password they’d just set up. Apparently it wasn’t enough to store the passwords in plain text, they also had to send it via an insecure protocol.
- RockYou asked users to enter their credentials for 3rd party sites directly on their site, and they promised that they wouldn’t save those 3rd party logins. Needless to say, they were lying.
- RockYou was informed of the vulnerability to SQL injection days before the hacker broke in and stole the passwords, and they didn’t act on it.
“We started off as a small company and today we have a different engineering structure…But shame on us. If you make a mistake, then people can get in and it is a big hole…Our security approach in the future will have to be deeper.”
Umm. No shit.
So what does this mean for you and me? Well, unfortunately there’s no way to know how secure your information is on any given site. Privacy policies don’t generally specify that passwords are encrypted in the database, or that the site has been coded to guard against many types of SQL injections. So I guess the takeaways are: be wary of sharing sensitive information in general; use lots of different passwords for various sites you sign up for; and never enter your credentials for one site on another site. Ever. The message for developers is: let someone else handle your login process via OpenID.
December 16, 2009 No Comments