[Catalyst] Encrypt /Decrypt URI

[Bill Moseley]

On Fri, May 18, 2007 at 05:31:51PM +0200, Matija Grabnar wrote:
> I see another use to obfuscating **part** of the URL: when you have 
> things you don't want the users enumerating. Like where you have 
> edit-item/(itemnumber). You DON'T want itemnumber to be a global counter 
> (for instance, the autoincrement id for the item table), because then a 
> black hat may find a way
> to view other items simply by changing the item number in the URL. What 
> you want there is either an item number that is only unique within the 
> context of a given user, or an opaque identifier that doesn't make it 
> obvious what values would come before or after it.

That's interesting.  Not so much as a solution, though, more
interesting as what we think users will do.


If the user "owns" items 3,5,7 then if they put on their black hat
they might want to try item 2 or 6.  Obvious guesses.

What you are proposing is if item 7 is instead encoded as
84bc3da1b3e33a18e8d5e1bdd7a18d7a then they are less likely to try
other numbers because of, ... why?  Because it's too daunting of a task?
It's a big scary md5 instead of a primary key?

I'd think the black hat would give up after realizing that 1,2,4,6,8
don't work for them just as much as trying variations on
84bc3da1b3e33a18e8d5e1bdd7a18d7a.  And from your application's point
of view the item number 8 is just as invalid as
c30f7472766d25af1dc80b3ffc9a58c7.  So, why should your application
bother with using obfuscated ids?

As far as the user is concerned 3,5,7 are abstract ids, just like
84bc3da1b3e33a18e8d5e1bdd7a18d7a is.

Of course, what you want is a method that requires checking that the
user can access the item.  Something like:

    $item = $user->get_user_item( $id );





-- 
Bill Moseley
moseley at hank.org