Re: Drawbacks of using BYTEA for PK? - Mailing list pgsql-general

Quoting Greg Stark <gsstark@mit.edu>:

> "scott.marlowe" <scott.marlowe@ihs.com> writes:
>
> > > they can try to look up information on other customers by doing:
> > >
> > >     http://domain.com/application/load_record.html?customer_id=12346
> > >     http://domain.com/application/load_record.html?customer_id=12344
> > >
> > > ...basically walking the sequence.  Sure, you will protect against this
> with
> > > access rights, BUT...seeing the sequence is a risk and not something you
>
> > > want
> > > to happen.  NOW, if you use a GUID:
> >
> > Security != obscurity.
> >
> > While using GUIDs may make it harder to get hacked, it in no way actually
> > increases security.  Real security comes from secure code, period.
>
> Well, uh, you're both wrong.
>
> On the one hand if your GUIDs are just an MD5 of a sequence then they're
> just
> as guessable as the sequence. The attacker can try MD5 of various numbers
> until he finds the one he is (it's probably on the web site somewhere
> anyways)
> and then run MD5 himself on whatever number he feels.
>
> On the other hand it is possible to do this right. Include a secret of some
> kind in the MD5 hash, something that's not publically available. That secret
> is in essence the password to the scheme. Now it's not really "obscurity"
> any
> more than any password based scheme is "security through obscurity".
>
> However even that isn't ideal, since you have to be able to change the
> password periodically in case it's leaked. I believe there are techniques to
> solve this though I can' think of any off the top of my head.
>
> But if your only threat model is people attacking based on the publicly
> visible information then an MD5 of the combination of a sequence and a
> secret
> is a perfectly reasonable approach.
>
> In the past I happily exposed the sequence but used an MD5 of the sequence
> and
> a secret as a protection against spoofing. I find exposing the sequence is
> very convenient for programming and debugging problems. Spoofing is a
> serious
> security hazard, but worrying about leaking information like the size of the
> customer database is usually a sign of people hoping for security through
> obscurity.
>
> --
> greg
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faqs/FAQ.html
>

Its not a question of right or wrong.  Its the method.  One thing I see here is
a failing to use several security methods at different layers.  That really is
necessary for a production environment.  If you want customer id's kept private,
then you need a private connection or to not expose them.  Using an MD5 hash to
"hide" them will slow your app down by some delta and not protect your
connection.  Granted garbling that id with a password is somewhat more secure
but your connection could still be attacked or even hijacked.

In the URL's you gave above, why are you not using HTTPS (i.e. authentication)?
 What about using a crytographic cookies to identify your session and link that
to you userid (after authorization)?

'Just seems like you're not using the right tool (method) for the job here.

$-0.02

--
Keith C. Perry, MS E.E.
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com

____________________________________
This email account is being host by:
VCSN, Inc : http://vcsn.com