what exactly are you protecting if you do this? it seems to me you are only exchanging a small number for a much bigger number, and also introducing a heavy perf cost to your query. I don't see any benefit.

The only thing I can see you gaining by using a hash of the ID is so that user 5 can't say "hm, I think I'll log on as user 6."

If you need to obscure logins, generate a session id each time they log in, and store the login credentials in the session table. You can also store a random number in the session table to prevent someone from hijacking someone else's session. (The random number really doesn't need to be bigger than 32 bits...) None of this requires any MD5 stuff. (BTW, MD5 is obsolete. Use SHA256 if possible.)

That's a great idea!

You're right: the idea is not let users know their users id's.
I'm like to add a new table and generate random integers for every session.

Thanks!
Diego.-

...and why in the world would you want to use "LIKE 'c4ca4238a0b923820dcc509a6f75849b'" anyway? Better take a few minutes and refresh yourself on the use of the LIKE operator.

I like X002548, personally

in what platform are you doing this?

Hi.

What's wrong using LIKE ?
I know it's better to use ID (it's smaller). However, the idea behind this is not to let users known their id's.

Thanks..

You didn't use any wildcards in your LIKE statement. It was equivalent to an "equals" comparison.