[Catalyst] Encrypt /Decrypt URI

[Bill Moseley]

On Fri, May 18, 2007 at 07:55:35PM +0200, Matija Grabnar wrote:
> Bill Moseley wrote:
> >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?
> >

> Well, in a way. Because the space they need to search to find the "next" 
> item in a md5 or similar scheme is many orders of magnitude larger than 
> in a system where the numbers are consecutive  (i.e. o(1)).

Last time I checked there were an infinite of integers.  (And I'm not
planning on counting them again.)

The black hat can try /item/8 and /item/329191810201811821092 and they
both are equally invalid.  There's no "next" item to find.  Trying
different integers and different md5 keys require the same number of
steps with exactly the same result -- they can only see items they
own.

Now, a *human* might perceive that trying integers might be more likely
to work than trying random md5 sums.  So, you might have more 404
errors on your server than if you use md5 sums, but your security is
no better.


Using md5s for images, as in your example, is fine.  But if the images
really needed to be protected then that scheme is purely security by
obscurity.  That's what we were talking about -- the case where some
user might type in the next sequence and see someone else's data.  If
the images belonged to users you would probably want to make sure the
request is authorized to view the image instead of relying on just
obscuring the url.

Adding layers of security are fine -- but you have to be careful that
the added complexity doesn't also make it easier to leave open a hole.


-- 
Bill Moseley
moseley at hank.org