Entries Tagged "web"

Page 7 of 14

Google vs. China

I’m not sure what I can add to this: politically motivated attacks against Gmail from China. I’ve previously written about hacking from China. Shishir Nagaraja and Ross Anderson wrote a report specifically describing how the Chinese have been hacking groups that are politically opposed to them. I’ve previously written about censorship, Chinese and otherwise. I’ve previously written about broad government eavesdropping on the Internet, Chinese and otherwise. Seems that the Chinese got in through back doors installed to facilitate government eavesdropping, which I even talked about in my essay on eavesdropping. This new attack seems to be highly sophisticated, which is no surprise.

This isn’t a new story, and I wouldn’t have mentioned it at all if it weren’t for the surreal sentence at the bottom of this paragraph:

The Google-China flap has already reignited the debate over global censorship, reinvigorating human rights groups drawing attention to abuses in the country and prompting U.S. politicians to take a hard look at trade relations. The Obama administration issued statements of support for Google, and members of Congress are pushing to revive a bill banning U.S. tech companies from working with governments that digitally spy on their citizens.

Of course, the bill won’t go anywhere, but shouldn’t someone inform those members of Congress about what’s been going on in the United States for the past eight years?

In related news, Google has enabled https by default for Gmail users. In June 2009, I cosigned a letter to the CEO of Google asking for this change. It’s a good thing.

EDITED TO ADD (1/19): Commentary on Google’s bargaining position.

Posted on January 19, 2010 at 12:45 PM • View Comments

Privacy Violations by Facebook Employees

I don’t know if this is real, but it seems perfectly reasonable that all of Facebook is stored in a huge database that someone with the proper permissions can access and modify. And it also makes sense that developers and others would need the ability to assume anyone’s identity.

Rumpus: You’ve previously mentioned a master password, which you no longer use.

Employee: I’m not sure when exactly it was deprecated, but we did have a master password at one point where you could type in any user’s user ID, and then the password. I’m not going to give you the exact password, but with upper and lower case, symbols, numbers, all of the above, it spelled out ‘Chuck Norris,’ more or less. It was pretty fantastic.

Rumpus: This was accessible by any Facebook employee?

Employee: Technically, yes. But it was pretty much limited to the original engineers, who were basically the only people who knew about it. It wasn’t as if random people in Human Resources were using this password to log into profiles. It was made and designed for engineering reasons. But it was there, and any employee could find it if they knew where to look.

I should also say that it was only available internally. If I were to log in from a high school or library, I couldn’t use it. You had to be in the Facebook office, using the Facebook ISP.

Rumpus: Do you think Facebook employees ever abused the privilege of having universal access?

Employee: I know it has happened in the past, because at least two people have been fired for it that I know of.

[…]

Employee: See, the thing is—and I don’t know how much you know about it—it’s all stored in a database on the backend. Literally everything. Your messages are stored in a database, whether deleted or not. So we can just query the database, and easily look at it without every logging into your account. That’s what most people don’t understand.

Rumpus: So the master password is basically irrelevant.

Employee: Yeah.

Rumpus: It’s just for style.

Employee: Right. But it’s no longer in use. Like I alluded to, we’ve cracked down on this lately, but it has been replaced by a pretty cool tool. If I visited your profile, for example, on our closed network, there’s a ‘switch login’ button. I literally just click it, explain why I’m logging in as you, click ‘OK,’ and I’m you. You can do it as long as you have an explanation, because you’d better be able to back it up. For example, if you’re investigating a compromised account, you have to actually be able to log into that account.

Rumpus: Are your managers really on your ass about it every time you log in as someone else?

Employee: No, but if it comes up, you’d better be able to justify it. Or you will be fired.

Rumpus: What did they do?

Employee: I know one of them went in and manipulated some other person’s data, changed their religious views or something like that. I don’t remember exactly what it was, but he got reported, got found out, got fired.

Posted on January 19, 2010 at 11:25 AM • View Comments

Reacting to Security Vulnerabilities

Last month, researchers found a security flaw in the SSL protocol, which is used to protect sensitive web data. The protocol is used for online commerce, webmail, and social networking sites. Basically, hackers could hijack an SSL session and execute commands without the knowledge of either the client or the server. The list of affected products is enormous.

If this sounds serious to you, you’re right. It is serious. Given that, what should you do now? Should you not use SSL until it’s fixed, and only pay for internet purchases over the phone? Should you download some kind of protection? Should you take some other remedial action? What?

If you read the IT press regularly, you’ll see this sort of question again and again. The answer for this particular vulnerability, as for pretty much any other vulnerability you read about, is the same: do nothing. That’s right, nothing. Don’t panic. Don’t change your behavior. Ignore the problem, and let the vendors figure it out.

There are several reasons for this. One, it’s hard to figure out which vulnerabilities are serious and which are not. Vulnerabilities such as this happen multiple times a month. They affect different software, different operating systems, and different web protocols. The press either mentions them or not, somewhat randomly; just because it’s in the news doesn’t mean it’s serious.

Two, it’s hard to figure out if there’s anything you can do. Many vulnerabilities affect operating systems or Internet protocols. The only sure fix would be to avoid using your computer. Some vulnerabilities have surprising consequences. The SSL vulnerability mentioned above could be used to hack Twitter. Did you expect that? I sure didn’t.

Three, the odds of a particular vulnerability affecting you are small. There are a lot of fish in the Internet, and you’re just one of billions.

Four, often you can’t do anything. These vulnerabilities affect clients and servers, individuals and corporations. A lot of your data isn’t under your direct control—it’s on your web-based email servers, in some corporate database, or in a cloud computing application. If a vulnerability affects the computers running Facebook, for example, your data is at risk, whether you log in to Facebook or not.

It’s much smarter to have a reasonable set of default security practices and continue doing them. This includes:

1. Install an antivirus program if you run Windows, and configure it to update daily. It doesn’t matter which one you use; they’re all about the same. For Windows, I like the free version of AVG Internet Security. Apple Mac and Linux users can ignore this, as virus writers target the operating system with the largest market share.

2. Configure your OS and network router properly. Microsoft’s operating systems come with a lot of security enabled by default; this is good. But have someone who knows what they’re doing check the configuration of your router, too.

3. Turn on automatic software updates. This is the mechanism by which your software patches itself in the background, without you having to do anything. Make sure it’s turned on for your computer, OS, security software, and any applications that have the option. Yes, you have to do it for everything, as they often have separate mechanisms.

4. Show common sense regarding the Internet. This might be the hardest thing, and the most important. Know when an email is real, and when you shouldn’t click on the link. Know when a website is suspicious. Know when something is amiss.

5. Perform regular backups. This is vital. If you’re infected with something, you may have to reinstall your operating system and applications. Good backups ensure you don’t lose your data—documents, photographs, music—if that becomes necessary.

That’s basically it. I could give a longer list of safe computing practices, but this short one is likely to keep you safe. After that, trust the vendors. They spent all last month scrambling to fix the SSL vulnerability, and they’ll spend all this month scrambling to fix whatever new vulnerabilities are discovered. Let that be their problem.

Posted on December 10, 2009 at 1:13 PM • View Comments

Security in a Reputation Economy

In the past, our relationship with our computers was technical. We cared what CPU they had and what software they ran. We understood our networks and how they worked. We were experts, or we depended on someone else for expertise. And security was part of that expertise.

This is changing. We access our email via the web, from any computer or from our phones. We use Facebook, Google Docs, even our corporate networks, regardless of hardware or network. We, especially the younger of us, no longer care about the technical details. Computing is infrastructure; it’s a commodity. It’s less about products and more about services; we simply expect it to work, like telephone service or electricity or a transportation network.

Infrastructures can be spread on a broad continuum, ranging from generic to highly specialized. Power and water are generic; who supplies them doesn’t really matter. Mobile phone services, credit cards, ISPs, and airlines are mostly generic. More specialized infrastructure services are restaurant meals, haircuts, and social networking sites. Highly specialized services include tax preparation for complex businesses; management consulting, legal services, and medical services.

Sales for these services are driven by two things: price and trust. The more generic the service is, the more price dominates. The more specialized it is, the more trust dominates. IT is something of a special case because so much of it is free. So, for both specialized IT services where price is less important and for generic IT services—think Facebook—where there is no price, trust will grow in importance. IT is becoming a reputation-based economy, and this has interesting ramifications for security.

Some years ago, the major credit card companies became concerned about the plethora of credit-card-number thefts from sellers’ databases. They worried that these might undermine the public’s trust in credit cards as a secure payment system for the internet. They knew the sellers would only protect these databases up to the level of the threat to the seller, and not to the greater level of threat to the industry as a whole. So they banded together and produced a security standard called PCI. It’s wholly industry-enforced ­ by an industry that realized its reputation was more valuable than the sellers’ databases.

A reputation-based economy means that infrastructure providers care more about security than their customers do. I realized this 10 years ago with my own company. We provided network-monitoring services to large corporations, and our internal network security was much more extensive than our customers’. Our customers secured their networks—that’s why they hired us, after all—but only up to the value of their networks. If we mishandled any of our customers’ data, we would have lost the trust of all of our customers.

I heard the same story at an ENISA conference in London last June, when an IT consultant explained that he had begun encrypting his laptop years before his customers did. While his customers might decide that the risk of losing their data wasn’t worth the hassle of dealing with encryption, he knew that if he lost data from one customer, he risked losing all of his customers.

As IT becomes more like infrastructure, more like a commodity, expect service providers to improve security to levels greater than their customers would have done themselves.

In IT, customers learn about company reputation from many sources: magazine articles, analyst reviews, recommendations from colleagues, awards, certifications, and so on. Of course, this only works if customers have accurate information. In a reputation economy, companies have a motivation to hide their security problems.

You’ve all experienced a reputation economy: restaurants. Some restaurants have a good reputation, and are filled with regulars. When restaurants get a bad reputation, people stop coming and they close. Tourist restaurants—whose main attraction is their location, and whose customers frequently don’t know anything about their reputation—can thrive even if they aren’t any good. And sometimes a restaurant can keep its reputation—an award in a magazine, a special occasion restaurant that “everyone knows” is the place to go—long after its food and service have declined.

The reputation economy is far from perfect.

This essay originally appeared in The Guardian.

Posted on November 12, 2009 at 6:30 AM • View Comments

Too Many Security Warnings Results in Complacency

Research that proves what we already knew:

Crying Wolf: An Empirical Study of SSL Warning Effectiveness

Abstract. Web users are shown an invalid certificate warning when their browser cannot validate the identity of the websites they are visiting. While these warnings often appear in benign situations, they can also signal a man-in-the-middle attack. We conducted a survey of over 400 Internet users to examine their reactions to and understanding of current SSL warnings. We then designed two new warnings using warnings science principles and lessons learned from the survey. We evaluated warnings used in three popular web browsers and our two warnings in a 100-participant, between-subjects laboratory study. Our warnings performed significantly better than existing warnings, but far too many participants exhibited dangerous behavior in all warning conditions. Our results suggest that, while warnings can be improved, a better approach may be to minimize the use of SSL warnings altogether by blocking users from making unsafe connections and eliminating warnings in benign
situations.

Posted on August 4, 2009 at 10:01 AM • View Comments

Strong Web Passwords

Interesting paper from HotSec ’07: “Do Strong Web Passwords Accomplish Anything?” by Dinei Florêncio, Cormac Herley, and Baris Coskun.

ABSTRACT: We find that traditional password advice given to users is somewhat dated. Strong passwords do nothing to protect online users from password stealing attacks such as phishing and keylogging, and yet they place considerable burden on users. Passwords that are too weak of course invite brute-force attacks. However, we find that relatively weak passwords, about 20 bits or so, are sufficient to make brute-force attacks on a single account unrealistic so long as a “three strikes” type rule is in place. Above that minimum it appears that increasing password strength does little to address any real threat If a larger credential space is needed it appears better to increase the strength of the user ID’s rather than the passwords. For large institutions this is just as effective in deterring bulk guessing attacks and is a great deal better for users. For small institutions there appears little reason to require strong passwords for online accounts.

Posted on July 13, 2009 at 5:38 AM • View Comments

Choosing a Bad Password Has Real-World Consequences

Oops:

Wikileaks has cracked the encryption to a key document relating to the war in Afghanistan. The document, titled “NATO in Afghanistan: Master Narrative”, details the “story” NATO representatives are to give to, and to avoid giving to, journalists.

An unrelated leaked photo from the war: a US soldier poses with a dead Afghani man in the hills of Afghanistan

The encrypted document, which is dated October 6, and believed to be current, can be found on the Pentagon Central Command (CENTCOM) website.

Posted on March 9, 2009 at 1:19 PM • View Comments

1 … 5 6 7 8 9 … 14

Sidebar photo of Bruce Schneier by Joe MacInnis.