SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 11 submissions in the queue.
SoylentNews
The third largest breach ever just happened in Finland. Passwords were stored in plaintext. At T-Mobile Austria, they explain that of course they store the password in plaintext, but they have so good security so it's nothing to worry about. At what point does this become criminally negligent?
This discussion has been archived.
No new comments can be posted.
At What Point Does Storing Passwords in Plaintext Become Criminally Negligent
|
Log In/Create an Account
| Top
| 138 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
1
(2)
1
(2)
The difference between the right word and the almost right word is the
difference between lightning and the lightning bug.
-- Mark Twain
(Score: 4, Interesting) by MrGuy on Sunday April 08 2018, @02:59PM (3 children)
I assume the question as asked is referring to legal, not moral, liability. IANAL, so take all this with a grain of salt. I'm also only familiar with the US system of determining liability. That said...
The problem here is what's legally referred to as an intervening cause. [wikipedia.org] If I do something negligent that could eventually cause injury but would not do so on its own, but then something happens done by someone ELSE that actually causes the injury, I may not be liable because the injury only ACTUALLY occurred because of someone else's action (the "intervening cause").
In this case, the hacked company may be negligent. The question is whether the action of the hacker breeching the company's server and stealing the actual data is an "intervening act" that absolves the hacked company of liability.
The key determining factor is whether the eventual injury is "forseeable" - whether the original person could have reasonably forseen the action that actually caused the injury. If you're a technologist, this seems to make it cut and dry - of COURSE getting hacked is a "forseeable" outcome of having a server on the internet. That said, the law is a lot murkier in this case. Because the action of hacker is illegal. It's not clear whether the duty to "forsee" actions extends to illegal activity, especially when you take "reasonable precautions" to prevent illegal activities (this is precisely the argument T-Mobile is making - our security is so good it doesn't matter). Does circumventing "reasonable" or "industry standard" security make the action "unforseeable"?
Take an example - let's say you're responsible for closing the safe in my office. You negligently leave the safe open. Someone breaks in and robs it. Are you liable?
If the office doesn't have a good lock, and is in a building that's open to the public, then someone breaking into my office is probably "forseeable." Sure, the robber had to illegally enter the office to commit the robbery But you were negligent and you really should have anticipated someone else getting into the office and robbing the safe.
Now consider if your office is in a locked building, with a security guard in the lobby that checks people into and out of the building. There are cameras everywhere. The office has a steel reinforced door, with a high-tech lock. It turns out the burglars forged ID credentials to the building, disabled the security cameras remotely, and had broken into the lock company's server to get the design of a duplicate key. This makes the break-in considerably less "forseeable" - my actions might have been negligent, but I couldn't reasonably have anticipated that someone could break through all the security, so my negligence in leaving the safe open is probably negated by the "intervening act" of the high-tech robbery.
The open and unsettled question is where the bar is - how much can companies hide behind "Those crafty hackers defeated state-of-the-industry security measures to get the data!" vs. "Oops - we left the equivalent of the front door open."
(Score: 3, Insightful) by requerdanos on Sunday April 08 2018, @04:19PM
In the case of either...
not only could the original person have forseen the action, but so could have a blind, syphilitic monkey [bmj.com].
(Score: 3, Informative) by darkfeline on Sunday April 08 2018, @10:32PM (1 child)
The thing is, hashing passwords is so easy and is such a basic security practice that not doing so is a clear failure to take "reasonable precautions".
Also, breaches happen so often (literally every other day) that of course it is a "foreseeable" event. It happens much more often than, say, people getting killed by unprotected high voltage wires, it's much easier to protect against via hashing/salting, it affects millions/billions time as many people when it happens, and somehow failure to take reasonable security precautions is not gross negligence?
I'm not saying that this is how the law will be interpreted "de facto", but rather how the law should be interpreted "de jure" in the spirit of the law by anyone with (not so) common sense.
Join the SDF Public Access UNIX System today!
(Score: 0) by Anonymous Coward on Monday April 09 2018, @10:45AM
But how else would you have "cleaver" security systems, like tell you that you have used part of the password before, going months? And then tell you to update your password every 3 months?
Yes, the world is retarded.
(Score: 4, Interesting) by canopic jug on Sunday April 08 2018, @03:03PM (3 children)
A historian would be able to better answer the question of how many decades it has been established as best practice to use a salted hash for passwords. Regardless of the details the answer will be in decades, and there is no excuse for any manager to sign off on such failed designs as we are seeing in the news.
Apparently a crypt(3) function first appeared in Version 7 AT&T UNIX [freebsd.org], but if I read correctly it was symmetric. It's been at least since 1995 when Paul-Henning Kamp worked up md5crypt() [freebsd.dk], which is long since replaced and getting close to 25 years ago already.
Sufficiently advanced incompetence is indistinguishable from malice.
Money is not free speech. Elections should not be auctions.
(Score: 2, Insightful) by Anonymous Coward on Sunday April 08 2018, @03:27PM (1 child)
> Sufficiently advanced incompetence is indistinguishable from malice.
Well, in case of incompetence, "advanced" is probably not the right word. What's the opposite of "advanced"? "Retarded"? Yes, that one works on multiple levels.
Sufficiently retarded incompetence is indistinguishable from malice.
(Score: 4, Funny) by Azuma Hazuki on Sunday April 08 2018, @03:34PM
Yyyyyup. I've been saying this for years now, usually phrasing it as "Hanlon's Razor loses its edge when there's enough incompetence."
I am "that girl" your mother warned you about...
(Score: 2) by choose another one on Sunday April 08 2018, @04:19PM
> A historian would be able to better answer the question of how many decades it has been established as best practice to use a salted hash for passwords.
And how do partial password implementations (which is, I think, standard in some form on all of the banking sites I use) work with your "best practice"?
It all depends where you think the weakest point in the security actually is, sometimes the weakest link is the client or the customer, client-side malware, phishing or plain old shoulder surfing may be a much larger risk (and far more difficult for a bank, say, to control and secure) than server-side password storage. Partial password implementations reduce client-side risks. Incompetence?
(Score: 0) by Anonymous Coward on Sunday April 08 2018, @04:53PM (4 children)
At a top 5 CS university, passwords were until recently stored plaintext, supposedly because of interoperability reasons with legacy green screen services.
(Score: 1, Interesting) by Anonymous Coward on Sunday April 08 2018, @05:20PM (2 children)
here in a top 5 canadian U, they are AES encrypted for interoperablity but the password to the master key in plain text, however you need to have the code to uncypher them cause we do proper keys derivation. the master key is never directly use to encrypt or decrypt, to do so you need a cipher key derived by hashing the master key concatenated to it's usage context. You cannot get around the fact that somewhere you have to have a key or a password stored in plaintext somewhere unless your willing to pay an operator who know the password/key to be present if a service needing cyphers is restarted
(Score: 0) by Anonymous Coward on Sunday April 08 2018, @07:12PM
I feel a public key crypto solution could be created without having the users password needing to be stored, and the legacy app getting a completely random password based on its requirements.
(Score: 2) by Joe Desertrat on Monday April 09 2018, @09:59AM
Don't worry, that is on the sticky note on the monitor.
(Score: 2) by darkfeline on Sunday April 08 2018, @10:39PM
I'm not surprised, Computer Science is almost entirely unrelated to Computer Engineering (Software or Hardware) or Information Technology.
It's like expecting a Math department to know whether their building conforms to civil engineering standards, and to be able to rectify any problems that exist.
Join the SDF Public Access UNIX System today!
(Score: 0) by Anonymous Coward on Sunday April 08 2018, @05:48PM (1 child)
At the moment of decision, implementation, general release. Whichever comes first
(Score: 0) by Anonymous Coward on Sunday April 08 2018, @11:41PM
How does general release come before decision and implementation?
No, wait, don't answer that. I really don't wanna know.
(Score: 2) by https on Sunday April 08 2018, @06:00PM
...and maybe even before that, given the existence of Heartbleed, Shellshock, Spectre, etc. Treble penalties for sending over a network interface.
Offended and laughing about it.