The code i've started writing is mostly based on security, the current function's i've prepared are;
* Per user salting
* Per user encryption
* Dynamic encryption
* Dynamic salting.
Per User Salting
Per user salting is similar to a captcha, but it's a salt that is unique to the user, and is what is appended to the actual password they input, before being hashed into the tables.
Makes it a lot harder for people to spot some kind of pattern within your MD5, and makes it more resistant to Rainbow Tables, because it's not an "actual" string that is easy to guess.
Pretty secure because even if one user gets hacked, because everyone's salt is different, really, it's like cracking your customers passes one at once, because of differential patterns.
Per User/Group Encryption
Well, if you've got higher end customers, such as resellers, perhaps you would want to increase some form of security that goes to all their accounts, and sub accounts.
The idea is pretty simple, and that is that you store the user/group encryption type, and then query it before the user's login details are used. Pretty simple, but again , effective, because then there are levels of "defence" against cracking.
Again, these using dynamic salts, is pretty DARN hard to crack, even by a cryptographer's standards! Say you almost crack it.. Next day. or next logon.. completely new pattern, salt, key and hash.. Unlucky!
This would be, i guess most useful for administrator accounts. The idea is that the encryption type or hash salt, changes after each session timeout. This means that it randomly saves the encryption type for one day, or however long the session is set to die in, then it changes.
This is perfect, particularly if it's one user, because you can ensure that your password is never left there for excessive amounts of time, and left open to be started to be cracked-on, which is pretty "paranoid", i know, but it's just a thing perhaps others have.
So, with this, it means that the way your password is being hashed or encrypted is changed everyday.. Obviously, if there is a vulnerability found in one, there'll be a control panel section from which you can "disable" certain methods, until they are re-changed.
Maybe, you may be thinking - "If it's random, how will we know how to validate it?"
Well, it's not random in a way we can't control. When the admin logs on, the encryption type is selected at random, then stored in a table, where it can be queried from, if it's needed to encrypt or decrypt the password once again.. This means that yes, if you want to, you could even make it force you to log on every x minutes after your session dies, with a new encryption type once again.
I personally, have used these methods, and although the latter may be thought of as excessive for some .. For those who want the highest level of ensurance that they well be secure, this is quite adequate, indeed