Ok... The idea was was to make a Sha512 hash from the User ID, User Created date, Password & Computer Name. When a user have the "Remember" activated and return to the site, the server will get information from user's cookies regarding only the UserID and the 64 digit Hash. The Computer Name would also be fetched. The rest of the information is contained inside the server's SQL DB and will be used as elements to recreate the very same hash and compare it to the one that's stored on the user's computer. If they are same, the user is then the genuine user.
I think I understand the problem: conceptually, you are working with the idea that "Cookies can be hijacked". This is true in a way, but it implies that the attacker has control over the user's computer (e.g., the attacker took over the computer from a user at an Internet cafe who forgot to log out) to read the cookie file(s).
I am working on the assumption that you are concerned with an attacker sniffing the network. This attacker knows the data that is sent and received by the computer. So, if you send the user id, hash and computer name in the clear, the attacker can get all these and use them. It does not matter that the user id and hash were stored in cookies and the computer name was retrieved via some other way. The system would still be inherently insecure against interception of the data.
Well, that was the idea anyway. I don't know how this is solved IRL today on websites around the world. Maybe there are lots of solutions to it.
The solution is to use SSL/TLS, or an equivalent. In truth, many authentication systems deployed on websites assume that an attacker will not intercept the network data. Only those websites that really need to be secure (e.g., those that involve financial transactions) would use SSL/TLS.
