Casper F. <casper.feldmann@googlemail.com> wrote in
<a4751755-8b65-468e-963f-512ab04c09bd@i72g2000hsd.googlegroups.com>:
> I have a table filled with sensitive data. I wanted to
> avoid the conicidental retrieval or results through
> "guessing" an id.

<http://en.wikipedia.org/wiki/Security_through_obscurity>

Leaving aside cryptographic weaknesses of MD5, which I'm not
qualified enough to discuss, if you want to prevent
unauthorised access, check whether the actor requesting the
data has the right to do so.

Burdening the unique ID with the additional semantics of
access authorisation seems fundamentally wrong to me. There
might be very legitimate reasons of communicating a unique
ID of something to a third-party without simultaneously
transferring your access rights to that same party.

> I therefore thought of using a md5-hash as the primary id.
> What implications will I have as the database fills?

First of all, you cannot guarantee that there won't be
collisions, although this is very, extremely,
near-impossibly highly unlikely. Still, 'unlikely' is not a
guarantee. And if you just happen to have two records that
have the same data in the fields you would use for hashing,
guess how loud the resulting KA-BOOM! is going to be.

Secondly, an ID obtained without guessing will allow
unauthorised access unless you implement a real security
model.

If you want your system to be secure, design it that way.

Note that if your data really is sensitive, governmental
regulations may apply, and your proposed security model
probably won't fly by any even semi-competent security
auditor.

--
When all you have is a transformation engine, everything
looks like a tree.