Add that to a database table which maps the token to the userid, and then send it to the client in the cookie. When the user logs in, generate a large (128 to 256 bit) random token. The better way is to never let a user's information leave the server, except for the id. That line of thinking has a name: Security Through Obscurity, which should NEVER be relied upon. In short, the only thing protecting you is the salt, which isn't really protecting you as much as you think.Īll of that was predicated that the attacker knows the algorithm! If it's secret and confusing, then you're safe, right? WRONG. And unless you use sufficient randomness in it (make it large enough), it's going to fall quickly, and with it the keys to your castle. But modern day GPUs are exceedingly good at it.
Now, all an attacker needs to do is brute force the "salt" (which isn't really a salt, but more on that later), and he can now generate all the fake tokens he wants with any username for his IP address! But brute-forcing a salt is hard, right? Absolutely. Let's also imagine for a second that they know the algorithm that you used. You see a cryptographic cookie set for the remember-me on your session. Imagine for a second that you're an attacker. What's wrong with hashing user data, you ask? Well, it comes down to exposure surface and security through obscurity.
OK, let me put this bluntly: if you're putting user data, or anything derived from user data into a cookie for this purpose, you're doing something wrong.
0 kommentar(er)
