> Was your original signup https? No? Then [...] Sounds like a good reason to use HTTPS for registration and authentication, as stated in the article. > Would

> Was your original signup https? No? Then [...] Sounds like a good reason to use HTTPS for registration and authentication, as stated in the article. > Would you happily login to your account from the WiFi at Starbucks Sure, as long as the site uses HTTPS. > or from the public machine at the local library? Never, never, never. > Emailing passwords to new users is USEFUL [...] Allowing anybody to login without a password would doubtless save them even more support requests, but that doesn't mean it's a good idea. Sometimes the developer's responsibility to protect a user's information outweighs a desire for lower support costs. > ANY ability to reset a password via email is insecure. [...] Not so; additional information, such as user-defined security questions or verification, is usually required before a user is allowed to reset their password. Furthermore, a theoretical weak reset procedure only exposes the weak site. It doesn't expose the user's password. > An attacker which can read out the passwords from your database already owns your site. This isn't about protecting your site, it's about protecting users. Many people, despite decades of warnings, use the same password on multiple sites. If your site stores the user's authentication information in a way that can be accessed later, then you are violating the user's security.