Joel,
Just a few comments for consideration.
Firstly, there was a brief chat on IRC the other day about ways to reduce the possibility of a DoS attack (https://openacs.org/irc/log/2005-06-16 time window 20:50 until 21:17). There were some good suggestions - worth looking at.
Secondly, my bank uses a good system for entering passwords which is that it never asks for the whole password, just a selection of letters from it. This defeats packet sniffers (unless they wait for an awful lot of logins!), and ensures that the password remains secure(ish) even on unencrypted connections.
Thirdly, I'd like to refer you to my suggestion of an increasing timer delay after say 15 login attempts in quick succession. We could extend this to cover the re-issue password request such that if 're-issue my password' is requested more than say 20 times in say 10 seconds (or any other time considered appropriate), the system identifies this as a potential attack and introduces a timed delay to the page. I suggested that we could modify the developer support log sweep to include a multiple login detection check.
I would support any means of streamlining the process, but I would be wary of stripping stuff out without very careful discussion because there will probably be a 'Doh!' factor associated with doing that. "Oh yes! THAT'S why they did it like that!!!" 😊
Personally I quite like the question and answer thing for re-issuing passwords (because it is convenient) but I do think that we should block the DoS vulberability that it could represent. I also think that we should preserve the behaviour where the email that goes out has a magic url that takes the user immediately to a login and forces them to change their password to one that has not just crossed the ether unencrypted!
I hope these comments are helpful.
Richard
