问题
We have a number of network services and web-apps authenticating users differently, some with different password requirements for very bad technical reasons. For example, one system refused $ signs until someone "fixed" the string handling in some Perl scripts. Another system appears to parse @ signs in passwords. Another system issues users passwords to them, and the developer was proud to show me that it was a reversible transformation of the username.
I understand that password hashes are preferred; but I wonder how much must necessarily be sacrificed in the transition to browser based software. For my own edification, and to make a case for change, are there authoritative references on the subject of password handling and management that I can show those in my department and those responsible for other services?
回答1:
I would recommend looking at sites like OWASP. They deal with the broader topic of web application security, which of course password protection is a key feature. Im sure you'll find more information there.
There are also companies like Foundstone that can teach your development team about best practices and audit your existing applications.
回答2:
The fewer restrictions you can put on what characters are allowed in a password, the better - it increases the search space for someone attempting to brute-force. Ideally, there's no reason to disallow any ASCII character (aside from control characters and things like backspace/newline) within a password.
As far as length limits go, minimum limits are good (to a point - don't piss off your users by setting a minimum length of 10, for instance), maximum limits are bad. If someone wants to have a 50-character password, let them - storage shouldn't be an issue as long as you're hashing, since the hashes are of constant length.
Always store passwords in a non-reversible hash form - ideally, a cryptographically-secure one. There's no reason to store them in a reversible form (if someone forgets their password, just set a new password for them, don't try to "retrieve" it). Don't write your own hashing algorithms - chances are you're not a cryptography expert, and there are plenty of good, proven hashing algorithms out there with implementations (either in code or library form) for just about any mainstream language.
Salt your hashes with a per-user salt of sufficient length to prevent rainbow table cracking.
Chapters 5 & 6 in Pro PHP Security deal with storage and encryption of passwords:
- http://books.google.com/books?id=lVXnmsCCd3wC&lpg=PP1&pg=PA55#v=onepage&q=&f=false
Some relevant articles:
- http://www.codinghorror.com/blog/archives/000953.html
- http://securityratty.com/article/41ae895330526916b45e20f6b71dd8cc
- http://www.ibm.com/developerworks/opensource/library/os-php-encrypt/?S_TACT=105AGX01&S_CMP=LP
回答3:
Setting short length limits and filtering characters are two mistakes I see frequently that drive me up the wall. Hashing passwords properly should completely eliminate the need to do this and it can be a real pain for end users.
I generate my personal passwords with MD5(Key + Keyword) - for example my bank password is MD5("NotTelling" + "Bank"). A lot of sites seem to thwart users with strong passwords and there is never a good reason for it.
Obviously a good salted hash is the way to go.
What algorithm should I use to hash passwords into my database? has a good post on the best practice algorithms to use.
回答4:
If you design a system which handles passwords, and you can use it to acquire a user's password, then the system is not secure.
This is part of a more general necessary condition for security: The designer should not be able to break the system.
来源：https://stackoverflow.com/questions/1246463/password-handling-best-practices