views:

109

answers:

3

I was listening to the stackoverflow podcast (i think it was episode 52). Jeff was talking how they came up with some type of authorization mechanism where they were encrypting credentials in the cookie they sent to the client. Apparently someone Jeff knows was able to find a hole in this and was able to login with anyones id that he wanted to.

He didn't go into a whole lot of detail in the podcast but it sparked my interest. I am one of those people that would assume if your encrypting your cookie information then they couldn't be any vulnerabilities. Did anyone listen to that episode and/or know what the possible hole that you would open with this solution?

thanks Ncage

+1  A: 

If you're passing encrypted information to the client then there is always a chance that they'll be able to decrypt it (maybe due to weaknesses in the encryption algorithm used, or lack of salt leading to analysis attacks or various other possible problems).

So, you shouldn't send the client information you can avoid sending.

Ideally, you just send them a random ID which you use to look up in a sessions table, and keep all the data server-side. Then the "only" way a user can become a different user is to guess a (very long and random) session ID.

Legooolas
+2  A: 

In my implementation I use random string (16 bytes) followed by the important information. The whole thing is then encrypted with AES using cyclic block chaining.

This avoids the need to store the information in a session state or to get it from a database. Anyway, it's no super high security site, but I think that adding the random string and CBC improve security quite a bit.

chris166
+1  A: 

May be you can check this blog post, it explains a lot of thing you did not think of, and why encryption is not authentication. In fact you should not come with your own solution, but try to use a proved one.

shodanex