Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Monastery login over http

by bliako (Prior)
on Apr 24, 2018 at 17:32 UTC ( #1213488=monkdiscuss: print w/replies, xml ) Need Help??

Hi Monks, again,

I am on an insecure and nosy (not noisy, nosy) connection and have realised that my password was just POSTed cleartext over to the Monastery. Understandably (firefox warns about that). I changed it using the link. Though Jesus knows all the passwords. Obviously.

However, I am wondering...

I realise the increased computational burden of SSL on the Monastery's bit-pushing apparatus. And I am quite pragmatic as to what who gains my password can do with it ... Nothing really apart from flaggellating a fellow Monk or posting inefficient and buggy codes ...

So, what's the norm?

Personally, I would be comfortable with a middle way where the login form is send over SSL and then once successfully logged in it downgrades back to http. After that all sessions, posts etc are over http. Now what good that be? They can steal your cookie (I read in a past node). Yes sure, but still they do not have the password (**which one may share across many sites** - always pragmatically speaking) and the computational burden on the Monastery servers is kept low.

Please notice that downgrading back to http (after logging in via https) has to be done manually (as far as I can see), i.e. change browser's url to http a mano. So it is an incovenience on the digital fastlane.

So, question is: should I use https over all my transactions after I log in and forget about manual changing https to http? Or log in via https and then manually go to http for reading/posting (accepting the risks associated with it but who cares)? However, logging in via http is not going to happen for me anymore. I hate gloating script kids.

Edit: what about changing perlmonks' login form's names for username and password to something like a and b. And the login url to something less revealing? Just a thought.

Replies are listed 'Best First'.
Re: Monastery login over http
by marto (Cardinal) on Apr 24, 2018 at 18:07 UTC

      Noted. But I did not encounter the problem in there. Perlmonks https works fine for me just now.

      Maybe have the login form sent to client with added hidden field:


      Login form encrypts password on client-side using said key and all perlmonks' server has to do (wrt computational burden) is decrypt it. I think user passing his encrypted pass (by private key) was mentioned also here: We blame tye.

      Please note, I realise that these are no real solutions (e.g. against man-in-the-middle) which cost zero and that I am very far away from being an expert in security. I am just trying to work out a way where passwords are not sent cleartext with minimal cost to perlmonks (wrt effort, cpu, money) and some real effort on the snooper's side to gain the password (which is not that important anyway).

      I would hate my pub-lan-provider having a script saying

      if( $bytes =~ /username=(.+?)&password=(.+?)/ ){ store_in_db_and_then_ +sell_to_usual_suspects($1,$2) && cash_out_money() && advertise_charit +y_donations() && sponsor_666_politician() && go_to_parliament_for_que +stioning() }

        When both webservers have the certificates then IIRC the plan is for everything to be over https.

Re: Monastery login over http
by marto (Cardinal) on Apr 25, 2018 at 12:00 UTC

    "which one may share across many sites"

    This should never be the case, people should not reuse passwords, which isn't to say this doesn't happen, but in the modern world with the tools available there's no sane reason for this.

    In the interests of security there's no reason not to run the site (or any site) over https. Awareness of security is a big issue, always has been, and the general public are being made more aware, either by changes in applications (browsers warning them) or data breaches, well publicised hardware and software vulnerabilities, network shenanigans...

    Tools and services exist to make this easier for users and administrators, (e.g. lets enrcypt/https everywhere). Even this doesn't seem to be enough. As long as go as yesterday, for a couple of hours, people ignored the big https error message, logged into what looked like their myetherwallet wallet anyway, resulting in a heist:

    "Victims had to click through a HTTPS error message, as the fake was using an untrusted TLS/SSL certificate. The bandits have amassed $17m in Ethereum in their own wallet over time."

    Another BGP hijack. You say you don't trust the networks you use, I know people who run their own VPN servers, exclusively for their own use, and route all their traffic over this, regardless of device or where they are, and even this doesn't protect from everything, as this example shows.

    When do you stop? Hardware? At the moment, realistically a 'blobless' ARM based system is likely your best bet, but it's not a realistic option for most people at the right now.

    Anyway, hammers are still pretty cheap.

      (Web) technology can not solve the fundamental problem of trust. With hierarchical chain of certificates (control), one would have to tacitly assume the custodians have your best interests in mind.

        You seem to be asserting that secure communication online (and perhaps everywhere) is literally impossible and only appears to function through goodwill. Or do I misunderstand?

        A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Monastery login over http
by merlyn (Sage) on May 24, 2018 at 21:11 UTC
    What's even scarier is that at one point, your perlmonks password was stored in cleartext in the database (not hashed), and there was a breach (this was like a decade ago).

    -- Randal L. Schwartz, Perl hacker

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

      > at one point, your perlmonks password was stored in cleartext in the database

      AFAIK this is still the case, try to get a hashed password mailed to you.

      still the case...
      Hey there.
      You or someone else has requested a password for your username or e-mail address. Before you freak out, take a few deep breaths and remember that it's YOU and not THEM who is getting this password.

      Here's your info:

      username: merlyn passwd: LanXRulez human name: Randal L. Schwartz

      love, the management

      Cheers Rolf
      (addicted to the Perl Programming Language and ☆☆☆☆ :)
      Wikisyntax for the Monastery

      Doesn't scare me in the slightest and never did. The site doesn't have my social security or any banking or credit or non-public personal info or keychain access or certs to anywhere and does not represent any security threat at all unless I use the same credentials and password elsewhere. I've done a lot of stupid things in my day but not that one. Though I was able to skate on a five letter dictionary word as my password for a few years… :P

        The best strategy here is a generated cryptic password.

        I don't need it to be easily remembered as long as I can get it mailed.

        Cheers Rolf
        (addicted to the Perl Programming Language and ☆☆☆☆ :)
        Wikisyntax for the Monastery

      there was a breach

      What happened?

      your perlmonks password was stored in cleartext in the database (not hashed)

      And it still is, almost 9 years later. Anger Management


      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: monkdiscuss [id://1213488]
Approved by haukex
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (4)
As of 2020-09-28 08:34 GMT
Find Nodes?
    Voting Booth?
    If at first I donít succeed, I Ö

    Results (143 votes). Check out past polls.