see. It makes more sense to write your SQL to check for that. So for
example, if the user's "Level" is 0, and the DB record has a level of 1, and
the logic is the user's level must be equal or higher, then your SQL should
check for it.
That way, if I break your encryption, I don't get anything.
I'm not saying don't encrypt - just FIRST make your code rock solid, then
add junk to "slow down" the script kiddies.
>
> If the ID is 114, chances are good that 115 is going to be
> valid, and possible do something you shouldn't be doing
> (though that should be secured through other means). However
> if the URL is a UUID, md5 hash, or whatever, the odds of
> changing it to a valid number is much smaller, as there will
> be gaps in the series. It doesn't make the app any simpler,
> but it does accomplish something.
>
> barneyb
>
> > -----Original Message-----
> > From: Raymond Camden [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, December 09, 2003 1:08 PM
> > To: CF-Talk
> > Subject: RE: Another simple question...
> >
> > But even if you encrypt it, someone can still change it. If
> your logic
> > correctly handles missing and bad ID values, what is the point of
> > encrypting it?
> >
> >
> >
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
