The passwords of your customers are very important, not just for their own security, but for yours as well.

Abusers, spammers, fraudsters often rely on stolen accounts to commit their crimes – then they will fly away and will leave the user and the ISP dealing with the nasty effects.

If the accounts of your users can be easily cracked, they will be; and your servers will then be used for spamming and phishing. As a reaction, many other providers around the world will blacklist your servers, making it impossible for your services to work reliably, and greatly damaging your business. This is why the security of your users is not just their problem, but your problem as well.

Users must be required to pick secure passwords, at least 8 characters long and including at least one character category (possibly more) among capital letters, punctuation signs and numbers; they should be prevented from picking dictionary words or trivial passwords such as “123456”, “password” and “qwerty”, and from using their own name, city or birthday as a password. Traditional best practices also say that users should be required to change their password every 3-12 months – however, recent studies showed that this makes users pick weaker passwords and write them down, so you would rather have longer expiration terms or no forced expiration at all.

Users should be informed of your password policy and should be able to pick their password freely under these requirements, but they should not be able to re-use a previous password. There are discording opinions on what constitutes a good password policy, as requiring users to adopt passwords that are too difficult to remember, or to change them too often, will actually lead them to write them down somewhere and make them less secure. However, some effort has to be required on their part!

But it is useless to require users to adopt strong passwords, if the provider does not store them in a secure manner. And, to start:

Password should never, never, never ever be stored in plain text.

Still today, some ISPs and websites store user passwords in clear, because this allows their customer care to “send the password back” to the user that has forgotten it. This is an extremely dangerous practice, possibly illegal in several countries, as any intruder – but also, many ISP employees and system administrators – can have access to thousands, maybe millions of cleartext passwords at a time.

To deal with users forgetting their password, the correct way is to provide a password reset form that will automatically send a new temporary password/code or a link to create a new password to the email address used at registration, or via SMS to a mobile phone number provided in the past. To this purpose, you may ask users to provide their mobile phone number and/or an alternate email address at registration.

If you send a temporary password, then it must be forcibly changed at its first usage, to prevent intruders from logging in by peeking at the message in the future; in general, you should never send password reminders with a permanent cleartext password by email, even at registration, but just rely on the password reset mechanism.

You should store user passwords with a secure one-way encryption method, avoiding easy hashes such as MD5 or SHA1. The more secure the better, because an intruder may still enter your systems and get hold of a huge set of encrypted passwords, and then try to attack them by brute force.

Also, if you want to increase security, you should provide to your users a form of two-factor authentication – a login method in which users do not just provide their password, but also have to prove their identity in a second way using another device or account. For example, if you ask for a mobile phone number, after the user enters the password you may send an SMS with a verification code to that number and ask him to enter the code as well, so that an intruder would have to know the password and get hold of the user’s phone; or, you can provide users with an app or a small device that generates codes (see RFC 6238 for a standard algorithm to generate one-time verification codes). Nowadays this is not still general practice for average logins, though it is widely used by banks and as an extra requirement for sensible operations, but this may actually become common practice in the near future.