The Emperor's new clothes

The UK's Register has been running a a series of articles by John Leyden  (here, here and here) about Verified By Visa. (VByV)  Verified By Visa uses the same kind of “site redirection” I've written about many times with respect to OpenID and other password-based federation technologies – but in this case it is a banking password that can be stolen.

The phishing scenario is simple enough.  If you happen onto an “evil” site and are tricked into purchasing something, it can “misdirect” your browser to a counterfeit VByV signon page.  As John explains, you have little chance, as a user, of knowing you are being duped, but once you enter your password it is available to the evil site for both instant use an future reuse.  Those familiar with this site will understand that this is yet another example of an attack that cannot be made against Information Card users.

Beyond focussing attention on the phishing problems inherent in “site redirection” approaches, John argues that the system – though claiming to be more secure – is actually just as vulnerable as non-VByV mechanisms.  He then argues – and I have know knowledge as to whether this is the case – that the false claims about increased security are being used to reject complaints by end-users about irregularities and fraudulent purchases made in their name.  If that were true, it would be scandalous.

Friends, this is a case of “The Writing on the Wall”.  I think people in the industry should see John's work as a sign of what's to come.   He is the guy in the fable who is shouting out that “the Emperor has no clothes!”  And he's doing it cogently to the wide readership of the Register.

If I were an advisor to the emperor at this point I would insist on two things: 

  1. admit the vulnerability of all systems based on “site redirection”; and
  2. start getting into phishing-resistant technologies like Information Cards while one's modesty can still be protected.

John makes his points without the stench of jargon.  In spite of this, North American readers will require a dictionary to follow what he's saying (I did).  I'm talking here about a dictionary of British idioms (thanks to my friend Richard Turner for boosting my vocabulary on this one) :

punter n guy. A punter is usually a customer of some sort (the word originally meant someone who was placing bets at a racecourse)…

To see a bit of what mainstream press worldwide will be writing about as the paucity of redirection technology for long-tail scenarios is concerned, I do suggest looking first hand at these articles.  One small taste:

Both Verified by Visa (VbyV) and MasterCard's equivalent SecureCode service are marketed as offering extra security checks to online purchases. Importantly, the schemes also transfer liability for bogus transactions away from merchants who use the system back towards banks (and perhaps ordinary e-commerce punters).

Online shoppers who buy goods and service with participating retailers are asked to submit a VbyV or SecureCode password to authorise transactions. These additional checks are typically submitted via a website affiliated to a card-issuing bank but with no obvious connection to a user's bank.

Punters aren't informed up front that a merchant has signed up to Verified by Visa. Sites used to authenticate a VbyV or SecureCode password routinely deliver a dialogue box using a pop-up window or inline frame, making it difficult to detect whether or not a site is genuine.

The appearance of phishing attacks hunting for Verified by Visa passwords are among the reasons some punters are wary of the technology.

Once obtained by fraudsters, either by direct phishing attack or through other more subtle forms of social engineering trickery, VbyV login credentials make it easier for crooks to make purchases online while simultaneously making it harder for consumers to deny responsibility for a fraudulent transaction…

The little-publicised mandatory use of the technology by some banks means that those with reservations have an uphill struggle to opt out of the scheme…

Verified by Visa and Mastercard SecureCode are there purely to protect the banks, not the card holder. They offer zero additional protection to the consumer, but allow the bank to claim that transactions using purloined credit card credentials were really made by the card holder. It is as simple as that.

[More here}.


Hole in Google SSO service

Some days you get up and wish you hadn't.  How about this one:

Google SSO problem

The ZDNet article begins by reassuring us:

“Google has fixed an implementation flaw in the single sign-on service that powers Google Apps follow a warning from researchers that remote attackers can exploit a hole to access Google accounts.

“The vulnerability, described in this white paper (.pdf), affects the SAML Single Sign-On Service for Google Apps.

“This US-CERT notice describes the issue:

“A malicious service provider might have been able to access a user’s Google Account or other services offered by different identity providers. [US-CERT actually means ‘by different service providers’ – Kim]

“Google has addressed this issue by changing the behavior of their SSO implemenation. Administrators and developers were required to update their identity provider to provide a valid recipient field in their assertions.

“To exploit this vulnerability, an attacker would have to convince the user to login to their site

Incredibly basic errors

The paper is by Alessandro Armando,  Roberto Carbone, Luca Compagna, Jorge Cuellar, and Llanos Tobarra, who are affiliated with University of Genoa, Siemens and SAP, and is one of an important series of studies demonstrating the value of automated protocol verification systems.

But the surprising fact is that the errors made are incredibly basic – you don't need an automated protocol verification system to know which way the wind blows.  The industry has known about exactly these problems for a long time now.   Yet people keep making the same mistakes.

Do your own thing

The developers decided to forget about the SAML specification as it's written and just “do their own thing.”  As great as this kind of move might be on the dance floor, it's dangerous when it comes to protecting peoples’ resources and privacy.  In fact it is insideous since the claim that Google SSO implemented a well vetted protocol tended to give security professionals a sense of confidence that we understood its capabilities and limitations.  In retrospect, it seems we need independent audit before we depend on anything.  Maybe companies like Fugen can help in this regard?

What was the problem?

Normally, when a SAML relying party wants a user to authenticate through SAML (or WS-Fed), the replying party sends her to an identity provider with a request that contains an ID and a scope  (e.g. URL) to which the resulting token should apply.

For example, in authenticating someone to identityblog, my underlying software would make up a random authentication ID number and the scope would be  The user would carry this information with her when she was redirected to the identity provider for authantication.

The identity provider would then ask for a password, or examine a cookie, and sign an authentication assertion containing the ID number, the scope, the client identity, and the identity provider's identity.  

Having been bound together cryptographically in a tamperproof form where authenticity of the assertion could be verified, these properties would be returned to the relying party.  Because of the unique ID, the relying party knows this assertion was freshly minted in response to its needs.  Further, since the scope is specified, the relying party can't abuse the assertion it gets at some other scope.

But according to the research done by the paper's authors, the Google engineers “simplified” the protocol, perhaps hoping to make it “more efficient”?  So they dropped the whole ID and scope “thing” out of the assertion.  All that was signed was the client's identity.

The result was that the relying party had no idea if the assertion was minted for it or for some other relying party.  It was one-for-all and all-for-one at Google.

Wake up to insider attacks

This might seem reasonable, but it sure would sure cause me sleepless nights.

The problem is that if you have a huge site like Google, which brings together many hundreds (thousands?) of services, then with this approach, if even ONE of them “goes bad”, the penetrated service can use any tokens it gets to impersonate those users at any other Google relying party service.

It is a red carpet for insider attacks.  It is as though someone didn't know that insider attacks represent the overwhelming majority of attacks.  Partitioning is the key weapon we have in fighting these attacks.  And the Google design threw partitioning to the wind.  One hole in the hull and the whole ship goes down.

Indeed the qualifying note in the ZD article that “to exploit this vulnerability, an attacker would have to convince the user to login to their site” misses the whole point about how this vulnerability facilitates insider attacks.  This is itself worrisome since it seems that thinking about the insider isn't something that comes naturally to us.

Then it gets worse.

This is all pretty depressing but it gets worse.  At some point, Google decided to offer SSO to third party sites.  But according to the researchers, at this point, the scope still was not being verified.  Of course the conclusion is that any service provider who subscribed to this SSO service – and any wayward employee who could get at the tokens – could impersonate any user of the third party service and access their accounts anywhere within the Google ecosystem.

My friends at Google aren't going to want to be lectured about security and privacy issues – especially by someone from Microsoft.  And I want to help, not hinder.

But let's face it.  As an industry we shouldn't be making the kinds of mistakes we made 15 or 20 years ago.  There must be better processes in place.  I hope we'll get to the point where we are all using vetted software frameworks so this kind of do-it-yourself brain surgery doesn't happen. 

Let's work together to build our systems to protect them from inside jobs.  If we all had this as a primary goal, the Google SSO fiasco could not have happened.  And as I'll make clear in an upcoming post, I'm feeling very strongly about this particular issue.

Problem between keyboard and seat

Jeff Bohren picks up on Axel Nennker's recent post:

Axel Nennker points out that the supposed “Cardspace Hack” is still floating around the old media. He allows the issue is not really a Cardspace security hole, but a problem between the keyboards and seats at Ruhr University Bochum:

A while ago two students, Xuan Chen and Christoph Löhr, from Ruhr University Bochum claimed to have “broken” CardSpace. There were some blog reactions to this claim. The authoritative one of course is from Kim.

Today I browsed through a magazine lying on the desk of a colleague of mine. This magazine with the promising title “IT-Security” repeats the false claim and reports that the students proved that CardSpace has severe security flaws… Well, when you switch off all security mechanism then, yes, there are security flaws (The security researcher in front of the computer).

Sort of what developers like me call an ID10T error.

Update: speaking of ID10T errors, I originally mistyped Axel’s name as Alex. My apologies.

How to set up your computer so people can attack it

As I said in the previous post, the students from Ruhr Universitat who are claiming discovery of security vulnerabilities in CardSpace did NOT “crack” CardSpace.
Instead, they created a demonstration that requires the computer's owner to consciously disable the computer's defenses through complex configurations – following a recipe they published on the web.

The students are not able to undermine the system without active co-operation by its owner. 

You might be thinking a user could be tricked into accidently cooperating with the attack..  To explore that idea, I've captured the steps required to enable the attack in this video.  I suggest you look at this yourself to judge the students’ claim they have come up with a “practical attack”.

 In essence, the video shows that a sophisticated computer owner is able to cause her system to be compromised if she chooses to do so.  This is not a “breach”.

Students enlist readers’ assistance in CardSpace “breach”

Students at Ruhr Universitat Bochum in Germany have published an account this week describing an attack on the use of CardSpace within Internet Explorer.  Their claim is to “confirm the practicability of the attack by presenting a proof of concept implementation“.

I’ve spent a fair amount of time reproducing and analyzing the attack.  The students were not actually able to compromise my safety except by asking me to go through elaborate measures to poison my own computer (I show how complicated this is in a video I will post next).  For the attack to succeed, the user has to bring full administrative power to bear against her own system.  It seems obvious that if people go to the trouble to manually circumvent all their defenses they become vulnerable to the attacks those defenses were intended to resist.  In my view, the students did not compromise CardSpace.

DNS must be undermined through a separate (unspecified) attack

To succeed, the students first require a compromise of a computer’s Domain Name System (DNS).  They ask their readers to reconfigure their computers and point to an evil DNS site they have constructed.  Once we help them out with this, they attempt to exploit the fact that poisoned DNS allows a rogue site and a legitimate site to appear to have the same internet “domain name” (e.g. .  Code in browser frames animated by one domain can interact with code from other frames animated by the same domain.  So once DNS is compromised, code supplied by the rogue site can interfere with the code supplied by the legitimate site.  The students want to use this capability to hijack the legitimate site’s CardSpace token.

However, the potential problems of DNS are well understood.  Computers protect themselves from attacks of this kind by using cryptographic certificates that guarantee a given site REALLY DOES legitimately own a DNS name.  Use of certificates prevents the kind of attack proposed by the students.

The certificate store must also “somehow be compromised”

But this is no problem as far as the students are concerned.  They simply ask us to TURN OFF this defense as well.  In other words, we have to assist them by poisoning all of the safeguards that have been put in place to thwart their attack.  

Note that both safeguards need to be compromised at the same time.  Could such a compromise occur in the wild?  It is theoretically possible that through a rootkit or equivalent, an attacker could completely take over the user’s computer.  However, if this is the case, the attacker can control the web browser, see and alter everything on the user’s screen and on the computer as a whole, so there is no need to obtain the CardSpace token.

I think it is amazing that the Ruhr students describe their attack as successful when it does NOT provide a method for compromising EITHER DNS or the certificate store.  They say DNS might be taken over through a drive-by attack on a badly installed wireless home network.  But they provide no indication of how to simultaneously compromise the Root Certificate Store. 

In summary, the students’ attack is theoretical.  They have not demonstrated the simultaneous compromise of the systems necessary for the attack to succeed.

The user experience

Because of the difficulty of compromising the root certificate store, let’s look at what would happen if only DNS were attacked.

Internet Explorer does a good job of informing the user that she is in danger and of advising her not to proceed. 

First the user encounters the following screen, and has to select “Continue to the website (not recommended)”:

If recalcitrant, the user next sees an ominous red band warning within the address bar and an unnaturally long delay:

The combined attacks require a different yet coordinated malware delivery mechanism than a visit to the phishing site provides.  In other words, accomplishing two or more attacks simultaneously greatly reduces the likelihood of success.

The students’ paper proposes adding a false root certificate that will suppress the Internet Explorer warnings.  As is shown in the video, this requires meeting an impossibly higher bar.  The user must be tricked into importing a “root certificate”.  This by default doesn’t work – the system protects the user again by installing the false certificate in a store that will not deceive the browser.  Altering this behavior requires a complex manual override.

However, should all the planets involved in the attack align, the contents of the token are never visible to the attacker.  They are encrypted for the legitimate party, and no personally identifying information is disclosed by the system.  This is not made clear by the students’ paper.

What the attempt proves 

The demonstrator shows that if you are willing to compromise enough parts of your system using elevated access, you can render your system attackable.   This aspect of the students’ attack is not noteworthy. 

There is, however, one interesting aspect to their attack.  It doesn’t concern CardSpace, but rather the way intermittent web site behavior can be combined with DNS to confuse the browser.  The student’s paper proposes implementing a stronger “Same Origin Policy” to deal with this (and other) possible attacks.  I wish they had concentrated on this positive contribution rather than making claims that require suspension of disbelief. 

The students propose a mechanism for associating Information Card tokens with a given SSL channel.   This idea would likely harden Information Card systems and is worth evaluating.

However, the students propose equipping browsers with end user certificates so the browsers would be authenticated, rather than the sites they are visiting.  This represents a significant privacy problem in that a single tracking key would be used at all the sites the user visits.  It also doesn’t solve the problem of knowning whether I am at a “good” site or not.  The problem here is that if duped, I might provide an illegitimate site with information which seriously damages me.

One of the most important observations that must be made is that security isn’t binary – there is no simple dichotomy between vulnerable and not-vulnerable.  Security derives from concentric circles of defense that act cumulatively and in such a way as to reinforce one another.  The title of the students’ report misses this essential point.  We need to design our systems in light of the fact that any system is breachable.  That’s what we’ve attempted to do with CardSpace.  And that’s why there is an entire array of defenses which act together to provide a substantial and practical barrier against the kind of attack the students have attempted to achieve.

From The Economist: the Identity Parade

It's great to see mainstream publications really taking the time to understand and convey the issues of digital identity and privacy.  A recent article in the Economist discussed the Laws of Identity at length.  Cambridge researcher Ross Anderson and others are quoted as well.  Here's an excerpt that gives you a sense for the full article

Internet users have become used to providing personal information to any convincing-looking box that appears on a screen. They have little idea of either the technology that helps to provide electronic security in practice or the theoretical principles that determine whether it will work. According to Mr Cameron, “there is no consistent and comprehensible framework allowing them to evaluate the authenticity of the sites they visit, and they don't have a reliable way of knowing when they are disclosing private information to illegitimate parties. At the same time they lack a framework for controlling or even remembering the many different aspects of their digital existence”…

Cybercrime discredits the use of the internet not only by business but by government too. Mr Cameron suggests rethinking the whole issue, starting from the principle that users may be identified only with their explicit consent. That sounds commonsensical, but many big government databases do things differently. Britain's planned central records for the NHS, for example, will assume consent as it combines all the medical records held in local practice databases.

The second principle, says Mr Cameron, should be to keep down the risk of a breach by using as little information as possible to achieve the task in hand. This approach, which he calls “information minimalism”, rules out keeping information “just in case”. For example, if a government agency needs to check if someone falls into a certain age group, it is far better to acquire and store this information temporarily as a “yes” or “no” than to record the actual date of birth permanently, which would be much more personal and therefore more damaging if leaked.

Third, identity systems must be able to check who is asking for the information, not just hand it over. How easy it is for the outside world to access such information should depend on whose identity it is. Public bodies, Mr Cameron suggests, should make themselves accessible to all comers. Private individuals, by contrast, should be protected so that they have to identify themselves only temporarily and by choice…

[More here…]

UK Chip and PIN vulnerable to simple attack

LightBlueTouchpaper, a blog by security researchers at Cambridge University, has posted details of a study documenting easy attacks on the new generation of British bank cards.  Saar Drimer explains, “This attack can capture the card’s PIN because UK banks have opted to issue cheaper cards that do not use asymmetric cryptography”.  Let's all heed the warning: 

Steven J. Murdoch, Ross Anderson and I looked at how well PIN entry devices (PEDs) protect cardholder data. Our paper will be published at the IEEE Symposium on Security and Privacy in May, though an extended version is available as a technical report. A segment about this work will appear on BBC Two’s Newsnight at 22:30 tonight.

We were able to demonstrate that two of the most popular PEDs in the UK — the Ingenico i3300 and Dione Xtreme — are vulnerable to a “tapping attack” using a paper clip, a needle and a small recording device. This allows us to record the data exchanged between the card and the PED’s processor without triggering tamper proofing mechanisms, and in clear violation of their supposed security properties. This attack can capture the card’s PIN because UK banks have opted to issue cheaper cards that do not use asymmetric cryptography to encrypt data between the card and PED.

Ingenico attack Dione attack

In addition to the PIN, as part of the transaction, the PED reads an exact replica of the magnetic strip (for backwards compatibility). Thus, if an attacker can tap the data line between the card and the PED’s processor, he gets all the information needed to create a magnetic strip card and withdraw money out of an ATM that does not read the chip.

We also found that the certification process of these PEDs is flawed. APACS has been effectively approving PEDs for the UK market as Common Criteria (CC) Evaluated, which does not equal Common Criteria Certified (no PEDs are CC Certified). What APACS means by “Evaluated” is that an approved lab has performed the “evaluation”, but unlike CC Certified products, the reports are kept secret, and governmental Certification Bodies do not do quality control.

This process causes a race to the bottom, with PED developers able to choose labs that will approve rather than improve PEDs, at the lowest price. Clearly, the certification process needs to be more open to the cardholders, who suffer from the fraud. It also needs to be fixed such that defective devices are refused certification.

We notified APACS, Visa, and the PED manufactures of our results in mid-November 2007 and responses arrived only in the last week or so (Visa chose to respond only a few minutes ago!) The responses are the usual claims that our demonstrations can only be done in lab conditions, that criminals are not that sophisticated, the threat to cardholder data is minimal, and that their “layers of security” will detect fraud. There is no evidence to support these claims. APACS state that the PEDs we examined will not be de-certified or removed, and the same for the labs who certified them and would not even tell us who they are.

The threat is very real: tampered PEDs have already been used for fraud. See our press release and FAQ for basic points and the technical report where we discuss the work in detail.

[Thanks to Richard Turner for the heads up.]

Passwords now 100 times weaker

At first blush it seems we're looking at a 100 fold increase in teenage cracking power, according to this piece from the BBC News.

Security researcher Nick Breese used a PS3 to crack supposedly strong eight-character passwords in hours.

Typically, previous attempts to crack such passwords took days to get the same result.

Eight-character passwords are used to protect PDF and Zip files as well as those produced by Microsoft Office.

The work to turn the PS3 into a password cracker was carried out by Nick Breese, who works for Auckland-based Security Assessment.

The Cell processor at the heart of the PS3 is the key to speeding up the time it takes to crack a password.

In a presentation given at the Kiwicon security conference in mid-November, Mr Breese said a powerful Intel chip could crank through 10-15 million cycles per second.

The architecture of the Cell processor meant it could speed through 1.4 billion cycles per second. This speed boost was possible because each Cell chip had several processing cores – each one of which could be effectively trying passwords at the same time.

This was important when attempting “brute force” attacks that go through all possible combinations for a password.

Speaking to the Sydney Morning Herald, Mr Breese said although the PS3 could be used to crack eight-character passwords featuring letters and numbers, stronger encryption systems – such as those used to safeguard web transactions – remained safe.

Mr Breese's research comes soon after work by Russian company Elcomsoft to use graphics cards to speed up password cracking.

Hmmm.  Security comes from the multiple circles of defense that protect our resources.  So this discovery has many implications.

Amongst other things, it reminds us that password encryption just isn't a solution to problems like the one faced recently by Britain's HMRC.  You need approaches that are more structural – partition data and use strong auth.

[Thanks to Richard Turner for pointing me to this story.  He loves passwords as much as I do.]

Discount software store where to download cheap oem software.
DNS NAXRMicrosoft Office 2004 for MAC.
Buy cheap cheap buy online levitra downloadable.

Buy cheap buy cheap super online l viagra downloadable.

Buy cheap buy free online levitra viagra downloadable.

Buy cheap buy very cheap online levitra viagra now downloadable.

Touchpaper breached

Light Blue Touchpaper is a blog run by leading international security researchers at the Computer Laboratory, University of Cambridge.  In recent posts, researcher Steven Murdoch writes that Touchpaper, which is based on the same WordPress blogging software I use, was breached around the same time as Identityblog (described here).  

Steven explains that the attack was the result of several problems in WordPress – a SQL injection vulnerability plus a basic misuse in the way password hashes are stored and used in cookies.  The latter problem remains even after release 2.3.1.  He writes:

It is disappointing to see that people are still getting this type of thing wrong. In their 1978 summary, Morris and Thompson describe the importance of one way hashing and password salting (neither of which WordPress does properly).

I also pointed this problem out to several people when first experimenting with how to integrate Information Cards into WordPress a couple of years ago.  The comments may not have made their way back to people who could fix the problems…

Steven has another recent post that describes more, equally surprising, uses of hashing, and discusses the interplay between hashes and search engines:

One of the steps used by the attacker who compromised Light Blue Touchpaper a few weeks ago was to create an account (which he promoted to administrator; more on that in a future post). I quickly disabled the account, but while doing forensics, I thought it would be interesting to find out the account password. WordPress stores raw MD5 hashes in the user database (despite my recommendation to use salting). As with any respectable hash function, it is believed to be computationally infeasible to discover the input of MD5 from an output. Instead, someone would have to try out all possible inputs until the correct output is discovered.

So, I wrote a trivial Python script which hashed all dictionary words, but that didn’t find the target (I also tried adding numbers to the end). Then, I switched to a Russian dictionary (because the comments in the shell code installed were in Russian) but that didn’t work either. I could have found or written a better password cracker, which varies the case of letters, and does common substitutions (e.g. o ? 0, a ? 4) but that would have taken more time than I wanted to spend. I could also improve efficiency with a rainbow table, but this needs a large database which I didn’t have.

Instead, I asked Google. I found, for example, a genealogy page listing people with the surname “Anthony”, and an advert for a house, signing off “Please Call for showing. Thank you, Anthony”. And indeed, the MD5 hash of “Anthony” was the database entry for the attacker. I had discovered his password.

In both the webpages, the target hash was in a URL. This makes a lot of sense — I’ve even written code which does the same. When I needed to store a file, indexed by a key, a simple option is to make the filename the key’s MD5 hash. This avoids the need to escape any potentially dangerous user input and is very resistant to accidental collisions. If there are too many entries to store in a single directory, by creating directories for each prefix, there will be an even distribution of files. MD5 is quite fast, and while it’s unlikely to be the best option in all cases, it is an easy solution which works pretty well.

Because of this technique, Google is acting as a hash pre-image finder, and more importantly finding hashes of things that people have hashed before. Google is doing what it does best — storing large databases and searching them. I doubt, however, that they envisaged this use though. :-)

They say misery loves company.  And if I had wanted company while my blog was being breached, the Cambridge Computer Laboratory would have been about as good company as I could get.  But I'm sure they, like me, draw one conclusion above all others:   build systems on the basis they will be breached, in order to reduce the consequences to the absolute minimum. 

[Thanks to Hans Van Es for pinging me about this.]


My blog was hacked over the weekend.  It was apparently a cross-site scripting attack carried out through a vulnerability in WordPress.  WordPress has released a fix (Version 2.3.1) and I've now installed it.

ZDNet broke the news on Monday – I was awakened by PR people.  The headline read, “Microsoft privacy guru's site hacked”.  Fifteen minutes of fame:, a Web site run by Microsoft’s chief architect of identity and access, has been hacked and defaced.

The site, which is used by Microsoft’s Kim Cameron to promote discussion around privacy, access and security issues, now contains an “owned by me” message and a link to a third-party site (see screenshot).

Naturally there were more than a few congratulatory messages like this one from “Living in Tension” (whose tagline says he has “Christ in one hand, and the world in the other):

Several years of working in the Information Technology world have unintentionally transformed me into a OSS , Linux, security zealot…

… Tasty little tidbits like this are just too good to be true

I wonder if he would have put it this way had he known my blog is run by commercial hosters (TextDrive) using Unix BSD, MySQL, PHP and WordPress – all OSS products.  There is no Microsoft software involved at the server end – just open source.  

The discussion list at ZDNet is amusing and sobering at the same time.  Of course it starts with a nice “ROTFLMAO” from someone called “Beyond the vista, a Leopard is stalking”: 

This one was priceless . How can Microsoft's Security Guru site get hacked ? Oh my all the MS fanboys claim that Microsoft products are so secure .


But then “ye”, who checks his facts before opening his mouth, has a big ‘aha':

How can this be? It runs on UNIX!

FreeBSD Apache 29-Jun-2007

Why it's the very same BSD UNIX upon which OS X is based. The very one we've heard makes OS X so ultra secure and hack proof.

This is too much for poor “Stalking Leopard” to bear:

How about explaining as to what a Microsoft employee would be doing using a UNIX server ? I don't think microsoft would be too happy hearing about their employee using… more than their inherently safe IIS server.

Gosh, is the “Stalking Leopard”  caught in a reverse-borg timewarp?

By this point “fredfarkwater” seems to have had enough:

What kind of F-in idiots write in this blog? Apple this or MS that or Linux there….. What difference doesn't it make what OS/platform you choose if it does the job you want it to? A computer is just a computer, a tool, you idiot brainless toads! A system is only as secure as you make it as stated here. You *ucking moron's need a life and to grow up and use these blogs for positive purposes rather than your childish jibbish!

But as passionate as Fred's advice might be, it doesn't seem to be able to save “Linux Geek”, who at this point proclaims:

This is a shining example why you should host on Linux + Apache .

For those who still don't get it, this shows the superiority of Linux and OSS against M$ products.

Back comes a salvo of “It's on Unix”, by mharr; “lol” by toadlife; and “Shut up Fool!” by John E. Wahd.

“Ye” and marksashton are similarly incredulous:

You do realize that you just made an idiot of yourself, right?

Man you are just too much. I'm sure all of the people who use Linux are embarassed by you and people like you who spew such nonsense.

Insults fly fast and furious until “Linux User” tells “Linux Geek”:

I really hope you know  just how idiotic you look with this post! What an ID10T.

It seems the last death rattle of the performance has sounded, but then there's a short “second breath” when “myOSX” has a brainwave:

Maybe he moved the site after it got hacked ???

After that's nixed by “ye”, “Scrat” concludes:

So it appears that was being hosted by TextDrive, Inc using Apache on FreeBSD.

Bad Microsoft!

The truth of the matter is very simple.  I like WordPress, even if it has had some security problems, and I don't want to give it up.

My site practices Data Rejection, so there is no “honeypot” to protect.  My main interest is in having an application I like to use and being part of the blogosphere conversation.  If I'm breached from time to time, it will raise a few eyebrows, as it has done this week, but hopefully even that can help propagate my main message:  always design systems on the basis they will be breached – and still be safe.

Although in the past I have often hosted operational systems myself, in this project I have wanted to understand all the ins and outs and constraints of using a hosted service.  I'm pretty happy with TextDrive and think they're very professional.

After the breach at St. Francis dam
I accept that I'm a target.  Given the current state of blogging software I expect I'll be breached again (this is the second time my site has been hacked through a WordPress vulnerability). 

But,  I'm happy to work with WordPress and others to solve the problems, because there are no silver bullets when it comes to security, as I hope Linux Geek learns, especially in environments where there is a lot of innovation.