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

From Greg Stark
Subject Re: Drawbacks of using BYTEA for PK?
Date
Msg-id 877jzw3n5r.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Drawbacks of using BYTEA for PK?  ("scott.marlowe" <scott.marlowe@ihs.com>)
Responses Re: Drawbacks of using BYTEA for PK?
Re: Drawbacks of using BYTEA for PK?
Protection From Inference (was Re: Drawbacks of using BYTEA for PK?)
List pgsql-general
"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

pgsql-general by date:

Previous
From: Sai Hertz And Control Systems
Date:
Subject: Re: Dump/Restore ordering problem?
Next
From: Richard Huxton
Date:
Subject: Re: Announce: Search PostgreSQL related resources