From: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
---|---|
To: | "D(dot) Dante Lorenso" <dante(at)lorenso(dot)com> |
Cc: | David Garamond <lists(at)zara(dot)6(dot)isreserved(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Drawbacks of using BYTEA for PK? |
Date: | 2004-01-12 19:52:19 |
Message-ID: | Pine.LNX.4.33.0401121251230.19667-100000@css120.ihs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, 12 Jan 2004, D. Dante Lorenso wrote:
>
> > Tom Lane wrote:
> >
> >> Adding an MD5 hash contributes *absolutely zero*, except waste of space,
> >> to any attempt to make a GUID. The hash will add no uniqueness that was
> >> not there before.
> >
> The cool thing about a 'GUID' (or in my example a hashed sequence number
> [sure
> toss in some entropy if you want it]) is that if you happen to reference
> that
> value as a primary key on a table, the URL that passes the argument can not
> be guessed at easily. For example using a sequence:
>
> http://domain.com/application/load_record.html?customer_id=12345
>
> Then, users of the web will assume that you have at most 12345
> customers. And
> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Sai Hertz And Control Systems | 2004-01-12 20:23:34 | Re: Dump/Restore ordering problem? |
Previous Message | Martin Marques | 2004-01-12 19:25:13 | Re: Vacuum Error |