in reply to Ideas for "fixing" PerlMonks 1.0

Are passwords still stored as plaintext?

It is — unfortunately — no secret that pm stores its passwords in plaintext. There has been plenty of discussion about this. We won't rehash it here.

Is security by obscurity really considered a valuable defence against ze baddies

I'm not talking about security — as in, preventing accounts or the site as a whole from being hacked, or personal data getting exfiltrated — so much as not revealing how the sausage gets made. The admins do quite a bit to detect scammers and stymie trolls. We don't, for example, want you to know whom we have blocked, or how.

If the system for this site requires changing to achieve that, then it should be done.

I don't disagree. But, as has been mentioned many times, this system is very hard to change. It would be not only easier, but more advantageous in the long run, to build a new system from scratch, where everything is done The Right Way.

I am willing to put effort into that myself.

I appreciate that, and am grateful indeed.

Today's latest and greatest software contains tomorrow's zero day exploits.

Replies are listed 'Best First'.
Re^2: Ideas for "fixing" PerlMonks 1.0
by etj (Priest) on Dec 17, 2024 at 10:14 UTC
    Less, let's say, humorously: I note the recent attempt by Bod to discuss the elephant in the room (the password problem), at Priorities perhaps?.

    Having just re-read it, I see what I believe is a way to cut the Gordian knot. It could feel like a large, atomic change is needed to both encrypt the passwords, and put in place the workflow needed to do password resets that would be needed because the plaintext isn't available anymore.

    But what about making a workflow for password resets now, even though the passwords are still plaintext in the database? It would both set the conditions for then encrypting the passwords as a second, independent step, and already increase security a bit by not having plaintext passwords be emailed around, and sit in people's mailboxes for ze baddies to snarf up.

[reply]
[reply]
        I see it got successfully bikeshedded into the ditch. Services that offer single-sign-on (SSO) options usually also offer a username/password option, so SSO is not a solution to this problem. You'd still need a password-reset capability.

        jdporter - what would it take to make password resets change from the current (email out the plaintext password) to sending out a password-reset link, in the PerlMonks codebase? Is it as simple as an additional SQL table "password_reset" with columns UID, one_time_key, time_requested, and a page that takes the first two as CGI params, asks for a new password, submitting to a second page that takes those 3 values and updates the database by updating the password and deleting the password_reset row? (The time_requested is so it can be cleaned up periodically)

        cavac - how does PageCamel do this?

[reply]
Re^2: Ideas for "fixing" PerlMonks 1.0
by etj (Priest) on Dec 17, 2024 at 10:01 UTC
    pm stores its passwords in plaintext. There has been plenty of discussion about this. We won't rehash it here.
    I see what you did there.
[reply]
Re^2: Ideas for "fixing" PerlMonks 1.0
by NERDVANA (Priest) on Dec 19, 2024 at 02:52 UTC
    pm stores its passwords in plaintext. We won't rehash it here.

    Pun intended?

    (and now I see etj made the same comment, and I would delete this post if PM had that capability...)

[reply]

In Section Perl Monks Discussion