liability security
Has it been Legally Confirmed that A Website is not Liable if passwords stolen from it are used on other sites?
<p>Security Experts the world around all agree that you should not reuse passwords across sites. This is simply a matter of best practice, and it protects you such that if your StackExchange password is stolen, they can't use that to access your bank account.</p>
<p>The general feeling I get from my security friends is that this &quot;advice&quot; is legally bulletproof, and that if their website is hacked, and plaintext passwords are stolen, they don't have to worry about someone suing them because the password that was stolen from their website was also used on that person's banking page. After all, &quot;It's the user's fault for reusing a password!&quot;</p>
<p>Has this belief actually been upheld in court yet? Or is this a firestorm waiting to happen when Amazon turns out to be the victim and they sue some smaller organization for every penny it has?</p>

<p><a href="/questions/tagged/united-states" class="post-tag" title="show questions tagged &#39;united-states&#39;" rel="tag">united-states</a></p>
<p>The argument you are making, restated in legal terms, is roughly as follows:</p>
<ol>
<li>Users have a duty to not reuse passwords.</li>
<li>When a user reuses a password, and their password is subsequently stolen and used to fraudulently access the plaintiff's system, that password reuse becomes the proximate cause of the plaintiff's business injury.</li>
<li>Therefore, our storage of plaintext passwords cannot be the proximate cause, and so we cannot be liable.</li>
</ol>
<p><strong>This argument is mostly wrong.</strong> Leaving aside the fact that you're going to have a tough time convincing a jury of #1, a tort may have more than one proximate cause. Both the password reuse and the plaintext storage were but-for causes of the injury (i.e. if either had not happened, then the injury would not have happened). The injury was foreseeable, because it is well known in the security industry that many users in fact do reuse their passwords, professional advice notwithstanding. In most US states, that's enough to establish proximate cause. In the minority of states using the &quot;direct causation&quot; test, you <em>might</em> be able to characterize the user's password reuse as an intervening cause, and thereby avoid liability.</p>
<p>However, there are other elements of tort law which must be established aside from proximate cause, and so by itself this does not resolve the question of liability. Other defenses might be applicable; for example, the terms of service might contain an indemnification agreement, which (if upheld) would make the user(s) responsible. The defendant might also argue that there is no duty of care, that it was not breached, or that the injury was or <a href="https://en.wikipedia.org/wiki/Comparative_negligence" rel="noreferrer">should have been</a> <em>de minimis</em> (i.e. that the plaintiff should have taken greater care to prevent damages arising from account hijacking).</p>

<p>If the customer is in the EU (or UK or EEA) and services were offered, targeted or marketed to that area, the GDPR applies. If the organization running the site has an establishment  in the EU, the GDPR also applies. If the customer is in California, the CCPA applies. Other US states, including Colorado and Virginia, have recently passed data protection laws somewhat similar to the CCPA. Other jurisdictions may well pass such laws in future.</p>
<p>All these laws require that &quot;appropriate&quot; technical safeguards be used when storing personal data. And yes, passwords are almost surely personal data under these laws.  Exactly what is an appropriate level of security is not defined in detail. It depends on the nature of the information involved, and the risks of a possible breach. It also changes with the current state of technology.</p>
<p>Given that security best practice is <strong>never</strong> to store plaintext passwords, but only salted one-way hashes of passwords, there might be an argument that any system that stores plaintext passwords is not taking appropriate security measures.</p>
<p>The CCPA gives consumers a private right of action if a data breach compromises their information through a failure to take appropriate precautions. This means that individual consumers can sue companies that have breaches due to poor practices for up to $7,500 per consumer. The GDPR allows consumers to complain to a supervisory agency, which can impose significant fines.</p>
<p><a href="https://www.omm.com/resources/alerts-and-publications/alerts/ccpa-case-tracker/" rel="noreferrer">This CCPA Case Tracker</a> lists several large data breach cases now in process. It does not say whether passwords were an element of the breach in all cases.</p>
<p>In <a href="https://www.hklaw.com/en/insights/publications/2020/07/litigating-the-ccpa-in-court" rel="noreferrer">&quot;Litigating the CCPA in Court&quot;</a> from the law firm of Holland &amp; Knight (July 2020) it is said that:</p>
<blockquote>
<p>In the new wave of CCPA data breach cases, plaintiffs have generally pleaded a right to statutory damages, and also often seek restitution and an injunction against defendants' continued (allegedly) improper handling of personal information. Only a small percentage of cases allege actual damages as a result of the purported incident.</p>
</blockquote>

<p>Bluntly, the argument is obviously nonsensical. It's so absurd that it can't even be made with a straight face.</p>
<p>Here is how you've described it:</p>
<p>&quot;Security Experts the world around all agree that you should not reuse passwords across sites. This is simply a matter of best practice, and it protects you such that if your StackExchange password is stolen, they can't use that to access your bank account.&quot;</p>
<p>Let's try the equal and opposite version of the very same argument:</p>
<p>&quot;Security Experts the world around all agree that you should not store passwords in plaintext. This is simply a matter of best practice, and it protects you such that if your StackExchange password is stolen from storage, they can't use that to access your bank account.&quot;</p>
<p>See the problem?</p>
<p>There are <em>two</em> things, both best practices, that everyone is supposed to do to protect from this scenario. You are saying that you can deliberately choose not to do one of them because you can rely on others to do the other. But if that were correct, that argument would apply equally well to users being able to rely on site operators not to store passwords in plaintext.</p>
<p>So anyone who thinks that argument is correct needs to explain why the user can't make the same argument. Because, obviously, they can't both be right.</p>
<p>No such explanation is possible.</p>
<p>And, of course, it would be the site who would have additionally somehow allowed its password database to get stolen. So arguing for a 50/50 split in responsibility won't even work here.</p>
