Printable View
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.
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 and sha1 are both options; there are others if you prefer.PHP Code:md5($_SERVER['HTTP_USER_AGENT']); //or sha1();
md5($_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDR']); //combine two values
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.
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.
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.
don't forget JSON - very convenient, cross-language, and in most cases easier/quicker thanserialize(). plus, fairly human-readable.
for your specific case, however, I think you do want a hash.
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.
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.
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.
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.
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!
If someone steals your cookie (eg, from an unsecure wifi network) then they get unlimited access, rather than just the session. That's the downside.
And sessions do use cookies, but they're a little more secure. Instead of having a direct "key" to the website (a cookie) the session is an indirect way with a cookie that just gives access to the session while that particular session exists. It's like a plastic key for getting into your car if you lock yourself out; it won't work for long, but it is fine temporarily. With the cookie method (without an expiration) it's like giving the thief a metal key that will work forever.
It's totally your choice. In fact, a lot of scripts don't use sessions (I'm not sure why not), such as forum software. But generally I'd recommend sessions. They're also easy.
And by the way, you CAN try to extend sessions if you want. You can set the session cookie for a longer expiration date, and generally that keeps the session going just as long as the cookie. (Sometimes your server might delete old session logs, but I've never been bothered by that.)
I understand the risk of creating a duplicate cookie. That sounds easy enough to do, but even if the person had the correct cookie on my website they would still need the correct $_SERVER[REMOTE_ADDR] value for the cookie to be considered valid. Both must be correct in order to gain access.
Here is an example of one of my passwords: secure7➈
I know listing my password is a little off topic, but I wanted to show that I like to use more than just letters and numbers.
That's a strong password, but the strength of a password only matters if there is no other way around it-- if stealing the cookie is enough then it won't matter what the password is.
If you are using the IP within the validation, that's very strong. The only (reasonable) way that would not be secure is if someone is using the same IP you are, such as at a public wifi location or internet cafe (where you're both behind the same router).
By the way, here are some more thoughts on why cookies are potentially problematic:
--Cookies are stored on the client's computer so they can be manipulated, such as extending the expiration date. The server keeps no record of cookies and just checks what the client claims they have, so if their cookie is modified to be extended forever, that will give them access forever.
--Cookies will relate directly to access. If sessions are used then they are an intermediate step in access so that:
1) the sessions can expire on the server and just extending the cookie's expiration won't extend the session's validity.
2) The session cookie will be random each time. A cookie that gives access directly will be the same always. So if a brute force hacking method is used, then the session method is much more secure because rather than giving the hacker infinite time to guess what cookie might work (and just try various combinations), with sessions the hacker would need to guess the right combination for the cookie within the time that that session is active on the server-- much less likely.
Remember that with any brute force attack it's possible to limit the number of login attempts for a login form, but if that login attempt is done by a cookie (claiming they are already logged in) and there is no secondary validation of the actual login process (eg, a session log), then it will be much more difficult to monitor this and deny excessive requests (eg, 25 wrong password attempts).
Finally, this is a very important point: if a brute force method is used and you do not have server log validation of some sort (eg, sessions or a database entry) and the cookie is generated by validating the IP address and the password together (eg, as a hash), then it is completely possible that given enough time the hacker can find the right combination. It will be the cookie that gives them access from THEIR IP, not yours, but that will still give them full access.
There are two ways to protect against that:
1. Create a list of approved IP addresses (including your own) that can access the site or admin part of the site. That way the hacker will never get access from another location.
2. Use a real login form with sessions or something else to show that that user really has logged in rather than just submitting a cookie that might be fake (and one of thousands of brute force attempts).
I like the idea of creating a list of approved ip addresses that are stored in my database or used in .htaccess file. For now I don't want to limit the number of login attempts so that I can continue to gather some information on the behavior of these hack attempts. I have a script that records all valid and hack attempts. Some are innocent like google crawlers. Others are sql injection attacks.
I use unicode in my passwords to greatly hinder brute force attempts. When using letters and numbers and capital letters to generate a password I get a password that is 62 to the power of the number of characters in the password. In the above example if I were to only use letters and numbers I would have to make approximately 62^8 attempts. With unicode I get 65536 to the power of the number of characters in the password, which is a considerably larger number and thus far more difficult to crack.
I do not disagree that sessions are more secure. I am leaving myself slightly open to attacks for now so that I can learn more about my attackers. For my site I do not believe it is necessary to have to log in every time I want to have admin access to my site. My site has many files that are more tailored just for myself or files that I do not feel are finished enough for public viewing. I keep sensitive information off site. I like to change my passwords every so often just to be safe. I might use sessions in the future, but not now. I feel like my site is secure enough to ward the casual hacker. If I were concerned about very sensitive or personal data I would, but even if my site were compromised or destroyed I can always upload it again to my hosting service.
That's fine-- do what you want with the site. I'm just explaining the technical details from my experience. As I've said, it's probably not realistically necessary to take every precaution (and would make your life as an admin on the site more difficult).
The one last point I want to make, though, is that you can limit login attempts and still track what the hackers are doing-- just make it a silent block. After 10 incorrect passwords, make that IP wait one hour, but don't display anything-- just pretend that every password is incorrect until that time limit is up. Or, if you find someone doing a very serious brute force attack just block that IP from gaining access (that is-- reject the password even if it's right). The hackers never need to know-- the response can read "incorrect password" and it won't hurt your ability to see how they're attacking the site. It will just protect it while you're doing that. In fact, you could make it like a true "silent alarm" and have it automatically send you an email so you can watch their hacking attempt live.
absolutely. a few more things for passwords:
1. send a unique token (a random hash, for example) in a hidden field with every login form, and save the value (sessions would come in handy here) and time to compare the submission to. This will prevent malicious users from creating their own login forms to work from, since you'll reject any form submission that doesn't match the unique value that you sent.
2. You can also have forms expire in this way; don't accept a login attempt from a form that is more than a helf-hour or so old. Likewise, don't accept login attempts that are too quick: legitimate users don't make 5 login attempts in as many seconds, so block them (silently, as Daniel suggests).