This bothers me: > The database also contained passwords, which were stored as an MD5 hash, a long-outdated algorithm that is nowadays easy to crack. Many of the passwords were easily unscrambled using readily available tools when we tried. That's not how hash functions work... > Kim denied this. “We don’t use MD5 for our passwords to store them,” he said. “The MD5 keys were a log and it does not represent how we are…
> That's not how hash functions work... Kind of. A hash function just provides a near random set of characters of fixed length for a given set of input in a way where the output characters are reproducible for the given input. Passwords are not stored. It is the computed hash value that is stored. When a user attempts to login with a username and password the password is hashed and compared to the stored hash. That s…
And for what it's worth:
> To be secure the salt must be stored in a different location from the stored hashes and the salt value should not be statically visible in the source code provided a source code compromise.
This isn't true. Your salt can be totally public if you're using a robust key derivation function. Likewise you can make e.g. the work factor (rounds) public for bcrypt and N, r and p public for scrypt (cost factor, block size and parallelization parameters).
The rest of what you said about secrets management in code is sound though.