Writing Secure Code

Sin 11: Use of Weak Password-Based Systems Summary

• Do ensure that passwords are not unnecessarily snoopable over the wire when authenticating (for instance, do this by tunneling the protocol over SSL/TLS).

• Do give only a single message for failed login attempts, even when there are different reasons for failure.

• Do log failed password attempts.

• Do use a strong, salted cryptographic one-way function based on a hash for password storage.

• Do provide a secure mechanism for people who know their passwords to change them.

• Do not make it easy for customer support to reset a password over the phone.

• Do not ship with default accounts and passwords. Instead, have an initialization procedure where default account passwords get set on install or the first time the app is run.

• Do not store plaintext passwords in your backend infrastructure.

• Do not store passwords in code.

• Do not log the failed password.

• Do not allow short passwords.

• Consider using a storage algorithm like PBKDF2 that supports making the one-way hash computationally expensive.

• Consider multifactor authentication.

• Consider strong zero-knowledge password protocols that limit an attackers opportunity to perform brute-force attacks.

• Consider one-time password protocols for access from untrustworthy systems.

• Consider ensuring that passwords are strong programmatically.

• Consider recommending strategies for coming up with strong passwords.

• Consider providing automated ways of doing password resets, such as e-mailing a temporary password if a reset question is properly answered .