how do you hash a word

[james438]

This is almost a request for a script, but If I were to pull a small amount of data from the database and wanted to store it in a cookie, such as the combined and stored $_SERVER[HTTP_USER_AGENT] and username for use in a persistent login how would I convert that into a hash value?

As I understand this a hash is a variation of converting text to hexadecimal format, but with a few differences.

[djr33]

Except in the case of files (for which there are special functions in some cases), you need a string. Then that can very easily be converted into a hash string.

For example:

md5($_SERVER['HTTP_USER_AGENT']); //or sha1();
md5($_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDR']); //combine two values 

md5 and sha1 are both options; there are others if you prefer.

The only complication will be figuring out what identifying information you want to store in the string. If it's just the user agent string, then that's easy. If you want just part of that, you'll need to figure out how to split it into pieces. If you want to combine it with something else, then just concatenate them and be sure to always do it in the same order. Since you're making it into a hash string anyway, there is no need to worry about readability-- you just need to concatenate the info in the same order each time and that will give you an identifier.

[james438]

I think that is all I need, thanks

I was going to ask how to decode that, but I don't see the need to do that right now.

[djr33]

You can't ever decode a hashed string. It's one way encryption. (In fact, it's not "encryption" in a technical sense.)
Because the odds of accidentally arriving at the same output are so low, it's a way to generate a unique identifier (for all practical purposes, anyway).

So, rather than storing the original data (eg, sensitive information, or too much information to conveniently store such as a full file), you store the hash and can still use it to verify information later. Here's how:

Compare two hash strings. If they match, then the input matched. This can tell you that the file you've just downloaded is the same as the target, or it can tell you that the password just sent in the login form is the same as the original password used by the user. But you never need to store the original data in the raw form. And in fact, you can't ever actually determine what that data was-- you can just verify that the user input the correct form to get a match.

In your case, you'd just be matching up users based on whether they have the same hash string, so you could know if they're the same as someone from before.


If you're not using this for security purposes and you need to be able to decrypt it, then hashing the information is the wrong way to do it. Instead, you should either store it in its raw for or use base64_encode() and base64_decode() to store the information in a convenient way. You can also use serialize() and unserialize() to store non-strings (such as arrays) as strings if you need to do that.

[traq]

don't forget JSON - very convenient, cross-language, and in most cases easier/quicker than serialize(). plus, fairly human-readable.

for your specific case, however, I think you do want a hash.

[james438]

Just wanted to add that I have finally updated my cookies so that the password is not stored in plain text. I now use two different hashed values. I am now looking into better file permission practices.

[djr33]

And by the way, I thought of a clearer way to explain hashing and why it's not reversible: it's like a footprint or a fingerprint-- you can match it to the thing that made it, but you can't actually figure out what made it just by looking at it. With a database you can find the person whose fingerprint you found, or figure out what animal made a footprint. And in fact that's the only way to "hack" a hashed value-- create a database with all (many) possible inputs, and then find out which one matches the output you've got.

That's good that you're storing the cookie that way. It's still not totally secure because your hashed value could be used (if put into someone else's cookie) to gain access.

Using sessions is the most secure way. It's possible to hijack a session by stealing the session ID cookie, but you can actually prevent that by verifying the IP address. In most cases, that isn't done, but it's one way. And you never store the password (in any form) client side. So even if the session is stolen it's one-time access. By requiring a password entry to change the password, the account is secure except for that one-time issue.

If you want to know how to limit sessions by IP, I can explain that. It's actually very simple. There are two options:
1. If you're using a hashed value (eg, password) then include the IP in that, such as: hash($ip.$pw). Then you can't verify the password except by using the IP, then just make sure the requesting IP matches (by using the same pw+ip combination), and it's secure.
2. If you're using sessions, then store the IP as a session variable. If the incoming request IP ever differs, log the user out (destroy the session, start over).

The only downside to that is that users who have laptops or mobile devices and might log on from different places during the same session (taking the laptop to work and still expecting to be logged in) will have to log in again. It's a little annoying, but it's very secure.

[james438]

I am more interested in being logged in for longer periods than one session, which is why I have moved away from sessions. My hashed cookie could be duplicated, but if it is they would also have to have the correct ip address, which fewer people know how to fake let alone know which ip address to imitate.

This is designed for the admin so that only one person can be logged in at a computer at any given time.

[traq]

you'd still do well to use sessions - just use the cookie to start a new session without requiring the user to log in. For admin accounts, however, it's best to make it impossible to stay logged in for longer than a single session (and put a concrete time limit on it as well). I know it's less convenient, but persistent logins are an inherent security risk.

[james438]

It sounds like using a cookie to start a new session so as to avoid logging in has the same security risks as using just a cookie, sort of like what I do right now. The only security risk that I can think of at the moment with persistent log ins of an admin would be me leaving my computer ad someone else using it.

The main problem with using sessions is the frequency with which I close my browser and open it again. Logging in as admin at that point just becomes somewhat bothersome even though I am sure it would be more secure.

On a side note I think I know how the hacker was able to change his ip address from Germany to the UK with hardly any effort. My thought is he has a few hacked websites already whose servers reside in the UK and Germany and used those websites to mask his ip address. Considering certain past methods used to hack my site this makes sense.

I kinda take it for granted that people will try to attack my site every so often. I can't imagine why though.

I definitely want to thank you two for your help and advice as I try to beef up my website security!