X
Tech

The taxpayer-funded plain text password store

What's worse than a clueless security team that doesn't care about securing the details it receives? One that you're paying for with your tax dollars.
Written by Michael Lee, Contributor

There are so many sites that store passwords in the clear that normally when I come across one, I make a mental note to never trust it with anything too important, or to find a similar service that actually does care about security.

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.

ATO's banned password list
Part of the POS password ban list.
Image: Screenshot by Michael Lee/ZDNet

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.

Editorial standards