http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8753 --- Comment #58 from Chris Cormack <chris@bigballofwax.co.nz> --- (In reply to M. de Rooy from comment #57)
Interesting! Just some thoughts: The SQL code in the opac-recovery script will not make it pass QA. Please move it to module level (in DBIx?). Can you unit test SendPasswordRecoveryEmail?
I would not mind a mail with a library password; other info is more sensitive. If you can read/intercept the password from the mail, you can also read the unique userid for the reset password form. Same result: a hacked account. This approach is fine with me, feels more safe but is not per se safer imo.
I disagree, a token should be time based, and will require the person to set a password. This password only they will know. It's true that if someone intercepts the token and uses it to set your password for you, that is still a problem. However when you go to use the token and find out it has been used you will know this. If they intercept your password, they could use it for a bunch of time without you ever knowing. Sending passwords in the clear is a bad idea. Please do not do it. -- You are receiving this mail because: You are watching all bug changes.