You'll get a monolithic block of code and you'll have to take over maintenance.

Reasonable and normal (for better or worse).

Do code nodes have a size limit?

See htmlcode. It's a MySQL text field. So... I don't know. It's going to be 64kb at least?

please have a plan how to migrate to hashed keywords

At this point you probably understand how it all works as well as I do. Do you have a plan?

mail template in Password Mail doesn't look like HTML emails are supported tho...

You're right. That's unfortunate. OTOH, we can just copy the code of node2mail and make an htmlcode to use instead. Then we can add MIME types and whatever else.

> Do you have a plan?

No, I don't.

Probably ...

You can add a column "hashed_password" as a shadow to the right table, and hash all "plain_password" and gradually double all password write and reads in the code.

At the end delete or rename the plain_password field and "deactivate" all code referencing it. ¹

But that's something you gods must discuss!

Cheers Rolf
_{(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery}

Update

¹) I'd probably encapsulate all this in two custom functions "store_password" and "check_password" which are ruled by a global switch.

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}

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...