Australian Tax Office Stores Passwords In Clear Text 84
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."
Re: (Score:2)
Can't tell what's being Slashvertised here...
Storing plaintext passwords should be illegal (Score:4, Insightful)
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.
Re:Storing plaintext passwords should be illegal (Score:5, Funny)
If only there were a widely deployed standard way of encrypting data submitted to web servers.
Re:Storing plaintext passwords should be illegal (Score:5, Interesting)
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?
Re: (Score:2)
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.
Re: (Score:2)
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
plaintext passwords (Score:2)
That's not a password.... This is a password!
Re: (Score:1)
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.
Re: (Score:3)
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.
Re: (Score:1)
"Also, password is never sent in plain-text anywhere. Not even over encrypted link."
Not true, both sides need a shared secret. So there is a little problem at account creation time/password updates. Never the less, it is much much much more secure since passwords are only transmitted once.
Re: (Score:2)
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.
Re: (Score:1)
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.
Re: (Score:2)
This would still allow attackers to log in as anyone they wanted if they got a dump of "plaintext" passwords - they would just send the hash instead.
Only if the hashes were stored directly. Any competent website admin would add another layer of ecryption on the server side before storing the password. Any good security scheme requires defense in depth, and client side password encryption would just be one additional level. But as TFA shows, in many cases that one level would be replacing zero levels.
Re: (Score:2)
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.
Re: (Score:2)
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?
Re:Storing plaintext passwords should be illegal (Score:5, Interesting)
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."
Re:Storing plaintext passwords should be illegal (Score:4, Interesting)
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.
Re: (Score:2)
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
Re:Storing plaintext passwords should be illegal (Score:4, Insightful)
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.
Re: (Score:1)
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.
Re: (Score:1)
...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.
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:2)
Add another field to your back-end, next time the user logs in, hash using the new algorithm.
Re:Storing plaintext passwords should be illegal (Score:4, Informative)
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!
Re: (Score:3)
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.
Re: (Score:2)
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.
Re: (Score:3)
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,
Re: (Score:2)
Seriously, there should probably be some minimum requirements for encryption.
Be careful that you can still work with older browsers. While browser improvements are great, they don't get deployed everywhere overnig
Re: (Score:2)
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
Re: (Score:2)
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].
Re: (Score:2)
In return for that pathetic amount of protection you would break millions of websites.
No, not SHA-256 (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:1)
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!
Re: (Score:2)
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.
Re: (Score:2)
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 (Score:2)
not a excuse to not pay your taxes so suck it up and pay
The Austrailian government is... (Score:2)
emasculating my password, and book-ending my brain. Please make them stop.
It SHOULD be illegal (Score:3, Insightful)
Re: (Score:3)
Re: (Score:2)
Gross Professional Negligence.
Re: (Score:1)
Re: (Score:2)
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
Re: (Score:2)
Anal gang rape prison is disproportionate
FTFY
It's ok, because they're downunder (Score:2, Funny)
Why people reuse passwords. (Score:2, Interesting)
Financial security should be stronger than secrecy (Score:2)
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
Hashes not enough either (Score:4, Insightful)
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.
Re: (Score:3)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
Correct!
Also, this XKCD [xkcd.com] applies as well.
Re: (Score:2)
FYI challenge-response systems do not require storing the plaintext password
Re: (Score:1)
Re: (Score:2)
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?
Re: (Score:2)
T-Mobile does it too (Score:2)
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.
How many had 'password' as their password? (Score:2)
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?
Hashing is not always the best solution (Score:3)
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.
BCrypt or SHACrypt256/SHACrypt512 (Score:2)
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.
SRP (Score:2)
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.
It's a third party not the ATO (Score:2)
Re: (Score:2)
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.