You'll get a monolithic block of code and since I can't debug PM you'll have to take over maintenance. (Do code nodes have a size limit?)

I'll think about it and will come back to you next year after I'm back from holidays.

In the meantime please have a plan how to migrate to hashed keywords afterwards, otherwise it's all in vain.

> Please give me a link to the patch and discussion.

See Re^7: Ideas for "fixing" PerlMonks 1.0 Point number 3 links to the patch.

The full discussion is in the thread

> I'm not sure if EE has functionality to receive email. Will that be needed?

No, only sending an email with a an encoded link to start the password reset.

The mail template in Password Mail doesn't look like HTML emails are supported tho, which means we need to rely on mail clients making links in plaintext clickable by heuristics.

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.

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

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