For passwords, my method is individually salted and one way hash will eliminate most attempts, pretty much leaving brute forcing the most efficient way. However, it's known that people use common passwords like 'password1'. For more paranoid security, read documentation, discussions and even black discussions regarding the technology you use if you really want to lock down everything. Eventually it'll be a performance/usability vs security compromise in some cases.

I suggest a failure plan to prepare for security failures including several PR messages depending on severity of failure even if you do not know if you're compromised.

It's highly unlikely that you will be able to avoid potential leaks.

Hashed password are pretty obvious, but what if your app needs to talk with something that needs original password (database, external system of some sort)?

I guess, as always, there is no silver bullet.

If you are using something like app -> db calls to be done automatically on a server, hashed passwords won't help since the script usually requires a stored non-hashed key unless it accepts hashed keys. Even then, if the password or hashed password is exposed, the hacker can still use it to access the database via your app.

Maybe you want decentralised permissions of multiple database users? They can't quite get or do most things.

Or centralised and/or put into a locked down file that can only be accessed by the OS user for parsing scripts eg www-data.

More references:

http://technet.microsoft.com/en-us/library/cc722487.aspx#EIA...

http://us.php.net/manual/en/security.php (Or check your relevant manual)

http://blogs.forbes.com/firewall/2010/12/13/the-lessons-of-g...

http://stackoverflow.com/questions/3173698/how-safe-is-code-...