Slashdot Mirror

You've got to be kidding! In theory, the readers, and by extension the posters, of /. are better educated than the run-of-the-mill sheep in this country, but I really doubt that now. Does anyone actually read stories like this, this, or this.

People, let's start using that grey matter for once. Yes, there are definitely people who would want to blow up planes, and yes, there are ways that it could be done. The War on Moisture isn't going to make anyone safer. Beyond the huge inconvenience and expense factor (read Schneier's Wired essay (I posted the link to his blog rather than the Wired article due to updates), a simple question of proportion should come in here. According to the US government's own statistics, fewer than 2,000 people were killed WORLDWIDE in 2004 by terrorists. Even if you add in the thousands of people killed on 9/11, you're still talking about 10,000 people, tops. Compare that to the number of people killed each year in car crashes (38,000 US fatalities in 2004), malaria (1,000,000 to 3,000,000 per year worldwide, mostly in Africa), or heart disease (276 out of ever 100,000 people in the US in 1996, or 22,800 in New York City alone). In fact, if the statistics are right, more people are hit by lightning each year (1 person out of every 600,000 per year, or 10,000 worldwide) than are killed by terrorists.

So, are you going to stop driving your car? Stop smoking/drinking? Stop taking romantic walks in the rain? (ok, so maybe not a good one on /.) Think of all the lives that would be saved if the billions of dollars that are being spent protecting us from push-up bras and shampoo were spent on finding a cure for malaria, or tuburculosis, or lung cancer, or AIDS.

Bah, the world is filled with nothing but sheep.

You've got to be kidding! In theory, the readers, and by extension the posters, of /. are better educated than the run-of-the-mill sheep in this country, but I really doubt that now. Does anyone actually read stories like this, this, or this.

People, let's start using that grey matter for once. Yes, there are definitely people who would want to blow up planes, and yes, there are ways that it could be done. The War on Moisture isn't going to make anyone safer. Beyond the huge inconvenience and expense factor (read Schneier's Wired essay (I posted the link to his blog rather than the Wired article due to updates), a simple question of proportion should come in here. According to the US government's own statistics, fewer than 2,000 people were killed WORLDWIDE in 2004 by terrorists. Even if you add in the thousands of people killed on 9/11, you're still talking about 10,000 people, tops. Compare that to the number of people killed each year in car crashes (38,000 US fatalities in 2004), malaria (1,000,000 to 3,000,000 per year worldwide, mostly in Africa), or heart disease (276 out of ever 100,000 people in the US in 1996, or 22,800 in New York City alone). In fact, if the statistics are right, more people are hit by lightning each year (1 person out of every 600,000 per year, or 10,000 worldwide) than are killed by terrorists.

So, are you going to stop driving your car? Stop smoking/drinking? Stop taking romantic walks in the rain? (ok, so maybe not a good one on /.) Think of all the lives that would be saved if the billions of dollars that are being spent protecting us from push-up bras and shampoo were spent on finding a cure for malaria, or tuburculosis, or lung cancer, or AIDS.

Bah, the world is filled with nothing but sheep.

USBDumper

USBDumper (article is in French; here's the software) is a cute little utility that silently copies the contents of an inserted USB drive onto the PC. The idea is that you install this piece of software on your computer, or on a public PC, and then you collect the files -- some of them personal and confidential -- from anyone who plugs their USB drive into that computer. (This blog post talks about a version that downloads a disk image, allowing someone to recover deleted files as well.)

No big deal to anyone who worries about computer security for a living, but probably a rude shock to salespeople, conference presenters, file sharers, and many others who regularly plug their USB drives into strange PCs.

I have a write-protected PNY USB drive I use to carry around my tools, but now that I know about malware like this, I think I'm going to go to the trouble of burning a CD every week or so. Biggest trouble is going to be keeping AV signatures up to date.

"Recently, a coworker tried to assert that encrypting a file twice with a 64 bit algorithm is equivalent to encrypting it once with a 128 bit algorithm. I know enough about encryption to know that isn't true, but I am having difficulties explaining why and how. Doesn't each pass of the encryption create a separate file header which makes this assertion untrue? Can anyone point me to references that would better help me explain this?"

First of all, what is a '64-bit encryption algorithm'? Is this a symmetric or asymmetric algorithm? Is it a block or stream cipher? Are you talking about block or key sizes? What specific algorithm are you referring to?

We can't analyze anything if all we're given are vague generalizations like "a 64-bit algorithm" and "a 128-bit algorithm". Some symmetric ciphers gain security under functional composition. We know that DES is one such cipher, since it has been shown that DES is not a group. However, it is not true in general that symmetric ciphers gain security under composition. For example, no matter how many times you encrypt something using a Caesar cipher (a generalization of ROT-13), there will always be a single key that decodes the resulting ciphertext. Ask your coworker to show that the specific algorithm you're discussing is not a group. If he can't, then what reason do you have to believe that you gain any security through what he proposes?

The second problem here is that your coworker seems to think that the onus is on you to prove that a given system is insecure. Every time an expert invents a new cryptosystem, there is a good chance that the system will be insecure; It is a near-certainty that any cryptosystem your coworker comes up with will be insecure. Bruce Schneier brought up this topic again in this month's Crypto-Gram :

Anyone can invent a security system that he himself cannot break. I've said this so often that Cory Doctorow has named it "Schneier's Law": When someone hands you a security system and says, "I believe this is secure," the first thing you have to ask is, "Who the hell are you?" Show me what you've broken to demonstrate that your assertion of the system's security means something.

Thirdly, even if your coworker's new cipher design---and that's what it is---miraculously has the security properties that he thinks it does, is that enough? If you're using 128-bit keys in a symmetric cipher, you're only getting 64 bits of security, thanks to the "Birthday Paradox". If you want an attacker to have to perform 2^128 steps to brute-force your key, then you should be using 256-bit keys anyway. Justin Troutman explains this in more detail in his two-part series, "Ideal-to-Realized Security Assurance In Cryptographic Keys".

Finally, all this talk about composing cipher primitives might well be irrelevant. What is this cipher being used for? Disk-based encryption, for example, has vastly different requirements than a typical secure channel. (See New Methods in Hard Disk Encryption for a discussion of some of the issues associated with hard disk encryption.) What mode of operation are you using? What are you using for authentication? How much information does your cryptosystem leak? How are you negotiating what protocol you're using? To what extent is your protocol switch vulnerable to a chosen protocol attack? What about implementation issues?

I suggest that your coworker read the first two chapters

"Recently, a coworker tried to assert that encrypting a file twice with a 64 bit algorithm is equivalent to encrypting it once with a 128 bit algorithm. I know enough about encryption to know that isn't true, but I am having difficulties explaining why and how. Doesn't each pass of the encryption create a separate file header which makes this assertion untrue? Can anyone point me to references that would better help me explain this?"

First of all, what is a '64-bit encryption algorithm'? Is this a symmetric or asymmetric algorithm? Is it a block or stream cipher? Are you talking about block or key sizes? What specific algorithm are you referring to?

We can't analyze anything if all we're given are vague generalizations like "a 64-bit algorithm" and "a 128-bit algorithm". Some symmetric ciphers gain security under functional composition. We know that DES is one such cipher, since it has been shown that DES is not a group. However, it is not true in general that symmetric ciphers gain security under composition. For example, no matter how many times you encrypt something using a Caesar cipher (a generalization of ROT-13), there will always be a single key that decodes the resulting ciphertext. Ask your coworker to show that the specific algorithm you're discussing is not a group. If he can't, then what reason do you have to believe that you gain any security through what he proposes?

The second problem here is that your coworker seems to think that the onus is on you to prove that a given system is insecure. Every time an expert invents a new cryptosystem, there is a good chance that the system will be insecure; It is a near-certainty that any cryptosystem your coworker comes up with will be insecure. Bruce Schneier brought up this topic again in this month's Crypto-Gram :

Anyone can invent a security system that he himself cannot break. I've said this so often that Cory Doctorow has named it "Schneier's Law": When someone hands you a security system and says, "I believe this is secure," the first thing you have to ask is, "Who the hell are you?" Show me what you've broken to demonstrate that your assertion of the system's security means something.

Thirdly, even if your coworker's new cipher design---and that's what it is---miraculously has the security properties that he thinks it does, is that enough? If you're using 128-bit keys in a symmetric cipher, you're only getting 64 bits of security, thanks to the "Birthday Paradox". If you want an attacker to have to perform 2^128 steps to brute-force your key, then you should be using 256-bit keys anyway. Justin Troutman explains this in more detail in his two-part series, "Ideal-to-Realized Security Assurance In Cryptographic Keys".

Finally, all this talk about composing cipher primitives might well be irrelevant. What is this cipher being used for? Disk-based encryption, for example, has vastly different requirements than a typical secure channel. (See New Methods in Hard Disk Encryption for a discussion of some of the issues associated with hard disk encryption.) What mode of operation are you using? What are you using for authentication? How much information does your cryptosystem leak? How are you negotiating what protocol you're using? To what extent is your protocol switch vulnerable to a chosen protocol attack? What about implementation issues?

I suggest that your coworker read the first two chapters

Bruce Schneier, the dean of crypto and security processes generally, yesterday debunked this plot as "implausible".

A British diplomat (to Uzbekistan, an actual center of the Qaeda War) warns us to be skeptical of the plot. Especially its timing, which was premature for destroying a possible network, but right on time to steal headlines from a primary defeat from a leading neocon that drew defensive scare propaganda from Bush and Cheney even though it's a Democratic primary.

As we see more and more of our Republican government terrorizing us on their campaign schedule, we have more chances to turn against them, and fight our own war against terror ourselves, in our own minds and at the polls. We can replace anyone in the House of Representatives and 1/3 of the Senate.

Bruce Schneier, the dean of crypto and security processes generally, yesterday debunked this plot as "implausible".

A British diplomat (to Uzbekistan, an actual center of the Qaeda War) warns us to be skeptical of the plot. Especially its timing, which was premature for destroying a possible network, but right on time to steal headlines from a primary defeat from a leading neocon that drew defensive scare propaganda from Bush and Cheney even though it's a Democratic primary.

As we see more and more of our Republican government terrorizing us on their campaign schedule, we have more chances to turn against them, and fight our own war against terror ourselves, in our own minds and at the polls. We can replace anyone in the House of Representatives and 1/3 of the Senate.

This post is very interesting, I found it on Bruce Schneier's blog.

Bruce Schneier linked to another post which had an interesting take by a chemist in a graduate program. He describes details of the chemicals involved and what it would take to detonate them effectively onboard a plane.

The summary: improvised explosives involve pretty nasty stuff that you'd be hard pressed to mix in an airplane lavatory without killing yourself in the process.

'"I refuse to participate in your shared hallucination." -- Dilbert'

Wise words. I wish more people would live by them

I would find this whole airport security thing rather amusing, if it weren't such a pain in the tuckus. I think Bruce Schneier summed it up rather nicely in his latest Crypto-gram when he characterised all these draconian restrictions as 'Security Theatre' - something that looks like security to those who don't know any better, but ultimately has no real effect.

He also points out that if we're to learn anything from this event, it's that classical police/intelligence operations work. Authorities knew about the would-be bombers well in advance, they learned as much as they could about the cell, then shut it down before it could do damage. Biometric IDs, airport baggage checks, no-fly lists and other kinds of security theatre contributed nothing whatsoever to the outcome.

Bruce Schneier here refers to an article which claims that polygraphs have a 12% false positve rate, so apparently they are not much better than the system proposed in the original article.

Such systems almost invariably fall over due to the FP/FN rates and the "low rate fallacy". Here's the ever-reliable Schneier on the subject. Profound, simple, enables everyone to immediately debunk much of the security theatre we are surrounded by these days. (warning, don't try arguing it out with a cop or other jumped-up little hitler type as you are likely to find yourself banged up for being a smart-arse, barrack-room lawyer or similar troublemaker.)

Actually, no, none of these really benefit from "truly random numbers"

A random number generator is the best way to generate good cryptographic keys. Pseudo-random numbers are not good enough, in fact that is the commonest kind of "snake oil" in the encryption world. See Bruce Schneier's site for examples.

A very long random sequence can be used as a one-time pad, giving completely unbreakable encryption if the sequence is truly random.

Smaller, lighter, more fuel-efficient jets - sorry, but smaller, lighter jets are more INEFFICENT on a cost per pax-mile basis. See my post: http://slashdot.org/comments.pl?sid=193740&cid=158 86935 If smaller jets were more efficent, the airlines would be buying them in droves. But the general jist of your argument is quite valid. The term you were getting near is "Security Theatre" - the appearance of security vs. the actual thing. Bruce Schnier popularized the phrase. http://www.schneier.com/

Your right to walk the streets unmolested by the police outweighs my right not to get blown up.

The NSA have nothing that could compete with a current low-end commodity part. Here's a rare peek inside the NSA, don't you feel glad these clowns are monitoring our discussion?

Bruce Schneier has pointed out that the underlying problem with click fraud is the way that the incentives are set up. If it is in the fraudster's interest to try to spoof the system, this is going to happen, and both fraudsters and would-be fraud-busters are going to spend time and effort on an "arms race" that has no winners. He recommends that Google and co.

Change the rules of the game so that click fraud doesn't matter. That's how to solve a security problem.

cf. http://www.schneier.com/essay-119.html for Schneier's own words

Bruce Schneier has pointed out that the underlying problem with click fraud is the way that the incentives are set up. If it is in the fraudster's interest to try to spoof the system, this is going to happen, and both fraudsters and would-be fraud-busters are going to spend time and effort on an "arms race" that has no winners. He recommends that Google and co.

Change the rules of the game so that click fraud doesn't matter. That's how to solve a security problem.

cf. http://www.schneier.com/essay-119.html for Schneier's own words

It's impressive that these rivals have banded together to address click-fraud, but don't forget that Google has other tricks up its corporate sleeves. As seen here a little while back, they are also looking into "cost per action" ads, which would eliminate the fraud unless the action itself could be performed in a fraudulent manner. (Bruce Schneier mentioned it in a commentary about click fraud.)

Schneier's take and Penny Arcade's take. Just give up and enter junk for the questions. If you lose your password, call someone.

The point is: if the computer trusts someone else more than the end-user, in a security sense, then the end-user is not in control of the security of their machine. In a corporate IT context, this is (generally) a good thing. In an individually-owned computer, this is not really a good thing.

The real issue is the method in which the numbers were obtained. They were gathered without warrents or court orders, i.e. they were illegally obtained.

This bad is because 1) the President/gov't is *not* suppose to be above the law, 2) any evidence obtained from this ill gotten booty would not be usable in court, this in turn makes convicting the terrorist that much more difficult and 3) the harm done out weighs the benefits.

Wouldn't the right of free assembly(1st amendment) and the right against unreasonable searches(4th amendment) come into play when tracking calls? It's ok for the gov't to disregard those rights in the pursuit of ______?

The Constitution was written as an attempt to prevent tyranny, by chipping away at the Bill of Rights and increasing the Executive branch's power(back-boor vetos) US citizens continue to lose legal means of protecting themselves from a tyrannical government.

Here is some reading material for you:
Bruce Schenier on NSA & Bush's illegal wiretaps
Bush blocks internal probe into illegal wiretaps
An Imminent Threat (to the Constitution)

There is more involved than just tracking who you are calling. That's just the cover story to distract you while the power grab is going on.

Only thing that is worth mentioning was that the telephone networks ( cellular and POTS ) were jammed due to excessive calls.

The cellular network was nerfed so that the terrorists couldn't MAYBE trigger other attacks with them. It wasn't just excessive calls. Source.

No, I haven't heard about the MD5 and SHA-1 "breaks". What I have heard about is the MD5 and SHA-1 _collision_ scenarios. That's vastly different from a break.

That's an odd statement to make. If you have an algorithm that is claimed to be a collision-resistant hash function, and you can find a collision in fewer operations than brute force, then the algorithm is broken.

Quoting from Bruce Schneier's Self-study course in block cipher cryptanalysis:

Breaking a cipher doesn't necessarily mean nding a practical way for an eavesdropper to recover the plaintext from just the ciphertext. In academic cryptography, the rules are relaxed considerably. Breaking a cipher simply means finding a weakness in the cipher that can be exploited with a complexity less than brute-force. Never mind that brute-force might require 2^128 encryptions; an attack requiring 2^110 encryptions would be considered a break. Breaks might also require unrealistic amounts of known or chosen plaintext---2^56 blocks---or unrealistic amounts of storage: 2^80 . Simply put, a break can just be a "certicational weakness": evidence that the cipher does not perform as advertised.

Successful cryptanalysis might mean showing a break against a reduced-round variant of the cipher---8-round DES versus the full 16-round DES, for example or a simplied variant of the cipher. Most breaks start out as cryptanalysis against reduced-round variants, and are eventually (maybe years later) extended to the full cipher. In fact, a break on a reduced-round version of a cipher is often a publishable result.

If you read the literature, you'll find that Bruce is correct.

From the same author, here is the announcement of the SHA-1 break:

February 15, 2005
SHA-1 Broken
SHA-1 has been broken. Not a reduced-round version. Not a simplified version. The real thing.

If you had searched Google for SHA-1 broken, you could have figured that out yourself. Please do some fact-checking next time.

No, I haven't heard about the MD5 and SHA-1 "breaks". What I have heard about is the MD5 and SHA-1 _collision_ scenarios. That's vastly different from a break.

That's an odd statement to make. If you have an algorithm that is claimed to be a collision-resistant hash function, and you can find a collision in fewer operations than brute force, then the algorithm is broken.

Quoting from Bruce Schneier's Self-study course in block cipher cryptanalysis:

Breaking a cipher doesn't necessarily mean nding a practical way for an eavesdropper to recover the plaintext from just the ciphertext. In academic cryptography, the rules are relaxed considerably. Breaking a cipher simply means finding a weakness in the cipher that can be exploited with a complexity less than brute-force. Never mind that brute-force might require 2^128 encryptions; an attack requiring 2^110 encryptions would be considered a break. Breaks might also require unrealistic amounts of known or chosen plaintext---2^56 blocks---or unrealistic amounts of storage: 2^80 . Simply put, a break can just be a "certicational weakness": evidence that the cipher does not perform as advertised.

Successful cryptanalysis might mean showing a break against a reduced-round variant of the cipher---8-round DES versus the full 16-round DES, for example or a simplied variant of the cipher. Most breaks start out as cryptanalysis against reduced-round variants, and are eventually (maybe years later) extended to the full cipher. In fact, a break on a reduced-round version of a cipher is often a publishable result.

If you read the literature, you'll find that Bruce is correct.

From the same author, here is the announcement of the SHA-1 break:

February 15, 2005
SHA-1 Broken
SHA-1 has been broken. Not a reduced-round version. Not a simplified version. The real thing.

If you had searched Google for SHA-1 broken, you could have figured that out yourself. Please do some fact-checking next time.

As I understand it, RFID cards don't do anything until they're exposed to an electromagnetic field, which gives them just enough juice to fire off a message, usually an identity code.

They can broadcast whatever they like. In the case of passports, it's much of the information in your passport: name, gender, birthdate, nationality. Several countries are trying to get various forms of biometric information, especially your passport photo.

Unless I've been completely misinformed, you'd have to generate quite the field to even have a chance of reading one of these things at a distance. I know that my RFID card doesn't work until it's within a coupla inches of the appropriate reader.

That's because there is no good reason for, say, an RFID door key reader to detect keys furthere away than a few inches. Any further and you risk someone loitering near the door accidentally letting a bad guy in.

If you're actively interested in reading RFID at a distance, the rules change. The theft detectors in stores are all RFID and some have ranges of 5 or so feet. At least one group has developed tech capable of reading RFID at 69-feet. (Sadly the 1, 2.) It's a big rig, but small enough to hide in the trunk of a large car.

The whole "it's broadcasting all of your personal information!!!!" hype is a bunch of FUD. The only way it could really be a security risk is if the card itself was stolen, and then it's really no different than having your S.S. card or driver's license stolen.

It's broadcasting most of the information in your passport: name, date of birth, gender, nationality. The last one is perhaps the most important. Want to kill some Americans, but don't want to be nearby when it happens? Plant a bomb attached to an RFID reader. You don't need 69 feet of range, 10 or so will be plenty. When it detects 2 or more American passports nearby, explode. Looking for an American to kidnap? Future versions are likely going to be broadcasting a low-resolution version of your passport photo. Set up a scanner in your backpack and wander around.

Only because people raised concerns like this the passport design was modified with a shield in the front cover. If the passport is closed, in theory no data is broadcast. That reduces the exposure, which is good, but isn't perfect. If you're in a foreign country you need to display your passport occasionally: airports, checking into hotels, and the like. The window of exposure is smaller, but not zero.

The new design also includes a thin radio shield in the cover, protecting the chip when the passport is closed.

According to Schneier the State Department already plans (and has since sometime last year) to include a RF shield so the chip can only be read while the passport is open and they are encrypting the data on the RFID.

Schneier goes back and forth on the issue depending on the current proposed implementation of the technology. Schneier thought that particular implementation proposal looked promising.

Later articles discuss flaws:

http://www.schneier.com/blog/archives/2005/11/the_ security_of_2.html
http://www.schneier.com/essay-093.html

Schneier goes back and forth on the issue depending on the current proposed implementation of the technology. Schneier thought that particular implementation proposal looked promising.

Later articles discuss flaws:

http://www.schneier.com/blog/archives/2005/11/the_ security_of_2.html
http://www.schneier.com/essay-093.html

In a November 2005 article, noted security expert Bruce Schneier states that the maximum distance at which an RFID chip had been read so far was 69 feet.

See "The Security of RFID Passports" in Crypto-Gram #0511.

The article also has links to Schneier's other writing upon the subject.

...

The new design also includes a thin radio shield in the cover, protecting the chip when the passport is closed. More good security.

Assuming that the RFID passport works as advertised (a big "if," I grant you), then I am no longer opposed to the idea.

...

I don't have an exact figure, but there are roughly 500 airports with commercial flights into and out of them in the United States. Some of them only have a couple of scheduled flights a day. At, say, $25 million a pop, it will cost $12.5 billion dollars to equip all those airports with such a system, plus operating costs (presumably you have to have at least one guy babysitting the thing).

And you pretty much have to install these things everywhere an airliner flies. Terrorists aren't stupid (well, actually the evidence is that most of them are, but that's another story. Assuming they're stupid isn't a good idea IMO). They'll realise that if these systems exist, they should pick somewhere that's unlikely to be equipped with it. So while the planes at LAX and La Guardia land and take off with laser-guarded safety, our friendly local terrorists cruise on down to Bum's Rush, Iowa, and take potshots at the one RJ that lands there every day.

But assume these things *do* get installed in every airport in the country. What do our terrorists do? They scrap plan A - missiles at airplane takeoff - and go to the equally lethal plan B, a couple of tonnes of explosives under the grandstand at the local high school football game. Or any one of plans C through ZZ. So we've blown 10 billion dollars to achieve very, very little.

This is almost a quintessential example of protecting against a movie plot threat.

...he says he wants his assessment back.

I was hoping that the website would explain this. Did you RTFM? Assuming you did not. The advantage that still exists is that OTP, even over SMS is much harder to intercept than standing behind someone at an airport kioske or sniffing wireless networks...

This is hilarious. My idea of TFM is this. Your system does not provide the advantage of the One Time Pad. Which of course is encryption and perfect encryption at that. The advantage you seem to be summing this up with, is that the passwords are used only once. So that is a One Time Password system and nothing like a One Time Pad.

You could actually get the benefits of the One Time Pad to provide single use passwords, but not the way you want to do it. You could have a list of strong passwords on the target login server. You will need an OTP for each user on the server and you will also need to distribute the appropriate One Time Pads to each individual user. When a user wishes to log in, they enter their username and then a "challenge" is provided, which is really the password they have just been one-time allocated for that session, encrypted against that users next free One Time Pad block. The user decrypts the password from his One Time Pad and then logs in. At this point, that used One Time Pad block is erased from the users machine, the server and the one-time password is also erased.

Obviously there are major impracticalities to this and thus the general use of One Time Pads.

The first and worst, is that you need to generate non-algorithmically lots of decent One Time Pads on an on-going basis and then somehow distribute them to your users in a secure channel. If you had access to such a secure channel between you and your users at arbitrary times, you would not need the impractical One Time Pad.

Second, your users need to somehow securely store thier current One Time Pad and it needs to be capable of being securely erased really fast. Is this going to be done with more practical algorithmic crypto? If so, the perfect strength of the One Time Pad may be gone.

Third big problem is that you can't store password hashes on the server, instead of the passwords themselves, for the simple reason that sending a user a one-way hash of a password is not going to give them access.

There are lots of one time password systems. Why we should choose your system and how does it provides the benefits of the One Time Pad?

Get a WRT54 - GL or whatever they're calling it. It's a great router.

Put openwrt on it. http://openwrt.org/

Don't wait. http://www.schneier.com/blog/archives/2006/06/gree k_wiretappi.html

Back in 2004 some of the highest-ranking politicians and other most influential people in Greece had their cell phone conversations surreptitiously recorded by an unknown organization for a period of months.

The job could not have been pulled off without the presence of automated wire-tapping functionality built into the Ericsson switches in Greece. What makes the "greek experience" relevant here is that Greece didn't even purchase the wire-tapping "option" to their switches, it would have cost millions more and they decided to save the money and thought that by not purchasing the extra software and hardware they didn't even have to worry about the issue. They were very wrong.

If ever there was proof that wire-tapping features built into systems for law-enforcement use can and will be exploited by unauthorized users, this is it. It really does not get more clean-cut than this - except for the speculation as to who exactly these unauthorized wire-tappers were - the leading candidate is the CIA. Which would lead even just a mildly paranoid person to wonder if perhaps the FBI is jealous of the CIA's latitude in foreign operations and they just want the same, easily-abused by themselves, features within their own jurisdiction.

The Sears Tower plot was foiled the old-fashioned, and effective way -- by infiltration.

Mass eavesdropping has been proven to harm homeland security. The problem is that it doesn't "gather a little more information about suspected terrorists", it gathers information about all 300 million people in the US.

Targeted eavesdropping is still available just like it's always been -- just name the target and get a rubber-stamp FISA warrant, even after the fact.

And blocking Western Union transfers to people with Arab names doesn't do one single solitary blasted thing to make anyone any safer.

If they can duplicate one thumbprint, it's because they have a stash of gummi bears in which case they can duplicate other thumbprints and you have a total break.

Most biometric spoofing problems can be addressed by putting the reader in a public space or under the eye of a security guard who can say "excuse me, sir, why are you holding a photograph up to the iris reader?".

This article is terrible and contains no real facts. It is full of buzz words for management.

Go read Schneier. It may seem that most of what he writes is not security related, but it usually it. All forms of security are related. It is important to look at the big security picture and not concentrate on the individual technology pieces.

..people want to attack bigger targets more than smaller ones.

Twelve thousand machines was the entire vulnerable and exposed population, and Witty infected them all -- worldwide -- in 45 minutes. It's the first worm that quickly corrupted a small population. Previous worms targeting small populations such as Scalper and Slapper were glacially slow.

Read and understand Schneier's book Secrets and Lies. The problem is described in the preface.

Read and understand Schneier's book Secrets and Lies. The problem is described in the preface.

Just to make this clear, "security" is not an end item. You cannot "have" security. My definition is: The process of identifying and evaluating threats and reducing their effectiveness.

As Bruce says, when there isn't an economic incentive, that process is not maintained.

But, suppose you are maintaining it. How do you know how good your security is?

Bruce also wrote about "attack trees".
http://www.schneier.com/paper-attacktrees-ddj-ft.h tml

Identifying and evaluating the different avenues of attack is part of evaluating the threats. Once you've identified one, don't think about how you can "prove" it is "secure". Think about how you would go about showing that it is NOT secure. Make your statements about your security "falsifiable". Just like in the scientific method.

Then experiment, on an on-going-basis, to see if you can demonstrate that your security can be broken. This takes time and effort on your part as you have to continually read about the latest advances and theories.

Which gets back to the economic issue. If the organization does not see an economic incentive for you to perform that research/work, then you will be assigned to other tasks and the process will not be followed. If you are not following the process, there is no "security".

I don't understand why there would be any greater implications from this event than any other. All kinds of organizations have been compromised; this is far from news, and just another example of why most security experts recommend a "multi-tiered" password scheme for users. A set of passwords, of varying importance...for the most critical things, a longer and stronger password, another middle-level password to use at other sites of lesser importance (like webmail) and a throwaway password for things that don't matter to you so much. Best of all, use unique passwords for the high-importance site, if you use something like Password Safe for Windows, KeePass for Linux, or Keyring for PalmOS to keep track of them securely.

While your account information may be personal to you, these records constitute business records that are owned by AT&T.

This really summarizes the legal problems with privacy here in the US. Although the data that people collect on you is "personal to you", it almost always, legally, belongs to whoever collected it. The hodgepodge of Federal and state laws doesn't help. For example, here in Virginia, my medical records are the property of my doctor. It was only relatively recently that legislation was passed that gives me the statutory right to see my own medical records.

This also relates directly to the more-or-less careless approach many firms take to protecting personal data. If the data belongs to them, they are that much more insulated from any legal consquences of losing it.

Bruce Schneier has discussed this in a number of his blog posts and essays.

The main point to be made here is that you do not store sensitive data in a location which is not physicaly secure. Not a home office , not a desktop machine anywhere and certainly not a laptop. But in a locked and secure server room. Also if you want a secure environment -- disable your companies desktop USB ports:- http://www.schneier.com/crypto-gram-0606.html#6

Reasons other companies provide weak security

Unbiased evidence of companies providing weak data security is easy to find. A search on the internet for "password recovery" reveals how anyone can instantly unprotect files used by top-selling software.

Strong data security generally requires effective use of strong cryptographic standards. But companies have reasons for not including effective cryptographic software in their products. Reasons may include:

• desire to sell to countries that restrict imports or use of effective cryptographic software
• desire to export outside U.S. and Canada without the Bureau of Industry and Security (BIS) revoking authorization to use License Exception ENC during or after the 30-day review
• desire to export without filing semi-annual reports to BIS that must include the names and addresses of each individual customer located outside U.S. and Canada

Make the Social Security Number public to EVERYONE.

That's right, cat's out of the bag. Can of worm has been opened. Too late.

Ban use of Social Security Number as an identifier, except for Social Security, like it was supposed to be in the first place.

Each business entities must use their OWN issued numbers.

Wide-reaching Identity Theft Containment problem limited to just the affected business.

Now, it is time to look into three-way public keys to ensure that consumer data is not misused:

      1. Merchant/Business/Corporation
      2. End-user/User/
      3. Arbitrator/Government

With keys signed by each other in 3-ways, secured identification and security of data compartmentilization has been greatly enhanced.

Each and every transaction is signed, sealed and delivered by all 3 parties.

Now, let's get an infrastructure going on this...

Even Bruce Schneier agrees to this.

It's there already: http://www.schneier.com/blog/archives/2006/06/the_ doghouse_kr.html