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?
|
Список | 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 по дате отправления: