Encrypted Storage Model

SSL/SSH protects data travelling from the client to the server: SSL/SSH
does not protect persistent data stored in a database. SSL is an
on-the-wire protocol.

Once an attacker gains access to your database directly (bypassing the
webserver), stored sensitive data may be exposed or misused, unless
the information is protected by the database itself. Encrypting the data
is a good way to mitigate this threat, but very few databases offer this
type of data encryption.

The easiest way to work around this problem is to first create your own
encryption package, and then use it from within your PHP scripts. PHP
can assist you in this with several extensions, such as Mcrypt and Mhash, covering a wide variety of encryption
algorithms. The script encrypts the data before inserting it into the database, and decrypts
it when retrieving. See the references for further examples of how
encryption works.

Hashing

In the case of truly hidden data, if its raw representation is not needed
(i.e. will not be displayed), hashing should be taken into consideration.
The well-known example for hashing is storing the cryptographic hash of a
password in a database, instead of the password itself.

In PHP 5.5 or newer password functions
provide a convenient way to hash sensitive data and work with these hashes.
In PHP 5.3.7+ »
password_compat library can also be used.

password_hash() is used to hash a given string using the
strongest algorithm currently available and password_verify()
checks whether the given password matches the hash stored in database.

User Contributed Notes 5 notes

I would strongly recommend using SHA-2 or better the new SHA-3 hash algorithm. MD5 is practically unusable, since there are very well working rainbow tables around the whole web. Almost the same for SHA-1. Of course you should never do a hash without salting!

I think the best way to have a salt is not to randomly generate one or store a fixed one. Often more than just a password is saved, so use the extra data. Use things like the username, signup date, user ID, anything which is saved in the same table. That way you save on space used by not storing the salt for each user.

Although your method can always be broken if the hacker gets access to your database AND your file, you can make it more difficult. Use different user data depending on random things, the code doesn't need to make sense, just produce the same result each time. For example:

This wont prevent them from reading passwords when they have both database and file access, but it will confuse them and slow them up without much more processing power required to create a random salt

It's difficult to post scripts here for all to view on the subject of best security practices. But i would wish to point out that using a salt with a randomized and odd numbered long length salt value is do_able with two Php functions while retrieving and separating the salt when it comes out using simple math functions. But with everything we add we also have to think of the constant standardized login systems we stay behind with.

For one,,, adding and validating two to four passwords is not a bad idea. Also having no username or email going in. They can be stored after the user logs in after the validation process. It is possible to store the email on the first signup and only at that time. And if the user loses his passwords then validate by email only upon request within a contact form by a validated phone number stored in the database,, and then via their email account.