Re: Drawbacks of using BYTEA for PK?

Поиск
Список
Период
Сортировка
От scott.marlowe
Тема Re: Drawbacks of using BYTEA for PK?
Дата
Msg-id Pine.LNX.4.33.0401121251230.19667-100000@css120.ihs.com
обсуждение исходный текст
Ответ на Re: Drawbacks of using BYTEA for PK?  ("D. Dante Lorenso" <dante@lorenso.com>)
Ответы Re: Drawbacks of using BYTEA for PK?  (Greg Stark <gsstark@mit.edu>)
Список 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.


В списке pgsql-general по дате отправления:

Предыдущее
От: Martin Marques
Дата:
Сообщение: Re: Vacuum Error
Следующее
От: Sai Hertz And Control Systems
Дата:
Сообщение: Re: Dump/Restore ordering problem?