Geek Answers Handbook

Best practices for handling passwords?

We have several network services and web applications that authenticate users in different ways, some with different password requirements for very bad technical reasons. For example, one system rejected the $ signs until someone “committed” string processing in some Perl scripts. Another system seems to parse @ signs in passwords. Another system gives users user passwords, and the developer proudly showed me that it was a reversible username conversion.

I understand that password hashes are preferred; but I’m wondering how much you need to donate when switching to browser-based software. For my own guidance and for the case of change, are there any authoritative links on the topic of processing and managing passwords that I can show to those in my department and responsible for other services?

+6
passwords encryption
source share
4 answers

I would recommend looking at sites like OWASP . They cover the broader topic of web application security, which, of course, is a key feature of password protection. I am sure you will find more information there.

There are also companies such as Foundstone that can teach your development team about best practices and test your existing applications.

+3
source share

The less restrictions you can impose on characters allowed in a password, the better - this increases the search space for someone trying to go too far. Ideally, there is no reason to prohibit any ASCII character (other than control characters and things like backspace / newline) in a password.

As for the length restrictions, the minimum limits are good (to the point - do not break users by setting a minimum length of 10, for example), the maximum limits are bad. If someone wants to have a 50-digit password, let them be - the repository should not be a problem while you have the hashes, because the hashes are of constant length.

Always store passwords in an inevitable hash form - ideally - cryptographically secure. There is no reason to store them in a reversible form (if someone forgets your password, just set a new password for them, do not try to "extract" it). Do not write your own hashing algorithms - most likely, you are not a specialist in cryptography, and there are many good, proven proven hashing algorithms where implementations (either in code or in the form of a library) are for just about any common language.

Salt your hashes long enough for each user to prevent a rainbow table .

Chapters 5 and 6 in Pro PHP Security conclude agreements with storage and password encryption:

Some relevant articles:

+9
source share

Setting short length limits and filtering characters are two errors that I often see that push me to the wall. Properly hashing passwords should completely eliminate the need to do this, and this can be a real pain for end users.

I generate my personal passwords using MD5 (Key + Keyword) - for example, my bank password is MD5 ("NotTelling" + "Bank"). Many sites seem to interfere with users with strong passwords, and there is no good reason for this.

Obviously, a good salty hash is the way to go.

What algorithm should be used for hash passwords in my database? has a good post on using best practice algorithms.

+2
source share

If you create a system that processes passwords, and you can use it to obtain a user password, the system is unsafe.

This is part of a more general prerequisite for security. The designer must not disturb the system.

+1
source share

More articles:


All Articles