Forgot your password?
typodupeerror
Australia Security IT

Australian Tax Office Stores Passwords In Clear Text 84

Posted by Soulskill
from the you're-doing-it-wrong dept.
mask.of.sanity writes "The passwords of thousands of Australian businesses are being stored in clear readable text by the country's tax office. Storing passwords in readable text is a bad idea for a lot of reasons: they could be read by staff with ill intent, or, in the event of a data breach, could be tested against other web service accounts to further compromise users. In the case of the tax office, the clear text passwords accessed a subsection of the site. But many users would have reused them to access the main tax submission services. If attackers gained access to those areas, they would have access to the personal, financial and taxpayer information of almost every working Australian. Admins should use a strong hash like bcrypt to minimize or prevent password exposure. Users should never reuse passwords for important accounts."
This discussion has been archived. No new comments can be posted.

Australian Tax Office Stores Passwords In Clear Text

Comments Filter:
  • by ShanghaiBill (739463) * on Thursday February 28, 2013 @11:22AM (#43034597)

    Storing passwords in readable text is a bad idea for a lot of reasons

    It needs to be more than a bad idea: it needs to be illegal, and people or organizations that betray their users' trust, need to pay a price for their negligence.

    But we need to go further than that. When forms are submitted, browsers should not allow "hidden" fields to be transmitted directly, and instead should have a default action of encrypting them with Bcrypt [wikipedia.org] or SHA-256. [wikipedia.org] When building a website, many people will use defaults and follow the easiest path. The default should be transmission of encrypted passwords, not plaintext.

    • by characterZer0 (138196) on Thursday February 28, 2013 @11:31AM (#43034715)

      encrypting them with Bcrypt [wikipedia.org] or SHA-256

      If only there were a widely deployed standard way of encrypting data submitted to web servers.

      • by Tarlus (1000874) on Thursday February 28, 2013 @11:43AM (#43034857)

        But if web developers aren't even hashing up their password db's, who's to say they'll be competent enough to employ SSL?

        • The user has no control over how the server hashes passwords. The user has a choice not to submit unencrypted data.

          Unless, of course, the government mandates it.

          • by Tarlus (1000874)

            True. But I have to ask the same question again: Who's to say that users will be competent enough to know the difference? Users should be smart enough not to reuse passwords, and it's within reason to expect them to recognize when that little green HTTPS padlock is present, but the technical details of how this is handled internally by a legitimate company cannot and will not be understood by the average user.

            It does raise an interesting question about where the responsibility of these things lie, and given

        • by Anonymous Coward

          If browsers started warning people when the submitted form contained a password field and the destination was not over SSL, developers would learn pretty fast.

      • If only there were a widely deployed standard way of encrypting data submitted to web servers.

        Of course there is. [wikipedia.org] But that solves a different problem: a password will be encrypted in transmission, but is unencryped on the other end, so the server will still receive your form with plaintext passwords. By default, input fields of type "password" should be encrypted and only the encrytped password should be sent to the server. The server should have no access to the plaintext. They can't store what they don't have in the first place.

        • by Tarlus (1000874)

          Also, having a web browser submit a hashed password without SSL would do nothing to protect your account. It could still be intercepted and used by a malicious third party. They just wouldn't know right out in the open what the original password is.

    • by Anonymous Coward

      I thnk you mean "password" fields, not hidden. Hidden input fields are used to transmit all sorts of data, and rarely is it sensitive enough to warrant client-side encryption. They generally dont even carry data that was actually submitted by the user.

    • by SirGarlon (845873)

      It needs to be more than a bad idea: it needs to be illegal

      Yeah, because what we really need in IT are more compliance checklists and more lawyers and more absolute rules that never get revisited or updated.

      • by JDG1980 (2438906)

        Yeah, because what we really need in IT are more compliance checklists and more lawyers and more absolute rules that never get revisited or updated.

        Under what circumstances do you believe it is appropriate, or would be appropriate at any time in the future, for a website to store passwords in clear-text?

        • by Chris Mattern (191822) on Thursday February 28, 2013 @12:03PM (#43035163)

          The problem is, I am very leery of having those who are not knowledgable pass rules on technical matters, even if the correct rule would be absolutely helpful, because they are likely to pass *almost* the correct rule. I can see this very easily changed from "you cannot have cleartext passwords" to "you must have encrypted passwords" by the time it gets passed.

          "Where are your encrypted passwords?"
          "We use PKI keys, we don't have *any* passwords"
          "So you don't have any encrypted passwords?"
          "No, we don't need them."
          "Off to jail with you, then."

        • by SirGarlon (845873) on Thursday February 28, 2013 @12:50PM (#43035841)

          That's not the point. I do not believe it is appropriate to develop software without a revision-control system in place, but I've seen people do it. I do not, however, advocate a law to require people do basic obvious stuff like that.

          There are several reasons, but the foremost is probably that ill-informed people (technical and non-technical) tend to mistake "going through the motions" for "doing it right." That is, checklists promote a cargo cult [wikipedia.org] approach to security.

          Compliance != good design, and indeed compliance is only a subset of good design when the requirements are perfect.

        • by Smauler (915644)

          I'm not an expert here.... but 15 years ago when I set up a fantasy football website for me and my friends, I immediately understood the security implications of storing passwords in plain text. I was working on the database directly - I didn't want to know my friend's commonly used passwords. Most of them were not too tech savvy, I don't think anyone asked me about password storage.

          All I did was store a truncated MD5 hash, IIRC. This wasn't high security stuff... I just didn't want to know their passw

      • by dkleinsc (563838) on Thursday February 28, 2013 @11:57AM (#43035085) Homepage

        Yeah, because what we really need in IT are more compliance checklists

        Yes, we do, because it's abundantly clear that there are lots of IT organizations that can't meet the basic requirements of doing the job properly.

        and more lawyers

        Yes, to deal with the cases where IT organizations skimp or lie about meeting the requirements.

        and more absolute rules

        Yes, so they know when they're in compliance and when they aren't. For example, a rule that "No password may be stored in clear text." is quite absolute, and also appears to be quite necessary.

        If it weren't a financial system that everyone in Australia is required by law to use, I'd be fine with the standards being looser, because then the damage would be less.

    • by Anonymous Coward

      Storing passwords in readable text is a bad idea for a lot of reasons

      It needs to be more than a bad idea: it needs to be illegal[.]

      My god son, you've just made possession of Post-It Notes into a felony.

    • by rminsk (831757)

      ...browsers should not allow "hidden" fields to be transmitted directly, instead should have a default action of encrypting them with Bcrypt or SHA-256.

      So now I steal the database of hashes that the browser transmitted. Just as good as having the plaintext. Now all I need to do is send the hash.

      • by rtaylor (70602)

        Indeed. The Hash is the plaintext password.

        Hashing a password only protects a users account on other websites when they're silly enough to use the same password on all websites.

        It also makes it damndably difficult to strengthen or change the hash if a problem is found. If you picked MD4, you're stuck with it forever.

        I don't know what the solution is but hashing the password in the DB has created as many problems as it solved for me.

        • Indeed. The Hash is the plaintext password.

          Hashing a password only protects a users account on other websites when they're silly enough to use the same password on all websites.

          It also makes it damndably difficult to strengthen or change the hash if a problem is found. If you picked MD4, you're stuck with it forever.

          These objections are only true if the client-generated hash is stored directly. There is nothing to stop a competent admin from applying another hash on the server side.

        • by Bengie (1121981)
          Hashing the password also protects the user on the current website, assuming both the has hand the password are strong.

          Add another field to your back-end, next time the user logs in, hash using the new algorithm.
    • by blueg3 (192743) on Thursday February 28, 2013 @12:03PM (#43035153)

      But we need to go further than that. When forms are submitted, browsers should not allow "hidden" fields to be transmitted directly, and instead should have a default action of encrypting them with Bcrypt [wikipedia.org] or SHA-256. [wikipedia.org] When building a website, many people will use defaults and follow the easiest path. The default should be transmission of encrypted passwords, not plaintext.

      This is why security is often so terrible: people don't know what they're talking about when it comes to security, but they throw some encryption (or in this case, hashing) at the problem and hope it solves it, like pixie dust.

      Hashing isn't encryption; encryption is reversible, while hashing isn't. There's already a system for encrypting transmissions between a browser and a Web server.

      If you hash the password before transmitting it, then the hash is simply the password. Sure, it doesn't look like "password" or "123456", but it retains all of the security problems that a plaintext password does. It provides absolutely no security benefits, but it looks better (if you don't look too hard) because you've applied some crypto, somewhere!

      • by Smauler (915644)

        Hashing before sending is pointless... except for the fact that your password is not easily guessable.

        Hashing on the server side should be basic common sense, which is what this story is about.

        • by blueg3 (192743)

          How about you read the comment to which I was replying? I quoted the relevant part in my comment, even.

          Here, I'll do it again.

          When forms are submitted, browsers should not allow "hidden" fields to be transmitted directly, and instead should have a default action of encrypting them with Bcrypt or SHA-256. ... The default should be transmission of encrypted passwords, not plaintext.

          They're talking about hashing before sending.

          I agree that the article is about the actually-useful practice of hashing server-side. But my comment is rightfully about the useless suggestion of hashing client-side.

    • by Bert64 (520050)

      If you encrypt/hash the data before you send it then you no longer need the plaintext, the hash becomes the plaintext equivalent. Also any sensible passwd hashing algorithm will be salted, so you would need to leak the user's salt *before* they authenticate.

      While not illegal, many security guidelines (some of which are mandatory within certain circles) require that passwords be appropriately hashed etc... Windows generally doesn't comply with such guidelines (stores plaintext in memory, uses unsalted hash,

    • Yes, unencrypted passwords should be illegal. So use Rot-13.

      Seriously, there should probably be some minimum requirements for encryption.

      But we need to go further than that. When forms are submitted, browsers should not allow "hidden" fields to be transmitted directly, and instead should have a default action of encrypting them with Bcrypt [wikipedia.org] or SHA-256.

      Be careful that you can still work with older browsers. While browser improvements are great, they don't get deployed everywhere overnig

    • by tlhIngan (30335)

      Storing passwords in readable text is a bad idea for a lot of reasons

      It needs to be more than a bad idea: it needs to be illegal, and people or organizations that betray their users' trust, need to pay a price for their negligence.

      One of the problems I see is if they can't be bothered to hash passwords, they probably can't be bothered to do it right despite what the law says. After all, a hashed password table is just as bad if used incompetently, maybe worse because of a false sense of security.

      Thing stuff

    • by mlts (1038732) *

      What might be an idea would be client-side HTML5 code to do the MD5/SHA/bcrypt hashing [1] on the local machine before sending it up. This doesn't get rid of the need for SSL, but it does ensure that the original passphrase is extremely hard to obtain.

      If for some reason a passphrase has to be stored for some reason (perhaps it needs retrieval intact), then there is a fairly easy way to deal with that: Have a clientside app that takes the password plus a salt and encrypts it with the site's public key [2].

    • by abigsmurf (919188)
      There are a few thousand ways you could 'hide' a input field, you could maybe protect against 2 of them.

      In return for that pathetic amount of protection you would break millions of websites.
    • You don't want to use SHA-256 by itself, because that's a high speed unsalted hash algorithm.

      Ulrich Drepper created a good password crypt algorithm which incorporates SHA-256 or SHA-512, but the features that make it resistant to dictionary attack are the salt and the massive iterations over SHA to slow down the algorithm.

      BCrypt uses the same techniques to slow down dictionary attacks.

    • If the password is hashed client side and the database gets exploited, you've just given access to everyone.
      Since they can just manually use the hash from the db to log in.

      You'd need to do double hashing with per site salt to counteract it.

      Or just use SSL like everyone else suggested. Somewhat easier and doesn't have that problem.
      Or you could manually SHA1 your passwords and use the hashed copy as your password for long and pseudorandom passwords.

    • by prshaw (712950)

      And who should write the law on this? Who enforces the law?
      I don't think I want the 'International Internet Police' coming to my house to see if I have applied the correct level of security to the passwords stored on my computer.
      Hell, I don't want the 'International Internet Police' coming to my house for anything!

    • Agreed about making it illegal... but many US companies store passwords in clear text too. Most notably many cell phone companies store your PINs in cleartext... any agent at the carrier can see what yours is.

      This has been a pet peeve of mine for years... when companies have (are required?) privacy policies about what they do with your personal information yet there's no discussion at all as to what they do with your passwords, it's like putting a bandaid on a severed artery.

    • More laws are rarely the answer. Saying "There should be a law" is really saying "I trust the bastions of incompetence in the halls of government to do ..." I don't trust those halls to pick up garbage, much less to regulate IT.

  • not a excuse to not pay your taxes so suck it up and pay

  • emasculating my password, and book-ending my brain. Please make them stop.

  • by Jawnn (445279) on Thursday February 28, 2013 @11:33AM (#43034751)
    That kind of brain-dead security fail should be illegal, and I mean pay "a fine and go to jail" felony-type illegal. It is clear understatement to say that there is simply no excuse for this to have happened.
    • So you would put the blame on the person that failed to stop someone from doing something illegal as in "felony-type illegal". Should the blame and punishment be applied to the real criminal instead? Our mailboxes don't even have locks around here. And it's not a problem. Why? Because there are severe penalties for touching someone elses mailbox. You would rather jail the owner of the postbox because they did not prevent the theft by putting a lock on the postbox. Why not jail the person breaking into the
      • by Bengie (1121981)
        Should the baby sitter be blamed for handing your child to some random homeless guy or should you blame the homeless guy?

        Gross Professional Negligence.
      • by Jawnn (445279)
        I should not have to point this out, but storing passwords in the clear, for a large collections of users, on a system that contains sensitive data, is hardly the same thing as having a mailbox without a lock. All of those users have a reasonable expectation that their accounts will be secure. The keepers of that particular system have pissed on that trust. They should be punished for so willfully disregarding their responsibility here.
    • What? No. Anal gang rape prison is disproportionate to being too dumb to hash passwords.

      This should be a simple matter of strong liability for misdeeds. With actual liability, website owners would be strongly incentivized to take out insurance, and those insurance companies would be strongly incentivized to see that their insured has good security practices.

      If you have to mandate something, make it displaying their compliance certificate on their website, preferably in a machine-readable format. But eve

  • No one looks down there.
  • Most of us have very busy lives and not enough time to remember long passwords especially long paswords with CAPS and numbers. It is quicker to sign up for a new gmail account than figure out that password you never used in a month. Now why don't people think of the poor abandoned email accounts tying up that username you really wanted? Now my bank and credit card pins came in the mail in plain text. Its not usually a problem. Why you ask? Because it is very illegal and you will spend a lot of time in jail
  • Why is it still the case that we live in terror that someone can get our secret financial information and ruin our lives? Secret information that is frequently scattered around in the public domain anyway. At this point it should be possible to lock down financials and identities so that this problem is in the past.
    If nothing else, someone should see a business opportunity in offering that kind of security. Move your money to this bank/credit because we offer real financial protection for you. You w

  • by Todd Knarr (15451) on Thursday February 28, 2013 @12:07PM (#43035197) Homepage

    Unfortunately, as has been demonstrated recently, hashed passwords don't protect very well against attacks either if the intruder gets access to the stored passwords themselves. Faster and cheaper hardware combined with cheap storage have allowed attacks on hashed passwords that would've been infeasible only a few years ago. And hashed passwords on the back-end mean that cleartext passwords almost have to be passed over the wire where they're vulnerable to interception not just by things snooping network traffic but by malware that's inserted itself into the network stack on either end.

    And most importantly, storing passwords in the clear makes it perfectly clear that they are vulnerable to any compromise that gives an intruder access to the stored passwords. Having them hashed gives a false sense of security and the opening to argue that compromises don't have to be disclosed because the passwords are hashed and thus haven't really been compromised, even though the hash isn't going to really keep the passwords from being compromised.

    I much prefer a system that segregates passwords onto a dedicated authentication service that runs on a machine that's walled off and isolated from even the production machines except for the small hole needed for access to the authentication service (which should be written, at least the input and input-parsing portions, by professional paranoids). Then store passwords on it in the clear if needed so you can use challenge-response authentication methods that avoid needing to transmit the password itself between the client and your systems. That way your efforts to protect the passwords can be concentrated on that authentication server with it's relatively small exposed area, rather than on your entire system with it's large exposure to attacks.

    • by scorp1us (235526)

      Wrong on many accounts. I have a browser plugin [crossrider.com] and website [passhasher.com] that doe password hashing in the client (via javascipt) your password is not transmitted, the hash is computed locally.

      These are still vulnerable to dictionary attacks because the dictionary can be quickly hashed. That's why the hashes int he website and plugin above is variable. You can set your hash for any number. We default at 20, which does slow the attacker down. However the attacker won't know where to stop and they are only looking at hash

      • by Todd Knarr (15451)

        That sounds like a challenge/response system. Does the plug-in require that the server send a random nonce? If not, it's vulnerable to replay and pre-play attacks, since without the nonce the hash values are predictable. And with a nonce you should only need one exchange, assuming your hash algorithm is sufficiently robust (if it isn't, I'm afraid no number of repetitions will make the exchange secure).

        Note: as has been demonstrated repeatedly over the last decade, any cryptographic system that's vulnerable

        • by Sarten-X (1102295)

          It's not a challenge-response system at all. The website (and I assume the plugin as well) will generate a long hash value based on the website name and a different personal password. That long hash can be used as the password on a website, so if the website's breached, the user's short password is protected. It's not about maintaining the security of that particular account (which is a moot point if the server's been thoroughly hacked), but rather letting the user have one password to remember easily for a

    • FYI challenge-response systems do not require storing the plaintext password

      • Does a challenge-response system appear as part of the spec for html, or implemented by common web toolkits? So many websites sound as if they are rolling their own login system which simply hides the password typed in and that's it! Do Amazon, eBay or gmail use a challenge/response system?!
      • by Todd Knarr (15451)

        Can you point to one that uses a random nonce to insure that responses can't be recorded and reused and can't be predicted before the actual transaction, and that use a process where the hashed form of the password can't simply be treated as the password itself?

  • Or they did as of not very long ago at all - I had to recover my password on their site, and just about fell out of my chair when, instead of sending me a recovery link, they emailed me my current password.

    Nowadays that password is a KeePass-generated random one.

  • I once got access to the unencrypted password file for a widely used site. It was rather disturbing -- and not just because the passwords were unencrypted ("It's fur customer service purposes!"). Literally 10% of the users had 'password' as their password.

    I guess that it wasn't quite as bad as the network service provider that had 'password' as the password through their firewall.. I mean, why even have the thing, to begin with?

  • by abigsmurf (919188) on Thursday February 28, 2013 @01:39PM (#43036525)
    The information in your tax account is probably far more damaging than just your password and that is stored in plain text. If you don't trust them with your password, why the hell do you trust them with all that other information?

    Tax offices usually have to deal with a wide variety of enquiries, some of which may not be done over the phone. Passwords/secret phrases can be a nightmare over the phone, especially for someone non-technical, having plain text passwords allows you to verify that a granny who says "21 primrose hill" is their password when it's stored as "21 Primrose-hill".

    My bank (Barclays) doesn't use encrypted passwords, they use the "say the 8th and 6th letters of your password" system plus chip + pin to verify you. As they're a high priority target for phising, key logging and MITM, it is actually far safer to do this then force the entire password the whole time.

    TLDR: password hashing is an (easy) additional layer of security but it comes with its own drawbacks, isn't the be-all and end-all to security and isn't needed if security measures are strong enough.
  • The OP is right that there's no point in using a high speed naked hash algorithm, but BCrypt isn't the only good alternative.

    There's also SHACrypt-256 and SHACrypt-512 [akkadia.org], which have been supported in GNU LibC since October 2007.

    Wikipedia has a pretty thorough discussion [wikipedia.org] of the various password hash routines that are in use on Unix/Linux systems, for that matter.

  • The Secure Remote Password protocol has been out for more than a decade now. Sites shouldn't even be storing hashed/salted passwords by this point. They should never even have possession of the actual password on the server side.

  • A separate company that is managing a Publication Ordering Service for the Tax Office is storing passwords in plain text. I had to help set up access to the ATO portal at my last job and it requires installing company specific certificates per user or to be running a specific security application which, requires installing company specific certificates, the for the login screen to even show up
    • by SJ2000 (1128057)
      That's right, summary is completely false.

      The system is run externally by the warehouse and separately to the ATO," a spokesperson told SC....It is unable to access taxpayer information or their details. There are no financial or bank account details stored on POS.

      A case of not reading the article, it's blatant FUD.

Are we running light with overbyte?

Working...