Stories
Slash Boxes
Comments

SoylentNews is people

posted by on Wednesday March 22 2017, @05:14AM   Printer-friendly
from the bad-sysadmin,-no-biscuit dept.

The operator of a website that accepts subscriber logins only over unencrypted HTTP pages has taken to Mozilla's Bugzilla bug-reporting service to complain that the Firefox browser is warning that the page isn't suitable for the transmission of passwords.

"Your notice of insecure password and/or log-in automatically appearing on the log-in for my website, Oil and Gas International, is not wanted and was put there without our permission," a person with the user name dgeorge wrote here (the link was made private shortly after this post went live). "Please remove it immediately. We have our own security system, and it has never been breached in more than 15 years. Your notice is causing concern by our subscribers and is detrimental to our business."

Around the same time this post was going live, participants of this Reddit thread claimed to hack the site using what's known as a SQL injection exploit. Multiple people claimed that passwords were stored in plaintext rather than the standard practice of using cryptographic hashes. A few minutes after the insecurity first came up in the online discussion, a user reported the database was deleted. Ars has contacted the site operator for comment on the claims, but currently Ars can't confirm them. The site, http://www.oilandgasinternational.com, was displaying content as it did earlier at the time this post was being updated.

As a member of the Mozilla developer team pointed out in reply to the complaint, both Firefox and Chrome routinely issue warnings whenever users encounter a login page that's not protected by HTTPS encryption. The warnings became standard earlier this year.

The site in question appears to be completely offline at this time.

Source: ArsTechnica


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by theluggage on Wednesday March 22 2017, @01:03PM (1 child)

    by theluggage (1797) on Wednesday March 22 2017, @01:03PM (#482680)

    Ok, this is why i don't like HTTPS in general: the cert system is foundamentally broken and flawed. Not on a technical point of view (well, maybe too, but it is not my point),

    No, the requirements of the cert system are fundamentally flawed: Joe public wants to connect securely to a website they found on the interwebs. Joe public doesn't want to have to visit the website operator, verify that it really is them and collect a copy of their public key in person, then install it in their browser. Nor do banks want the cost of managing that and educating users.

    Or - put simply - doing the job properly isn't a practical option.

    Public key cryptography sounds wonderful - until you realise that unless you personally collect "Bob's public key" from Bob himself it still all comes down to trust.

    because it's basically a scam to rob money.

    Who do you expect to pay for the process of reliably confirming your identity (as a website operator)? There's a reason that the free options have very short validity (e.g. LetsEncrypt) - they have to use cheap, cheerful and, therefore, less than watertight methods of validating identity.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 0) by Anonymous Coward on Wednesday March 22 2017, @06:20PM

    by Anonymous Coward on Wednesday March 22 2017, @06:20PM (#482867)

    Ok, this is why i don't like HTTPS in general: the cert system is foundamentally broken and flawed. Not on a technical point of view (well, maybe too, but it is not my point),

    No, the requirements of the cert system are fundamentally flawed: Joe public wants to connect securely to a website they found on the interwebs. Joe public doesn't want to have to visit the website operator, verify that it really is them and collect a copy of their public key in person, then install it in their browser.

    Or - put simply - doing the job properly isn't a practical option.

    Granted, for some value of properly.
    But you can do it less improperly than allowing any CA to issue certificates for any domain. You can allow a site to present multiple certificates, so we can remove untrustworthy CAs without throwing up "unknown issuer" warnings for a substantial fraction of the internet. That's what GP was talking about -- it's fundamentally broken in ways that aren't required by practicality.

    There's a reason that the free options have very short validity (e.g. LetsEncrypt) - they have to use cheap, cheerful and, therefore, less than watertight methods of validating identity.

    No, LetsEncrypt has a short lifetime to encourage automation and discourage people managing their certificates manually, because people who manage certificates manually sooner or later let it slip.

    Paid services offer longer validity despite what I consider equivalent levels of validation; the ubiquituous "can receive email at webmaster@example.com" is no more proof of legitimate control of example.com than LetsEncrypt's "can make arbitrary files appear at specified URLs on example.com".