Indie-Resource.com

There's a lot of discussions floating around the internet about md5 having been cracked, and sha1 as well. So far, the best way I've found to encrypt passwords is using a salt, which is a 32 character encryption key, containing lower-case, upper-case and numbers. (no symbols) Then hash the password using SHA1 with the defined encryption key(NOTE: SHA1 will create a 40 character string, where md5 creates a 32 character string, make sure the password field in your database is varchar(40))

For added security in your PHP applications, try creating a config file (for this example we'll name it encrypt.config.php) with the salt value like: Remember, the salt value needs to be 32 characters long.

Okay now we can include it in a helper file, let's call it encrypt.helper.php: I'm using this code slightly differently in my application, but this generic example can be easily modified to suit your needs!

Woops, forgot to include an example of usage: You'll see that it generated a 40 character string that is virtually non-readable.

Also, you should note, that the reason this is so secure, is that it is virtually non-breakable unless the cracker has your salt value. Happy coding!

They are 'cracked' it is still a waste of time to actually take advantage of anything of relatively decent strength. But yes, for extra security you should always use a salt, it takes no effort really.

Most inner data won't be exposed from someone figuring out their hashes, but from just generally sloppy coding or a virus attaching to their ftp programs config files.

Maybe I should write some tutorials on xss filtering, and other security functions

When you say cracked, do you mean that every possible hash has been solved?

The problem with using a universal salt is that an admin could look at the salt, generate a hash list (a list of every possible hash result and the seed), and then with access to the database, compromise the accounts.

What I do is add a new salt column to the table where the passwords are stored and generate a random salt. That way, security is improved a lot as an admin will have to do as many hash lists as there are salt combinations.

ita Stet.

I don't understand what you mean by an admin may be able to gain access to the salt? I mean, if it is stored in a PHP file, and you have a defined constant so that there is no direct access to the file, you'd have to provide someone direct access to that directory on the server for them to find the salt, which would mean they are probably an employee or affiliate of some kind (and hopefully trustworthy enough not to compromise security).

I could be wrong though. I'm by no means an expert on security. But as far as I understood it, a salt, combined with xss filtering, server side data validation, and escaping strings before inserting data into a database provides a pretty decent level of security, in exchange for not too much work.

Anyway, all this prompted me to read up on this, and I've found some interesting articles. Most suggest to actually use bcrypt, which is included in the 'crypt' function in php 5.3

I'm not sure, but I'll keep reading and let yall know what I find.

Considering how everyone wants to work writing their own Ajax XSS filtering would be immensely helpful to these guys.

I saw a few places where Capital letters couldn't be encrypted with md5 and sha1 to stay case sensitive? Can someone explain how this works for me as it is also a concern among the stuff I am making. Thanks for this tutorial as well!

No, as far as I know sha1 and md5 both create a completely different hash when one character in a word is different. So they are both case-sensitive.

There have been cases where employees, mods, etc. have basically tried to hack/access other peoples accounts. The salt limits this threat.

But then again, assuming they have the privileges, they could just alter the MySQL database.

I usually don't worry about security. I am just interested in cryptography.

ita Stet.