It's not a new issue. Well-known information security advocate Bruce Schneier argued back in 2009 that there's not much point in showing asterisks or bullets in place of a user's password — masking it — while they enter it, as anyone who's close enough to read over the user's shoulder can simply look at the keyboard.

It's a classic case of security negatively impacting usability, and Schneier argued at the time that it really isn't worth it, since the user is typically alone in their office, anyway.

That seems to be the justification for why the latest beta release of Fedora no longer masks passwords as you type.

When starting an installation of Fedora 19 Beta TC2, administrators are asked to set a root password, but the password isn't masked until the focus is taken away from the field. This gives the administrator the convenience of checking that they're typing the password in correctly, but it does raise concerns, considering it's the root password for the system.

The issue was filed on Red Hat's Bugzilla instance as a bug, but initially dismissed by Chris Lumens, one of the developers on the Anaconda installer for Fedora. He wrote that it was "working exactly as it is intended", and brings about other benefits, such as solving keyboard layout-related problems — an issue that is particularly taxing during an install stage.

The installation process also allows administrators to create an additional local user account, and also add that to the machine's list of administrators. But creating such an account has the same mask effects, and, strangely enough, includes a complexity "meter" that is missing when setting the root password.

Even stranger is that once administrators go through the installation process and actually get Fedora up and running, login passwords are masked when typed, anyway. The exception to this is changing a user password in the GNOME graphical user interface — but, even then, the default action is to mask the password unless the "Show password" option is checked.

And that is one of the ways that installation password masking — especially for the root password — should have been done. Other alternatives could include masking everything but the most recently typed character. Or by doing what Microsoft recently did in Windows 8: Including a button next to logins, which shows the unmasked password for as long as the user is clicking it.

This is another instance of when an assumption is made that the user wants convenience over security, when the proper thing to do is put in place a reasonable level of security and let the user downgrade as necessary. Users can always choose to reveal their password if they know that no one else is in the room, but if the lowest security options are implemented by default, it's too late. After all, the people responsible for designing security mechanisms don't know exactly the environment users are in, and can't always offer advice that will apply to everyone.

Does this mean that gurus like Schneier are mistaken, then?

I guess it's telling that Schneier himself later admitted that he probably was.

Is password masking necessary? Or should it be considered too inconvenient to enable by default? Have your say in the comments.

Although offline, it's easy enough to connect with someone's day-to-day personality, it doesn't offer any insight into who they are and how they act online. Let's face it, as much as Hollywood might lead us to believe that hackers gain their street cred from hacking via sophisticated 3D-modelled file systems, or that two people typing on one keyboard doubles a computer's hacking abilities, the more boring reality is that it's mostly done by typing commands into a terminal shell (and I don't mean "access security").

Just as image is everything for some people offline, so too is it online. It's why sites like Zone-H exist, showcasing what websites online attackers have defaced. And just like in the offline world, many will take credit for others' work, make up successful attacks, or twist simple attacks into what seem like more nobler causes.

Which is what may have happened with the Commonwealth Bank of Australia (CBA) recently. A hacking group going by the name LatinHackTeamReborn, presumably trading off the name of the former LatinHackTeam group, claimed to have breached CBA's UK site.

It posted the alleged email addresses, hashed passwords, and names of users on the site, stating that it made its attack by "rerouting after attacking the firewall", and that it was "striking back after what you did to us".

The only problem is, it's not CBA's data.

"We have done a thorough investigation, and we can confirm that no Commonwealth Bank systems have been hacked and no customer data has been compromised. The CBA customer information is safe and secure," a spokesperson for the bank told us.

It's clear from the leaked data that it's not banking information. CBA uses numerical codes for it online banking system, not email addresses, and the passwords, while hashed, were done using MD5 with no salt. If such a method of securing passwords was used on a live banking system, it would certainly raise eyebrows, but CBA denies that it belongs to it.

But the email addresses do appear to be valid, and, worryingly, of a UK and Australian nature.

It's not unheard of for a hacked organisation to lie to the media, and for the information to actually be from a lesser-known and not mission-critical system (we might as well throw "developed by a third party" in here as well). But, digging deeper, I'd be more inclined to trust CBA's word. That's not just because of the damage to its reputation should it be proved that it lied, but because it would really mean trusting a hacker group that only created its Twitter account a few hours prior to the attack, which for some reason decided to include the #stopglobalwarning (yes, warning) hashtag in its attack, and opted for the cryptic, Hollywood-esque method of "rerouting" after attacking a firewall.

Wherever this data came from, it didn't happen by picking different routes. It most likely resulted from improper access to a database, probably by using SQL injection.

And what has CBA got to do with whatever happened to LatinHackTeam anyway? Nothing, as far as I can tell. It's a bank — and hackers breaking into banks is a sure-fire way to improve your image and gain credibility.

Which is probably why the hacking group also claimed to have attacked the Bank of Israel. That would be a significant feat itself; only the email addresses, hashed passwords, and organisations named have nothing to do with the Bank of Israel. They are actually from leaks posted by others, on previously compromised websites; in this case, the Ontario Imported Wine-Spirit-Beer Association. It runs its site off WordPress, which, if not maintained to the current version, is an easy target for even the most novice attackers, thanks to the wealth of information freely available online.

Most of the time, impersonators are going to get away with it because there are few consequences for being named and shamed, and fewer who have the time or inclination to do it ("Bank not hacked" is not a headline, after all). Even when it does happen, this is the internet, where creating a new alter ego is as simple as a few clicks, and a teenager, or an industry veteran, can be born again as a political greenie against global warning, a freedom fighter, a North Korean official, or perhaps all of them at once.

It's true that on the internet, nobody knows if you're a dog, but also, most times nobody knows you're really a dog pretending to be some sort of bank-robbing hacker.

University student Dan Farrall discovered that his UK government's communication headquarters (GCHQ) careers site has been sending back passwords in complete plain text. For those of us outside of the UK, GCHQ is one of Britain's intelligence agencies, dealing primarily with signals intelligence and charged with "safeguarding Britain's electronic communications and digital space".

It works with the nation's security services and secret intelligence services MI5 and MI6, and is thought of as the counterpart to the US National Security Agency or Australia's Defence Signals Directorate.

As Farrall pointed out on his blog, apart from the harm to its reputation, the sort of information that would be held within these systems would be significant.

We double-checked Farrall's claim and confirmed that the passwords were in fact being sent in plain text, and while we were at it, we started an application for a malware reverse engineer.

Aside from the usual residential information, the applications required passport numbers, reasons for wanting to apply, the relevant skills for the position being applied to, education history, and qualifications.

I imagine that such information would be especially interesting to foreign nations that would like to narrow down and possibly turn tomorrow's government penetration testers, or tap those that work on discovering and patching vulnerabilities for the UK government.

Farrall claimed to have contacted GCHQ about the issue at the end of February, but received no response.

GCHQ responded to ZDNet's queries about the issue, stating that "the current applicant tracking system used by GCHQ is a legacy system" and that is already in the process of replacing it.

Although the main issue with plain text passwords lies with the entire username and password database being unprotected and accessible in the event of a breach, GCHQ appeared to believe that the problem was simply a matter of passwords being sent over email.

It told ZDNet that "only the very small percentage of applicants (who need their accounts reset) are sent a new password. This comes with clear instructions of how to protect their data."

From the email in the screenshot above, these clear instructions involve not writing down the password or giving it to anyone else.

Updated on 27 March, 2012 at 10.45am AEDST: Included response from GCHQ.

As discussed in an advisory (PDF) issued by the Internet Corporation for Assigned Names and Numbers' (ICANN) Security and Stability Advisory Committee (SSAC) on Friday, a common practice by certificate authorities (CAs) is to issue digital certificates, even when the organisation requesting them provides a non-fully qualified domain name.

These "internal name" certificates are meant to be used for domains on private networks, such as server1.company.corp, that were never intended to be public facing. While this affords companies a convenient way to securely reference servers within their network, the internal name of their domains can potentially collide with gTLDs that either already exist or are being applied for.

This theoretically affords an attacker the ability to apply for a site certificate for a gTLD before it is approved, then once the target gTLD passes approval, the attacker has a signed certificate that can be used to conduct man-in-the-middle attacks.

"If an attacker obtains a certificate before the new TLD is delegated, he/she could surreptitiously redirect a user from the original site to the attacker site, present his certificate, and the victim would get the Transport Layer Security/SSL (TLS/SSL) lock icon," the advisory read.

Testing the theory, a SSAC researcher applied for an internal name certificate for www.site, and although the CA asked the requester to confirm it was for internal use only, approved its issuance. Armed with a certificate, the researcher then set up www.site, and found that several modern browsers recognised the certificate as though it had been issued for the gTLD and not an internal server.

The problem is not confined to new domains, and is potentially already a problem. As part of its research, SSAC noted that as well as listing valid entries for its business, Australian clothing retailer Quiksilver's certificate lists internal names ending in .corp — a gTLD that has recently been applied for.

Looking through the Electronic Frontiers Foundation's SSL (Secure Sockets Layer) Observatory project data from 2010, there are at least 157 CAs that have issued internal name certificates. As internal name certificates are not always publicly visible (as they are for internal systems only), SSAC noted that "there is no way of knowing how many of those certificates exist unless certificate authorities voluntarily disclose them".

SSAC has been working with a number of affected parties, including the CA/Browser forum. The latter industry forum has requested that its member CAs stop issuing internal name certificates by November 1, 2015, and inform any further applicants that the practice of issuing certificates for internal systems has been deprecated. Members are also requested to revoke any unexpired and affected certificates on October 1, 2016.

While SSAC commended the CA/Browser forum for this initiative, it wrote in its advisory that this still represents a problem, as gTLDs will still be vulnerable over the next three years until October 1, 2016.

But should we really be surprised?

While Australia's banks being hit by Chinese hackers makes for a great headline, the reality is that there's nothing particularly different about this attack than ones that have occurred in the past.

According to Freedom of Information documents (PDF) released by the RBA in December last year, the attackers' point of entry was via an email. The email, which was sent in November 2011, contained a link to a malicious website that if clicked on would download malware to its victims' computers.

It was sent, undetected by the RBA's security systems, to "several bank staff, including senior management up to head of department", and was ultimately successful — six people clicked the link and infected their machines.

While that elicits all sorts of buzz phrases like "advanced persistent threat" and "highly targeted" to go along with state-sponsored hacking, it's actually not particularly difficult to put together some names and email addresses. A quick LinkedIn search shows a couple of heads of departments and some 352 results for RBA employees.

Grabbing email addresses? Easy. Usernames for the rba.gov.au domain are employees' last names, followed by the first letter of their first name.

RBA's security system was bypassed because its antivirus systems failed to flag it. That might sound sophisticated, but run a piece of malware through VirusTotal, and it quickly becomes apparent that many vendors either miss recently authored pieces of malware completely, or take a while before they are aware of the threat. And "customised" malware that's capable of evading detection sometimes doesn't have to be much more than a few changes to a toolkit.

There's additionally the argument that's been floating around the security industry for the past few years that protection using signatures and heuristics alone is a fallacy, and instead network forensics are more important.

Of course, toolkit-based malware doesn't necessarily have the level of sophistication to take over a computer and dig for information like one that uses a zero-day can, but the RBA's malware wasn't up to that level of sophistication.

The incident summary includes a line downplaying the issue, stating, "of note, all of the affected PCs did not have local administrator rights. This prevented the virus from spreading".

And before we jump all over those six employees, what were their backgrounds? We don't know whether they were technologically savvy people, or just those who, like a huge proportion of Australians, need to use a computer to do their job. We might never know.

But we do know that even the most tech-savvy people fall for phishing schemes from time to time. Take a Facebook developer — someone who you would reasonably expect to know about protecting intellectual property, especially when they have access to live systems.

Facebook's own "Loopback" project, designed to test its own security, saw a developer fall victim to a spear-phishing email. His infected machine thereafter altered the code he was working on, publishing a (disabled by Loopback's coordinators) backdoor on Facebook's live servers.

This sort of thing likely happens all the time. The fact that it happened to six employees at RBA isn't anything out of the ordinary.

The RBA seems to agree, judging by the response it took.

It essentially suggested deploying updated virus signatures, looking for links in emails and possibly blocking the download of certain files from the internet via web browsing. It did not consider any changes to its risk register, and the team doing the security analysis didn't think it needed to, either.

While that covers the technology side of the issue, what about the human side? The RBA wrote that "while users are aware of the need for caution with suspicious attachments, such awareness is unlikely to protect the bank from credible-looking emails and attachments".

Its own documentation lists the "severity of actual impact" as minor, and although it states that "bank assets could have been potentially compromised, leading to service disruption, information loss, and reputation", it does not, in the RBA's incident report summary, list it as having financial, legal and compliance, or reputational impacts.

It did contact the Defence Signals Directorate (DSD), which might cause some to think that this is a national security dilemma. But the reality is, doing so is just good practice. The DSD's Information Security Manual states that agencies are recommended to coordinate their reporting of cybersecurity incidents to DSD.

This is not only to help gain appropriate assistance, if it is needed, but also to help the government maintain a better perspective on attacks conducted against it.

Does this mean we're not in some form of "cyber" war with scary foreign nations?

Not at all. China's probably hacking us, just as we and the US are hacking them, and anyone else that falls under our radar. We just shouldn't be surprised that it happens.

Subsequent to this article being written, the RBA issued the following statement:

As reported in today's media, the bank has on occasion been the target of cyberattacks. The bank has comprehensive security arrangements in place which have isolated these attacks and ensured that viruses have not been spread across the Bank's network or systems. At no point have these attacks caused the bank's data or information to be lost or its systems to be corrupted. The bank's IT systems operate safely, securely, and with a high degree of resilience.

The bank takes cybersecurity and its potential consequences extremely seriously. As part of its extensive efforts to ensure that security arrangements are best practice, the bank routinely consults with the Defence Signals Directorate and draws on the expertise of specialist private firms. There is ongoing rigorous testing of the bank's IT systems and regular training of staff.

However, as Alex North has recently discovered, when it's your own government's taxation office and it somehow believes that it's following best practice, a seething ball of rage slowly worked its way up from my spleen.

The Australian Taxation Office (ATO) has been storing passwords in plain text. I don't need to tell you why that's a bad idea. We've already seen how disastrous it can be when companies only store unsalted hashes of passwords — the Australian Broadcasting Corporation (ABC) joined LinkedIn on that honour roll recently.

North found out by requesting his password from the ATO's Publications Ordering Service, shortened, perhaps appropriately, to POS. This is where I'd normally shake my head, but walk on by. There are hundreds, if not thousands of companies that have little clue as to how bad this practice can be, so much to the point that a name-and-shame site called Plain Text Offenders exists.

But the remarkable thing about North's finding is that he went one step farther, made a complaint, and received a reply from the ATO's "technical area".

The ATO's response was that the process it follows is one of the most commonly adopted methods of password recovery, and is safe because the recovered password is only sent to the user's registered email address.

I sure hope not. There are plenty of sites that do the wrong thing, but the majority of responsible sites I've seen tend to do the right thing and require a time-sensitive confirmation link. It's not perfect, considering that email is typically not a secure medium, but done right, the confirmation link expires when used or after a period of time, unlike the password.

Although North didn't go digging any further, I figured I would — and I found that the problems get even worse, although the ATO's "technical area" has some idea of basic security concepts.

Take poor password generation, for example: It has a script that will check if your password is one in a blacklist of common passwords. However, that entire dictionary is checked client side in a script, and is hardly comprehensive. In fact, some of the other password complexity requirements mean that a lot of the words in the blacklist don't even qualify.

My dodgy password of "Password1", for instance, made the cut.

But given that all of this checking happens on the user/attacker's own computer, there's nothing to stop them from hijacking the JavaScript and skipping the checks.

That's not the only place that client-side verification occurs.

Attempt to log in with the wrong credentials enough times, and another JavaScript function will kick in, disabling the login form for 3 seconds. Someone at least knows that attackers can and do brute force systems, but hasn't figured out that it doesn't happen by entering usernames and passwords manually.

This happens on the two other sites set up for businesses and tax agents, although the tax agent site redirects users to a page telling them that they'd been locked out of the site for 24 hours. That would be a crude but effective measure, only it doesn't actually lock anyone out.

In fact, the tax agent site doesn't even prompt for a password, only a tax agent number (TAN). And with a number of them freely Google-able, one could probably log in under someone else's account, passwords be damned.

But, as North pointed out sarcastically, big deal. POS is a government service, so anyone can order free documents. In fact, anyone can sign up, order a bunch of documents and have them sent to various addresses if they really wanted to. The whole system is flawed, not just the password requirement.

We put our own query to the ATO, and it confirmed that its POS site stores passwords in plain text, but it also highlighted that the system is an external application hosted and managed by its "publication warehouse supplier". That means, at least, that it's separate to more sensitive information, as it is "unable to access taxpayer information or their details" and "there are no financial or bank account details stored on POS".

It also acknowledged that as "with any online ordering system, if a person was so inclined, they could place orders to another address. In addition to our ongoing consideration of security developments, we monitor requests to identify out of the ordinary activity, which may include repeat or 'over the limit' requests".

The difference between "any online ordering system" and POS, however, is that most people have to pay for the product. There is (thankfully) no payment mechanism in place for POS, as the ATO funds the printing and delivery of the products. But who funds the ATO? Taxpayers, ultimately.

As for entering TANs, the government is able to help attackers out there, too. Unlike Tax File Numbers (TFNs), which taxpayers are not meant to share, TANs are publicly available information that can be looked up on the Tax Practitioner's Board.

The ATO told us that with this information, an attacker would be able to "view the requester's contact details and past and current orders of ATO material", which admittedly isn't ground-breaking information to have, but it leaves me wondering what the point of a login system was in the first place.

Nevertheless, the ATO told us, "security is important to us; while we feel this represents a low risk overall and operates completely separate to ATO systems, we are working with our supplier to address best-practice security measures, including improvements that can be made to this system for the future."

Hopefully, this will be sooner rather than later. But judging from the ATO's response, it may not be in a rush. After all, it told us that "POS has not been compromised once in it[s] years of operation".

The point is not about not being breached; it's about what you do when you have been. In the ATO's case, it will lose all of its passwords, many of which are probably being used on other sites. The only thing it will be able to do for its users is send an apologetic email, shoving the responsibility to them to clean up the mess.

If you look at Evernote, which I am using as an example because it suffered a breach over the weekend, it has done (most of) the right things. Passwords were hashed and salted, which means that unlike just hashing, which simply obfuscates poor passwords, they are close to impossible to get the plain text from. Upon learning of a breach, it instituted a password reset on its users, just in case.

While it arguably could have done a better job at informing its users that it had actually reset their passwords, it checked all the right boxes when it came to ensuring that passwords are being responsibly stored.

The best part about it? Most don't even pay Evernote for this.

Mega's security operates in a different way to a lot of other sites. Its use of public/private pair keys is a good step for ensuring that no one but the owner of the private key pair has the ability to decrypt files that are stored in its cloud service, but it appears to also be tied into the password used to set up the account.

Mega's site states that it is "the master encryption key to all of your data" and that "if you lose it, you lose access to all of your files that are not in a shared folder and that you have no previously exported file or folder key for." However, tying the password deeply into the encryption scheme also means that it is impossible to reset or change a user's password without throwing away the encryption keys. Combined with the current inability for users to close their account and create a new one, and users are stuck with whatever password they signed up with. Hopefully, that wasn't "password," while they figured out whether they wanted to keep using the service.

And hopefully they didn't typo it, either, because Mega doesn't ask users to type their password again to confirm during the sign-up process.

Read this

Cloud security: How to make the switch

• Read more

But, more importantly, this approach to security highlights something that is more important than the strength of keys and passwords: the ability to revoke and issue new ones.

Previous security incidents have left organisations urging their users to reset their passwords, even when the targeted organisation was not affected. An example of this is the recent case of a New Zealand bank that claimed its site was being cloned for another payment processor's site. The incident did not involve the bank's own infrastructure — its systems were never breached — but the only advice it could really give its customers was for them to change their passwords. In Mega's case, this would be impossible.

In the event of a phishing campaign or malware that specifically targets the farming of users' Mega passwords, users don't have any options available to them to improve their security. Mega isn't responsible for the security of its users' PCs, or their behaviour on any unsavoury websites.

And if an account is compromised, what then? Attackers could have a laugh, uploading pornography randomly into users' documents; be downright malicious and delete all of their files in an instant; or, possibly worse, download them all to snoop through.

A vigilant user might discover that their account is being accessed from another browser at another IP address, but there are no options to disconnect the user and ban that address. Even if there were, the attacker could just use a proxy to change their IP address, log in with the same password again, and even employ the same futile lockout method on the original owner. Against a less tech-savvy user, perhaps it might even work.

So, sadly, the only thing that the account holder can do is delete their own files before their adversary can download them — a humiliating defeat, but the only way that they can protect their files, because, once hacked, they're hacked forever. Which leads me to question the point of having individual accounts in the first place. With this amount of security, the only files worth putting up are those that are only temporary or are going to be shared publicly anyway, both of which can be achieved through anonymous accounts.

But if we give Mega the giant assumption that all of its users will use long, unique passwords, and won't fall victim to phishing schemes or keyloggers and the like, their own systems should be fairly secure, right?

Not quite.

Read this

M2M and the Internet of Things: How secure is it?

• Read more

Users have already found cross-site scripting vulnerabilities on the site, which could be used, for example, to send off session cookies to an attacker so that they can log in as they please. Someone with a more malicious imagination can come up with better, but I can easily see the potential for a social engineer to create a form that requires the user to log in again before they can upload or download files. From here, they could gather Mega log-in details or even request that the user "link" accounts with other services, such as Facebook, or PayPal, if they're daring enough.

Unless things change in the future, and passwords are not tied so intimately to the encryption keys forming the basis for Mega's security, the alternatives will, at best, be a workaround. If Mega eventually allows accounts to be erased and closed, the paranoid (or those who are serious about security — it's a tough call to make a distinction) may opt to completely remove all of their content and sign up again just to change their password. With free accounts providing up to 50GB of cloud storage, many won't have the time and bandwidth to go through the hassle.

There will no doubt be various uses for Mega, such as uploading content that is meant to be publicly accessible and shared, but, if you were thinking about using it as a nice way to provide even more redundant storage for your documents and family photos, I'd steer clear for a while yet.

It's hard to say when Mega might become secure enough for more personal content, but it doesn't look like it will be soon; there are a number of enhancements coming up for the cloud storage site, but security barely rates a mention on the list of "essentials."

If that sort of advice has your hackles up, then take a step back and consider for a moment that, in a way, it's what so many of us have been saying for years.

There's a lot of advice out there on the recent zero-day exploit, which was found in Java 7 Update 10 last week. Oracle thinks that it has solved the problem and that it's okay to run browser plug-ins again; some say that not everything has been patched; others appear to no longer trust Oracle and warn against enabling the browser plug-in, even once updated; and the most extreme call is for Java to be uninstalled completely. Whatever the advice, it seems that everyone says you should do something right now.

While most suggestions are well intended — people are generally offering advice for your own protection — they don't always speak to each individuals' circumstances.

Since the news broke, I've fielded messages from readers who have been unaware of the issue and not known what to do. I've even seen a question about whether it matters because they're in a certain country. In all cases, however, my recommendation is that users should carefully consider their own circumstances and act accordingly.

Read this

How to disable Java in your browser on Windows, Mac

Amid a serious security flaw in the latest version of Java 7, where even the U.S. Department of Homeland Security has warned users to disable the plug-in, here's how you do it.

• Read more

Personally, as much as I think that Oracle will continue to fight a losing battle against hackers hell-bent on finding exploits in Java (and that's probably more to the credit of the hackers), I won't be uninstalling it, but I will disable it in my browser and re-enable it on a case-by-case basis. Java is a piece of software that I require from time to time, and despite being aware of the risks, they're manageable or acceptable.

Part of the managing the risk means keeping tabs on any future security issues that might pop up out of the blue, being more than careful with how I browse the web, accepting and considering what might be compromised in an attack, and realising that posting a blog about how I'm approaching the issue could further increase that risk.

It is not the safest route, and it goes slightly against the Department of Homeland Security's advice to disable the plug-in "unless it is absolutely necessary", but the US government (as far as I know) doesn't know me, isn't keeping tabs on me, and doesn't know my exact environment, browsing habits, and mitigating actions. I don't consider myself to be any "better" than anyone else, but the US government's advice doesn't strictly apply to me because I simply have a different set of circumstances.

Likewise, it's impossible for me to recommend that anyone follow my own example, as each and every person has their own unique circumstances where keeping or not keeping Java in some form or another will be best for them. To tell people that they should do one thing or another would be like forcing Vegemite on everyone else, just because that happened to be what I had put on my toast and didn't result in me dying (yet).

The bottom line is, no one can tell you how you should or shouldn't secure yourself, because no one knows your environment the way you do. There are vulnerabilities in every operating system known to man, but no one tells you not to run one — that would be impossible.

In that same vein of thought, we can't prescribe security to people without knowing what they do, how they manage the risks, or if they are prepared to accept them. Otherwise, we might as well go the full hog and tell them that not using a computer is the safest option. And that's just offensive.

Both groups share the same business model: independent hackers can submit vulnerabilities and sell them in return for credit on the site or money.

In a post on Facebook, ExploitHub confirmed that they had been attacked after accidentally leaving an install script on their server, which allowed Inj3ct0r Team to reinstall its Magento eCommerce software. This allowed the attackers to gain control of its back-end systems and interrogate the site's database.

However, ExploitHub claims that this database "only contains information used by the web application itself, as well as product information, such as exploit name, price, and author, but does not contain any actual product data, such as exploit code."

It currently insists that, although leaving the install script was an oversight on its part, its actual product data is stored elsewhere, and that, so far, it has not seen any unauthorised access or any of its exploit code compromised or stolen.

So was it hacked, or wasn't it?

It's a bit of both, really.

Inj3ct0r Team did manage to get away with information in the database containing a list of exploits and how much they cost, but it's simply that: a list. It's promising to release the actual exploits if it gets 30,000 likes on its Facebook page by December 16.

Its current like count sits at about 15,500, so I'm guessing that this is simply a means to rack up a lot of likes and then use it as a convenient excuse to not release the so-called exploits it stole.

In the meantime, ExploitHub is having its own issues. Its website is currently down, and while it hasn't provided a reason why, I wouldn't be surprised if another group stepped up and claimed responsibility.

Perhaps most concerning is that both groups are aiming to profit from hiding exploits from the public eye. You can't blame hackers for wanting to get paid for their efforts, but at the same time, the act of hiding security exploits makes the internet more dangerous as a whole.

As much as I hate to admit it, in order to get exploits into the public eye, these sorts of attacks are a necessary evil, and ones that lawful entities can't be seen doing. Here's a role for Anonymous to play — hackers hacking hackers — but that all depends on if someone can actually do it right.

The flaw exploits the ability for attackers to specify what phone number an SMS originated from, along with the lack of checks in place on Facebook, Twitter and Venmo's sides to verify that the information is authentic.

An attacker exploiting these quirks could fraudulently make status updates or mobile payments where these features have been made available via SMS.

Rudenberg documented the response of all three companies on his blog, and of them, Venmo was the quickest to respond to the issue. Being a relatively small company, Rudenberg had problems with finding the right contact to speak to regarding the vulnerability. Once he contacted Braintree, which purchased Venmo only recently, its security team shut down its feature for mobile payments via SMS just two days later.

It's worth noting at this point that Venmo doesn't have an extensive security team. It does have a dedicated risk and fraud manager, Eran Kimchi, but he is not part of the software team, and, judging by his background at Google and PayPal, he appears to be more of an analyst type.

Facebook and Twitter, which are known for having dedicated security teams, were not so fast to respond, despite Rudenberg using his influence to force both companies to give the issue greater attention. Rudenberg initially notified Facebook of the issue on August 19. Failing to get a response, he had a friend on the inside bump the issue internally, and received notification that the issue had been resolved on November 28 — 101 days later.

Twitter, on the other hand, took 107 days, after Rudenberg notified it on August 19.

"The issue I filed was initially inspected by a member of their security team, but was then routed to the normal support team, who did not believe that SMS spoofing was possible. I then reached out directly to someone on the security team, who said that it was an 'old issue,' but that they did not want me to publish until they got 'a fix in place.' I received no further communication from Twitter," Rudenberg wrote on his blog.

Rudenberg requested an update on the issue on October 15, and, upon receiving no response, notified Twitter on November 28 that he would be disclosing the issue publicly. Upon writing up the vulnerability and posting it on his blog yesterday, Twitter has since come back today and confirmed that the issue has been resolved.

For his efforts, Rudenberg will receive a minimum bug bounty of US$500 from Facebook. Neither Twitter nor Venmo have a similar bounty scheme. At the time of writing, Rudenberg is not listed by Twitter on its list of White Hats that it would like to thank for improving its security, a courtesy that I believe Rudenberg is more than worthy of.

Venmo's response was warranted, given that its customers' money was at risk, but that speaks volumes about how Facebook — and Twitter, to a lesser extent — view the reputation and personal information of its users. I would argue that personal information is more valuable than money, given that money can always be replaced; there are forms of insurance for that. A trashed reputation or leaked personal information, however, is forever.

Given that the issue wouldn't have affected the majority of its user base, why weren't posts via SMS simply disabled while a fix was sought? Coding the fix would be a complex issue, but understanding that it presents a risk should not take that long. After all, a small startup that six months ago barely had 25 employees could figure out the issue in a few days.

The truth is, Twitter and Facebook probably didn't see the issue as significant enough to warrant the inconvenience to users. And what this means is that even if they say privacy and security are supposed to be their most important issues, they have lost priority to convenience yet again.

There's a story about how most elusive discoveries are made; rather than the hyped-up eureka moment that many believe occurs, many discoveries are made by someone tinkering with something, not looking for a development, and realising that something is strange. In the same way, many security flaws aren't found by a guy who is hell-bent on breaking into a business and ruining its life, and if they were, they wouldn't inform the organisation of exactly where their issues are.

Yet, when a good Samaritan does that, they're left feeling like they're going to go to jail. One example is New Zealand's recent case with the Ministry of Social Development. Freelance journalist and blogger Keith Ng pointed out glaring security oversights, but it's obvious that despite only sharing thid information with officials and the privacy commissioner, and giving his personal guarantee that he would not pass the information to anyone else, Ng was concerned about what action might be taken against him.

In the end, Ng decided to lawyer up, and while the ministry eventually said that it would not be pursuing any legal action, one needs to ask whether it was because his position as a journalist would have created a public relations nightmare.

Looking further back, Patrick Webster attempted to warn First State Super that it had issues with its system, an act that was praised as "the right thing" to have done at the time. But later, and without any notice, he subsequently had the local police on his door step. No good deed goes unpunished.

People like Webster, who are professional security consultants or penetration testers, have a knack for discovering these sort of flaws, even in their daily browsing activities (you can't, after all, just turn off the ability to spot bad practices outside of work hours). However, I am yet to meet a single professional who will go out of their way to inform a company if they're not already doing work for them. On the surface, it might look like they're passing on a free opportunity to get some business, but the reality is, getting involved in someone else's affairs like that starts to look like extortion.

From the vulnerable business' point of view, a skilled hacker has been sniffing around their systems and just "happened" to find a flaw. What's that? You also just happen to offer the same services to test for weaknesses and we should hire you? You happen to run a security blog too, where you write about flaws? Oh, and you also talk to the media sometimes. Right.

On the flip side, there are businesses that are switched on and have realised that enlisting curious hackers to point out their flaws is an extremely cost effective way of getting a sketchy penetration test; sometimes, at no cost. The problem is that it has to be done their way, and the rewards are often non-existent or simply not worth a hacker's while.

Most offer no monetary rewards whatsoever for the reporting of bugs, and also place further restrictions on those interested in testing for bugs, asking reporters to stay silent on the issue until it is resolved.

Despite the catch-all statement that customer security and privacy is of utmost importance, many organisations take staggeringly long times to reproduce even simple errors that, in many cases, security folk already know how to fix and often even send suggested code for. This means that reporters have to hide their achievements away for weeks, and sometimes, with little acknowledgement from the vulnerable organisation.

At the end of the process, the only thing they have to show for their months of effort is their name on the company's security page, if they even have one. To put this into perspective, even Twitter's translators receive more recognition for their efforts in the form of profile badges and achievements.

Facebook's approach is similar when it comes to asking for hackers to delay their disclosure, but under the threat of legal action:

If you give us a reasonable time to respond to your report before making any information public and make a good faith effort to avoid privacy violations, destruction of data and interruption or degradation of our service during your research, we will not bring any lawsuit against you or ask law enforcement to investigate you.

To me, that doesn't read as a reassurance that Facebook won't sue you if you're well-intended. It reads as, "If you don't play by these specific rules, you better lawyer up, because we're coming back for everything".

It at least goes another step by offering bounties, but only says that its minimum reward is US$500. Furthermore, it excludes denial of service vulnerabilities and spam or social engineering techniques from its program. If there is any better use for Facebook by criminals, it's socially engineering users to launch targeted attacks. And what script kiddie wouldn't want to DoS Facebook for the attention? Professional penetration testers can attest that just because they're not required to test a particular system or attack vector, doesn't mean that others won't.

And I can't talk about bounties without at least mentioning Google and its program, which arguably pays among the best rates to hackers. That's great for whitehats, but it simply can't compete against underground markets or even the US Government.

At the end of the day, the ethical hacker is left with this scene: they could report the vulnerability to the company and open themselves up to legal action, little to no reward for their efforts, possible claims of extortion, reputation loss, and embargoes on their own discoveries, all for a warm fuzzy feeling; or they could keep it to themselves and move along.

The problem is, the less scrupulous hackers out there that are selling vulnerabilities and are at the root of the problem for vulnerable businesses; they're banking on the ethical hacker to keep their mouth shut. And in their effort to shoot whatever they happen to catch a glimpse of, friend or foe, businesses are only helping these bigger threats remain undetected.

So am I more secure now that I use a Mac without antivirus software than in my former life under a Windows machine with it?

The debate over Mac security compared with Windows is a long-running one. Apple considers Mac OS X so safe that late last year it removed a page on its site which Washington Post security blogger Brian Krebs had found.

Apple encouraged the "widespread use of multiple antivirus utilities" back then. Click it today, and you get the message as seen in the image below.

(Screenshot by Liam Tung/ZDNet.com.au)

Apple's reason for taking down the old message?

"It was old and inaccurate," Apple told Krebs. "The Mac is designed with built-in technologies that provide protection against malicious software and security threats right out of the box." It did concede that OS X wasn't bulletproof; antivirus (AV) "may offer additional protection," it said.

But how is that different to Windows Vista?

Since removing the article, Apple hasn't published a position on the issue, but Mac users on its support forum have closed the case on the matter: AV is unnecessary.

It's not surprising Apple would focus on its built-in technologies, especially when security researchers have begun paying more attention to them. Apple's growing user-base is still seen as a likely trigger for malware writers to start devising nasty payloads. Dino A. Dai Zovi, a buddy of Charlie Miller — the "prize" hacker who recently pwned a MacBook in 10 seconds — recently released his research on the subject.

Zovi's assessment was that while threats and the likelihood of attack are currently low for OS X, vulnerability is high. The chink in Leopard's armour is how it handles memory corruptions, such as a buffer overrun — a flaw that can be triggered by an attacker, which causes data to be stored beyond the boundaries of a "buffer". When that extra data is overwritten to a nearby memory location the process could crash, or allow malicious code to run.

One solution to this problem is known as address space layout randomisation (ASLR), which, according to Wikipedia, involves randomly re-arranging the positions of key data areas.

Microsoft took the lead, at least on ASLR, from the OS X cousin OpenBSD in this respect, announcing its use in the beta version of Vista in 2006.

Since then IBM security researcher Mark Dowd has tested Microsoft's implementation of defences against this type of attack in Windows Vista, looking at how Adobe Flash bugs could be used to beat them.

So am I more secure now that I use a Mac without antivirus software than in my former life under a Windows machine with it?

These defences don't stop, but reduce the likelihood of an exploit working. Dowd's work attempted to increase the likelihood of them working.

Today, OS X has fallen behind on several fronts, compared to Linux and Vista, says Zovi, whose research paper can be found here. His conclusion: "Mac OS X is significantly lacking in memory corruption defence features compared to other current operating systems like Windows Vista and Linux: ASLR, Non-eXecutable memory, stack and heap memory protections."

His proof? The CanSecWest hacking competition. Charlie Miller pointed out last week to Zero Day's Ryan Narraine about his latest exploit: "With my Safari exploit, I put the code into a process and I know exactly where it's going to be. There's no randomisation. I know when I jump there, the code is there and I can execute it there. On Windows, the code might show up but I don't know where it is. Even if I get to the code, it's not executable. Those are two hurdles that Macs don't have."

It's interesting to see Microsoft has leapfrogged Apple on some very important counts (probably out of necessity), and that OS X could be hacked so quickly. But does any of this really matter to the user? Well, I think I'll just relish in my AV-less state for now, and enjoy the fact there aren't an army of Charlie Millers across the globe each with a $10,000 incentive to find more holes and devise payloads.

Facebook's decision to pull the groups on Wednesday couldn't have been more perfectly timed: as its CEO Mark Zuckerberg attempted to convince his users that they really do own the content they publish on Facebook, locally it was commandeering "user's content" because Facebook decided those groups had breached its terms of use.

In other words, Facebook's lawyers thought it was not subject to the court order; it was just following its own rules.

The decision to take down the groups came after the Victorian Police told the media that it feared the Facebook groups could threaten the Department of Public Prosecution's case against Sokaluk.

Facebook responded quickly, but told media it did so because the groups had breached its terms of use. "We will remove groups reported to us that are found to express hatred or threaten violence towards people," spokespeople said.

In other words, Facebook's lawyers thought it was not subject to the court order; it was just following its own rules. At least that's how criminal lawyer David Galbally QC, who was interviewed on Sunrise yesterday, interpreted Facebook's comments.

"Facebook say they're not responsible. But that's wrong and nonsense. They're displaying it in a jurisdiction that breaches an order," Galbally said.

"We need to have a law that makes the website provider responsible for what it is that's being displayed on the internet, particularly in circumstances that breaches or tends to breach a court order," he added.

But if that's what should happen, it's certainly not what has happened in the past.

A lawyer friend of mine reckoned there are three analogous scenarios: eBay being used to sell counterfeit software; the court order preventing Channel 9 from airing the first series of Underbelly in Victoria being undermined by YouTube; and the case being brought by the Australian Federation Against Copyright Theft (AFACT) against ISP iiNet.

eBay typically handles the issue of counterfeit sales in its terms and conditions, my friend said. A good example is Microsoft's recent legal action, which was directed at the sellers and not eBay.

The Underbelly court order is much closer to the issue of whether Facebook is responsible. Although no individuals were charged with contempt of court, David Vaile, University of NSW Cyberspace Law and Policy Centre executive director told News.com.au at the time those who uploaded the series could face copyright and contempt of court charges, rather than YouTube or BitTorrent.

The AFACT versus iiNET case is more tangential than the first two, but that shows some of the difficulties in holding a service provider responsible for its users' actions.

Galbally is the only person I've heard say that Facebook should be responsible for obeying the court order. If he's right, we might see Facebook place an advertisement on its network asking: "Wanna make $150 a day for sitting at your desk and reading? Click here to apply."

It is our opinion that the majority of security threats faced by Australian companies come from employee's who are dissatisfied or at risk of redundancy

ESD Australia's Les Goldsmith

Thanks to the financial and economic crisis, which McAfee's CEO Dave DeWalt at the World Economic Forum in Davos last week twisted into the "global meltdown in vital information", the security industry has found its new public enemy number one: not clumsy insiders who accidentally leak information, but fearful insiders who suspect they're about to become outsiders.

"The current economic crisis is poised to create a global meltdown in vital information. Increased pressures on firms to reduce spending and cut staffing have led to more porous defences and increased opportunity for crime," said DeWalt.

DeWalt based his comments on research that found US$4.6 billion worth of intellectual property was stolen last year across several countries. McAfee extrapolated it to US$1 trillion for the globe — a figure which will probably have to be trimmed in today's finance-constrained world.

But DeWalt's argument was compelling — superficially at least. Locally, people have been angered by how retrenchments have been conducted — coldly — and revenge of a similar ilk would surely be on the minds of some. Just take a look at the feedback on the story about Dimension Data's recent layoffs.

Les Goldsmith, a veteran of technical surveillance counter-measure services and MD of ESD Australia, contacted me with a similar argument to DeWalts'.

"It is our opinion that the majority of security threats faced by Australian companies come from employee's who are dissatisfied or at risk of redundancy," said Goldsmith.

The current economic climate meant that staff would be aware of the threat of being laid off, leaving a company's intellectual property at a greater risk of theft, he said.

To an extent I agree with Goldsmith, but how different would that be to a climate in which poaching staff was the norm? Say, like last year.

I also had a chat with Rob McAdam, managing director of penetration testing firm, Pure Hacking, a company that often does forensics after a data theft has occurred. He made two points. First, companies that let their staff know its systems are being monitored reduce the risk of a theft occurring. Staff weigh up the risks, he said.

The second is more telling though of the risk of IP theft, specifically. "All the jobs we've been called in for have been around credit card data," he said. "It's been more about how can I make a quick return and that takes a while on IP, but for credit card information it's fairly immediate."

So is your IP under threat? Probably, just like it was last year, but it's the day-to-day low-hanging, easily liquefied fruit that's still likely to be at the greatest risk.

As Microsoft Australia's strategic security advisor Stuart Strathdee said: "We pulled all the stops to get this patch out". The "out of band" patch released by Microsoft at 5am Sydney-time yesterday was an unusual event indeed, according to Strathdee. The company usually patches monthly.

We pulled all the stops to get this patch out

Microsoft's Stuart Strathdee

"Out of band updates are a fairly rare occurrence. We did have one earlier this year. Without access to exact numbers, I think we only do one or two a year," Strathdee told ZDNet.com.au.

In October this year, Microsoft was forced to release a patch for its Windows Server software outside the monthly Tuesday patch cycle. Microsoft considered a flaw in its Windows Server 2000, Windows XP, and Windows Server 2003 software critical enough to do what it did yesterday at 5am.

The patch released yesterday was rushed through within eight days of the zero day's discovery — a feat which Australia's Computer Emergency Response Team's (AusCERT) general manager Graham Ingram earlier this week said would be "Herculean"; even without the eight-day turn-around time that Microsoft has achieved.

"I would not like to be working for Microsoft at this point in time," he told ZDNet.com.au at the time.

According to Strathdee, it wasn't such a pleasant time. After Microsoft completed its risk assessment on the threat, he said, "We decided it was something that we had to go 24/7 on."

"From the development team's [perspective], even though [they] have the core code for IE, going through all those permutations of different combinations of service packs and operating systems obviously opens up the matrix of testing," he said. "It was a big task."

Meanwhile, AusCERT, which knew that it might cop flack — not just from Microsoft but large corporations that have locked-down computers — had cautiously advised organisations to "consider" using alternative browsers until a patch was released.

Strathdee said this advice was "drastic". "Particularly in this instance, the risk to Australian users has been so minimal, that recommending alternate browsers — that really is a very drastic recommendation," he said.

And Strathdee's following comment can't be denied by other browser makers, such as Google, Apple, Opera and Mozilla.

"The other side of that is that if you are going to switch to an alternate browser, you need to consider the vulnerabilities that those browsers have in terms of exposure," he said.

The code is as good as we can make it based on the urgency that we had here

Microsoft's Stuart Strathdee

All have experienced serious flaws of some nature over the past year and all are under attack. On the other hand, none besides Firefox — and only at a consumer level — are anywhere near as widely used as Internet Explorer. The question is, which browser is next in line? On the advice of some fairly reliable sources, the answer is likely Firefox.

But in Microsoft's defence, Strathdee said: "We're not trying to back away from the fact this was a serious issue. That's why we've pulled out all the stops."

Despite the rushed nature of the patch issued yesterday, Strathdee said it was "quality". "Even though we've rushed it, we've done a lot to ensure that it is a quality update and the code is as good as we can make it based on the urgency that we had here," he said.

Microsoft typically tests its patches against application environments of between 250 to 300 organisations besides itself, according to the executive.

Despite the panic and hype caused by this zero-day flaw, Strathdee said it wasn't time for organisations that only supported Internet Explorer to start supporting other browsers.

I had a funny discussion yesterday with AusCERT's general manager Graham Ingram.

He was being coy about the advice they'd given — "consider using another browser until a patch has been issued" — which, from a home user's perspective seemed pretty sensible but for a major corporation might be impractical or simply impossible.

Every version of IE is exposed, and as Stephan Chenette, manager of Websense's US research division told ZDNet.com.au last week when it thought only IE7 was affected, this flaw is "critical" because it can be exploited with virtually no user interaction — the victim need only navigate to a website that has been armed with the exploit code.

Highlighting just how critical this flaw is, Microsoft last night announced it would issue an "out of band" patch tomorrow — a rare event which, according to AusCERT's Ingram, would have been a "Herculean" feat even for Microsoft.

As I was editing this blog one last time before pushing it live, Microsoft Australia sent an email to ZDNet.com.au advising that the patch will be ready by 5am tomorrow, 18 December. In fact, it's so spooked by this it's hosting a special webcast tomorrow at 8am for Australian eastern states.

Although zero days like this don't happen every day, we can be fairly sure it is only a matter of when, not if, there will be another. So a quick fix would be to immediately switch to an alternative browser such as Firefox, Opera, Chrome or Safari. If you like IE come back to it when Microsoft has released a patch.

But it's a different game for high security organisations like government agencies, banks etc. which in many cases "lock down" computers, usually with some cocktail of Microsoft software and inevitably IE in the mix.

So I was thinking then, why not, for the locked down environment, support two browsers? Stupid idea? Maybe.

IBRS security analyst James Turner thought supporting two browsers was silly and costly. He suggested "organisations question whether everyone actually needs web access".

AusCERT's Ingram agreed that if concern over this flaw was great enough, organisations should simply kill browsing altogether. But can you imagine seven whole tubeless days?

So how important is the web for business? I would say it's pretty darn vital as the majority of workers legitimately access the web to help them do their jobs. Even classically non-work services like YouTube or Twitter have become useful tools in some industries.

So how are you dealing with this issue? Do you support more than one browser? Does everyone in your organisation need internet access? Will you be patching tomorrow?

Agent 86: "Sorry about that, Chief"
(Credit: Australian Labor Party)

As Kevin Rudd (Agent 86) delivered his first National Security Strategy speech about "cyber war" and the threat that KAOS posed to the nation's computer-dependent infrastructure, the $10.4 billion fiscal stimulus that was designed to lubricate the economy knocked out the biggest system that would deliver it — CommBank's NetBank.

Agent 86 would have pulled off his shoe, dialled Ralph Norris and said: "Sorry about that, Chief".

But no, our Agent 86 didn't say that. He was busy in Canberra saying this:

"It is increasingly evident that the sophistication of our modern community is a source of vulnerability in itself... We are highly dependent on computer and information technology to drive critical industries such as aviation; electricity and water supply; banking and finance; and telecommunications networks."

"This dependency on information technology makes us potentially vulnerable to cyber attacks that may disrupt the information that increasingly lubricates our economy and system of government. A number of actors may carry out such attacks ranging from hackers, to commercial entities and foreign states."

After conducting a root cause analysis of the situation, I found that our Agent 86 had forgotten one potentially massive, although unintentional, agent of KAOS: himself.

His $10.4 billion package wasn't an attack, but it was definitely an assault on the information systems "that increasingly lubricate our economy".

NetBank, according to CommBank's CIO, Michael Harte, is the largest transactional website in the southern hemisphere, pumping out one million of the suckers a day. Apparently you can't just inject $10 billion with the click of a button.

As Harte explained, a demand shock can knock out the bank's online systems. Fortunately for our Agent 86, preparation for the expected 300 per cent increase in demand on its systems occurred before the money had hit accounts.

But Harte said something more, suggesting the government was caught off guard (which was unfortunately cut from my original tale): the banks didn't have enough $100 notes to deliver $10 billion to recipients. The Reserve Bank was forced into printing money so that banks could distribute the funds.

Well, it's Tuesday now and so far, in terms of the systems dispensing the money, nothing has gone wrong. Now it's a matter of waiting to see if people will spend it on pokies or Christmas presents.

Agent 86 would have pulled off his shoe, dialled Ralph Norris and said: "Sorry about that, Chief".

As Agent 86 would say of the systems, "Missed it by that much" — a quip I'm sure Rudd would love to say of a recession.

But here's a suggestion for the next Cyber Storm exercise. The banking system was tested during that multinational exercise. Incident response teams were faced with keyloggers which resulted in people being unable to access their accounts online. Steven Stroud, head of Australia's Cyber Storm effort and director of e-security exercises at the Attorney General's Department noted that they addressed symptoms — they reset passwords — but forgot to address the source — removing keyloggers.

But perhaps, a more important issue for our nation's leaders to think of when talking about cyber-stuff, in light of this economic crisis, was Stroud's other criticism. "They're only talking about what they know about. They're only talking about what they can deal with, or deal with shortly. They are not projecting out how bad can this be... That doesn't happen," said Stroud.

The projection problem is really a human flaw that none of us can escape. But while there's nothing wrong with testing various systems' resilience against "hackers, commercial entities and foreign states", a little peek at the Australian GDP's year long nose-dive could have flagged that something big — something that might strain critical infrastructure — was on its way well before the Lehman Brothers collapse in August.

"We're processing gigabytes of malware daily," says Alex Eckelberry, Sunbelt Software. (Source: Sunbelt Software)

The question came up during a discussion I had at the Ruxcon security conference at the University of Technology Sydney last weekend. I was chatting to independent security researcher Nishad Herath about Morro and why Microsoft decided to give the software away for free.

Herath reckoned at least one driver for Microsoft was that some "security conscious" organisations — law enforcement agencies etc — were increasingly turning to Mac OS X because managing malware was easier on a Mac than on Windows.

With Morro, Microsoft would level the playing field with Apple when it competed for this type of business, Herath hypothesised.

"I did a bit of research into this," said Herath. "I found that because of the high volume of malware directed to Windows environments [in general] and the significantly lower stream of malware targeted to OS X, they [OS X administrators] had an easier time detecting malware."

At least some administrators would rather deal with targeted attacks than the possibly millions of accidental pieces of malware that might affect what are likely to be a pre-Vista Windows systems.

Cisco's chief security officer, John Stewart, raised a similar question about antivirus at this year's AusCERT conference. Stewart wondered why businesses were spending money on antivirus when they were still clearly spending money remediating malware-affected systems. He called the "cost equation an entire waste of money".

But these are strange times in computer security. Administrators know phishing and browser-related attacks can work against users from both camps; so it's not as if by deploying Mac OS X, users are immune to all threats.

But if part of your job is to prevent malware, you can't escape the fact that PC-targeted malware has exploded while predictions of the same fate for Macs have not materialised.

And if antivirus is your answer to malware, what about flaws affecting antivirus software? Is there any product that hasn't suffered an exploitable flaw? Norton? McAfee? Trend Micro? ClamAV? Kaspersky? Here's a link to a search on our record of AV software where flaws have been discovered.

As Herath pointed out, "introducing any additional code in to the system increases your attack surface".

Meanwhile, antivirus vendors such as McAfee have all but admitted that they can't keep up with the volume of malware being generated for PCs. Malware has also put Symantec under pressure to create less intrusive security software.

While some elements of a security package are worth the cost, the commoditised component of it, the bit that Microsoft has promised to give away in Morro, is clearly not. Morro is the nail in the coffin for this cash cow.

I could see tax commissioner Michael D'Ascenzo wipe a bead of sweat from his brow and sigh with relief when he was told the CD only affected 3,000 people and not 25 million like in the case of its UK counterpart Her Majesty's Revenue & Customs's (HMRC) missing CDs.

In the absence of data breach disclosure laws, it was commendable of D'Ascenzo to disclose the loss, but I find it surprising the ATO isn't already encrypting files on CDs it sends out into the wild.

As security consultant, Chris Gatford, from penetration testing firm Pure Hacking told me, placing files in an encrypted Zip folder ain't "rocket science"; you just need good key management practices.

The ATO reckons the lost CD is a "low risk", because for theft (ID or financial) to occur, a person would need access not just to the individual's name, address, and tax file number — the details contained on the CD — but all their account information too.

Still, the last time I spoke to the ATO's CIO Bill Gibson, he was spooked by the HMRC data breach. That incident and another CD lost by the ATO had prompted it to conduct a 72-page review of its handling of information, which was done by PriceWaterhouseCoopers (PWC).

The ATO paid a wad of taxpayer's money for PWC to conduct that review, called "Australian Taxation Office: Information Security Practices Review" (PDF), but following this incident it wants to conduct another review of its handling of information.

My message to Michael D'Ascenzo: scroll down to page 23 under the heading "Information leakage — Potential hot spots". You don't need to conduct another review. Here's what it said back in April:

"Information [at the ATO] exchanged without a consistently applied security mechanism to guard against unauthorised disclosure or loss, including: international transfer of classified information using relatively low grade encryption; unencrypted files, or non password-protected files, transferred on physical media such as CD-ROM or electronically via email."

Apparently the people that influence Australia's privacy laws do, which is why the government has given itself four years, or until 2012, to start reviewing the Australian Law Reform Commission's recommendation to include "mandatory" data breach notification measures in Australia's Privacy Act.

In the meantime Australians will have to settle for softer initiatives, like the Office of the Privacy Commissioner's (OPC) Privacy Awareness Week, which recognises "good" privacy practices by organisations, but doesn't ferret out bad security and privacy practices.

In this state of affairs, if Australian Customs were to suffer a breach where people disguised as EDS staff stole two mainframes from its high security centre, which also contained sensitive details about you, Customs won't tell you.

Until 2012 we can celebrate privacy while the US clocks up another two billion data breach notifications — the number of notices issued to its citizens since 2002, Microsoft's chief privacy officer Peter Cullen tells me.

The first areas of the Privacy Act the government has promised to tackle are health information and privacy, which is sensible since health costs impact the public purse more than anyone's right to know when your personal information is exposed.

Data security and its relationship to privacy has been put on the back burner due to one fact: no one, not the ALRC, not politicians, not the Privacy Commissioner, and especially not the public, have the foggiest idea about the extent to which data breaches have affected Australians.

We could be lucky, or perhaps have supreme intellects, which has helped Australia avoid HMRC-style mass breaches that exposed 25 million UK citizens' personal records. The Australian Taxation Office at least recognised the reality of the risk. The HMRC breach inspired a security review that found overall good practices, but significant security holes which could result in a data breach.

This was quite rare indeed. According to a recent survey by analyst firm Intelligent Business Research Services of 99 local IT managers — half came from organisations with more than 1,000 staff — many organisations could haemorrhage data without realising it, just like TJX. Asked "How would you know if an unauthorised person were to access sensitive data?", 45 per cent agreed "It's possible we would not know if this occurred".

So that's the situation. The politicians don't know, organisations that hold your information don't know and the pubic doesn't know. If ignorance is bliss, then who the bloody hell am I to question Australia as being the lucky country?

She will, as we say, be right.