Hello, I'd add the following to the list below:
G) Notification to multiple email addresses (pre-specified) and even by phone should occur when a password reset is made (makes it harder for an attacker to cover their tracks). H) An account that makes a password reset should be monitored for unusual activity (e.g. a big increase in outgoing transfers, removals of domain locks, changes in nameservers, etc.), or a spike in general activity. Sincerely, George Kirikos http://www.kirikos.com/ --- Adam Selene <[EMAIL PROTECTED]> wrote: > A) Passwords should be stored as an MD5 or an SHA1 hash -- and > ideally hashed > with some other identifier (such as a User ID) to frustrate bulk > password/hash > match. > > B) A password reset request should generate and send via email a > temporary > password with a short expiration. > > C) Login with temporary password should require a new password to be > chosen. > > D) Not until this new password is chosen, should the original old > password be > removed. Generation of a temporary password should not remove or > prevent log in > under the old password. > > E) (Optional) Add ability to disable reset password feature and/or > store PGP > email keys for sending encrypted email. > > F) All account authentication events (login success/login > failure/password > reset/change password) should log IP address (and user agent string > if > web-based). > > This is all pretty standard, but it's amazing the sites that screw it > up.
