3 ms·

> absolutely necessary to gauge the severity of this misconfiguration Possibly. But what's the legal basis that allows random external parties to make that det

> absolutely necessary to gauge the severity of this misconfiguration Possibly. But what's the legal basis that allows random external parties to make that determination? Report the leaked credential, and let the company assess impact. The problem is that pivoting to accessing user passwords may cause the companies to spend money notifying customers and harm their reputation. If they want to pursue legal action, those are clear damages. > Chattr.ai must contact every affected user, not MrBruh. Agreed, a pentester directly contacting impacted users would increase the risk legal gets involved. > There is no telling whether and how many outside of this disclosure have previously accessed this information Typically the company would review logs to determine that.

Topfi 3y ago
> [...] may cause the companies to spend money notifying customers and harm their reputation. I'm sorry, but I don't quite understand. Are you saying that you feel a company should not notify customers when exposing passwords in plaintext and furthermore, that this fact alone isn't harmful to their reputation? Not notifying customers, in my eyes, would destroy any semblance of reputation further. > Typically the company would review logs to determine that. Again, do you believe in the competence of someone storing passwords in plaintext? Logs may be incomplete; even a more competent organization that stores credentials following proper procedures and lost a db due to specific phishing rather than such a major screw-up would be expected to contact every customer and advise them to change their credentials, for very good reasons.
- 8organicbits 3y ago
  I'm not really commenting on the company side, but yes: plaintext passwords are bad, companies should notify customers when legally required, and I'd like companies to go further. Legally, bypassing security controls, using credentials that are not yours, and accessing data without authorization is a crime[1]. I see no indication that this blog post was authorized. Others should not consider this blog post as a good approach. Look instead to bug bounty programs and stay in-scope. Often that means creating your own account and avoiding other customer's data. While it doesn't make a good blog post, I still emphasize that the author should have reported the leaked credentials and stopped. [1] varies by jurisdiction, I'm not a lawyer, etc.
  - Topfi 3y ago
    > [...] reported the leaked credentials and stopped. But, and this can be a significant differentiator from a legal standpoint in multiple jurisdictions[0], they did not use leaked credentials, nor did they circumvent any barriers. They used a publicly accessible endpoint to create their own, completely new user that just had access rights from the get-go. [0] Sticking solely with US examples, most notably United States v. Auernheimer which was in part overturned on jurisdictional issues, in part due to the following: "We also note that in order to be guilty of accessing “without authorization, or in excess of authorization” under New Jersey law, the Government needed to prove that Auernheimer or Spitler circumvented a code-or password-based barrier to access. See State v. Riley, 412 N.J.Super. 162, 988 A.2d 1252, 1267 (N.J.Super.Ct.Law Div.2009). Although we need not resolve whether Auernheimer's conduct involved such a breach, no evidence was advanced at trial that the account slurper ever breached any password gate or other code-based barrier. The account slurper simply accessed the publicly facing portion of the login screen and scraped information that AT & T unintentionally published."

Topfi 3y ago

> [...] may cause the companies to spend money notifying customers and harm their reputation. I'm sorry, but I don't quite understand. Are you saying that you feel a company should not notify customers when exposing passwords in plaintext and furthermore, that this fact alone isn't harmful to their reputation? Not notifying customers, in my eyes, would destroy any semblance of reputation further. > Typically the company would review logs to determine that. Again, do you believe in the competence of someone storing passwords in plaintext? Logs may be incomplete; even a more competent organization that stores credentials following proper procedures and lost a db due to specific phishing rather than such a major screw-up would be expected to contact every customer and advise them to change their credentials, for very good reasons.

8organicbits 3y ago
I'm not really commenting on the company side, but yes: plaintext passwords are bad, companies should notify customers when legally required, and I'd like companies to go further. Legally, bypassing security controls, using credentials that are not yours, and accessing data without authorization is a crime[1]. I see no indication that this blog post was authorized. Others should not consider this blog post as a good approach. Look instead to bug bounty programs and stay in-scope. Often that means creating your own account and avoiding other customer's data. While it doesn't make a good blog post, I still emphasize that the author should have reported the leaked credentials and stopped. [1] varies by jurisdiction, I'm not a lawyer, etc.
- Topfi 3y ago
  > [...] reported the leaked credentials and stopped. But, and this can be a significant differentiator from a legal standpoint in multiple jurisdictions[0], they did not use leaked credentials, nor did they circumvent any barriers. They used a publicly accessible endpoint to create their own, completely new user that just had access rights from the get-go. [0] Sticking solely with US examples, most notably United States v. Auernheimer which was in part overturned on jurisdictional issues, in part due to the following: "We also note that in order to be guilty of accessing “without authorization, or in excess of authorization” under New Jersey law, the Government needed to prove that Auernheimer or Spitler circumvented a code-or password-based barrier to access. See State v. Riley, 412 N.J.Super. 162, 988 A.2d 1252, 1267 (N.J.Super.Ct.Law Div.2009). Although we need not resolve whether Auernheimer's conduct involved such a breach, no evidence was advanced at trial that the account slurper ever breached any password gate or other code-based barrier. The account slurper simply accessed the publicly facing portion of the login screen and scraped information that AT & T unintentionally published."