Re^16: Ideas for "fixing" PerlMonks 1.0

Instead of relying on my reset process you can also use a KISS approach.

First time users get an automatically generated cryptic password.

You could reuse this.

Problem is you can't overwrite the old password yet, because you can't know who requested the reset.

You'll need a page password_reset asking for the reset_password which is stored separately.

Additionally you need a timestamp and a counter to limit the numbers of requests.

Otherwise an attacker could spam a user with useless requests. (Tho he needs to know the name of the account and the email to do so)

Update

In hindsight, the code creating a new user should already have a mechanism to block spamming an email by restricting the number of attempts.

I tried to look into Create A New User, but it wasn't evident for me if that's already handled.

Cheers Rolf
_{(addicted to the Perl Programming Language :)

see Wikisyntax for the Monastery}

Comment on Re^16: Ideas for "fixing" PerlMonks 1.0

Replies are listed 'Best First'.
Re^17: Ideas for "fixing" PerlMonks 1.0 by LanX (Saint) on Dec 22, 2024 at 18:41 UTC
FWIW: I've found multiple SQL-tables with `passwd` fields like user emailpwd newuser ... and even after hours (!) of searching I wasn't able to understand the "New User" "Mail Passwd" process. And there doesn't seem to be a possibility for pmdevs to search inside dbtables nodes, so there is probably more. Hashing the passwords will require patching the core modules in the `Everything::` namespace. Especially the `opLogin()` routine and internally called subs, but also those forks generated by other gods like `loginx()` (why???) (FWIW looking into some code with 1999 security standards gave me the shills.) Even if I went on now and installed an Everything.pm fork locally on my box, "assimilated" some parts from PM to make it coherent and created a working proof of concept there is no guaranty it would be accepted. Long story short, after spending a lot of time digging inside the guts, I'm pretty sure only the gods can fix this. And only after they agreed to do so. Making this work is realistically beyond the possibilities of a pmdev Cheers Rolf _{(addicted to the Perl Programming Language :) see Wikisyntax for the Monastery} PS: I'm not applying for a promotion, even temporarily...	[reply] [d/l] [select]
Re^18: Ideas for "fixing" PerlMonks 1.0 by erzuuli (Cannon) on Dec 23, 2024 at 03:18 UTC
welcome to our world. Do you think it’s any easier for us to understand? I thank you for looking into it. I feel like you have validated our long-term collective reluctance to do anything about it.	[reply]
Re^19: Ideas for "fixing" PerlMonks 1.0 by LanX (Saint) on Dec 23, 2024 at 10:00 UTC
Risking to repeat myself: This can only be solved with a real DEV environment. As a pmdev I can only do static code analysis with one arm bound at behind my back. And any patches are directly injected into the running system, I have to be available when the gods decide to do so. That's like a doctor only allowed to scratch dead bodies to find a cure. A god can log on to the machine and access the living creature, look into the logs and run queries against the DB. A god could find out if a code-snippet is relevant or just abandoned experiment. A DEV environment would allow to fork the current engine, implement tests and run experiments. Probably best in a container. Wishful thinking, I know. Cheers Rolf _{(addicted to the Perl Programming Language :) see Wikisyntax for the Monastery}	[reply]