Primary key and security in access restricted areas

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Primary key and security in access restricted areas

Nikolaj de Fine Licht
Hi,

It's recommended as a security messure not to use the primary key from
MySQL tables as record id in scripts etc. but rather use a unique
random id to identify records. Makes 100% sense for public product
catalogues etc.

But how important is this in access restricted areas like admin systems
and CMS systems? I mean, if you can't trust those few people with
access not to start tampering with the parameters being passed, then
you have no deal anyway. And if a hacker first manages to get pass you
access limitation, well, then he can do anything, not only play with
record ids.

I'm asking because using an extra identifier seems to me as an extra
level of complexity, which I wouldn't mind avoiding in cases where it's
not necessary...

/nikolaj


--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Primary key and security in access restricted areas

Doug Gentry
I'd still do it. Sure, an auto-increment field as the primary ID is
handy, but a randomly generated unique identifier that might see the
light of day, even in just an admin setting, seems like better
practice. I find that when I start trying to decide what is secure
enough and what isn't I spend more time on that decision. So I'm
trying, in my own projects to be more consistently secure.

I use the WT Generate Password script from www.lassoscripts.com to
generate the unique ID.

...Doug

On Jul 12, 2005, at 7:09 AM, Nikolaj de Fine Licht wrote:

> Hi,
>
> It's recommended as a security messure not to use the primary key from
> MySQL tables as record id in scripts etc. but rather use a unique
> random id to identify records. Makes 100% sense for public product
> catalogues etc.
>
> But how important is this in access restricted areas like admin
> systems and CMS systems? I mean, if you can't trust those few people
> with access not to start tampering with the parameters being passed,
> then you have no deal anyway. And if a hacker first manages to get
> pass you access limitation, well, then he can do anything, not only
> play with record ids.
>
> I'm asking because using an extra identifier seems to me as an extra
> level of complexity, which I wouldn't mind avoiding in cases where
> it's not necessary...
>
> /nikolaj
>
>
> --
> ------------------------------
> Lasso Support: http://support.omnipilot.com/
> Search the list archives: http://www.listsearch.com/lassotalk.lasso
> Manage your list subscription:  
> http://www.listsearch.com/lassotalk.lasso?manage
>

---
Doug Gentry
Dynapolis & Southern Oregon University
p:  541-261-8501 / Toll Free: 888-490-0644
[hidden email]


--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Primary key and security in access restricted areas

Richard Taubo
In reply to this post by Nikolaj de Fine Licht
Hi!

On 12. jul. 2005, at 18.33, Doug Gentry wrote:

> I'd still do it. Sure, an auto-increment field as the primary ID is
> handy, but a randomly generated unique identifier that might see the
> light of day, even in just an admin setting, seems like better
> practice. I find that when I start trying to decide what is secure
> enough and what isn't I spend more time on that decision. So I'm
> trying, in my own projects to be more consistently secure.

What kind of situation are we talking about here?  The original mail
mentioned "admin systems and CMS systems", but what is the problem with
using an auto-incrementing primary ID in these cases? If a given user
has access to only certain parts of these systems through a login
module, and every page is checked for apropriate username/password
before served, how could a hacker utilize information about an
auto-incremented primary ID? And if he could utilize information about
this, then it would seem like the real problem would be some sort of
flaw in the login module itself?

Do you have any examples of what you are reffering to here?

Thanks!

Best regards,
Richard Taubo

 


--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Primary key and security in access restricted areas

Doug Gentry
In reply to this post by Nikolaj de Fine Licht
Hmm - let's see how big a hole I can dig for myself...

I think the original question said something like the key/id in
question was in the administrative area of a CMS system, so only
trusted users would be exposed to it, and if you can't trust them who
can you trust...etc.  I've used exactly the same rationale when trying
to cut a corner or two.

What my note below was trying to convey (perhaps really a reminder to
myself) is that generally it is better to err towards caution. Maybe we
think only an admin person can see the key, but what if the hacker is
more clever than thee or me?  So I just mentally filed this in the
"good practices" category.

...Doug

On Jul 12, 2005, at 10:58 AM, Richard Taubo wrote:

> Hi!
>
> On 12. jul. 2005, at 18.33, Doug Gentry wrote:
>
>> I'd still do it. Sure, an auto-increment field as the primary ID is
>> handy, but a randomly generated unique identifier that might see the
>> light of day, even in just an admin setting, seems like better
>> practice. I find that when I start trying to decide what is secure
>> enough and what isn't I spend more time on that decision. So I'm
>> trying, in my own projects to be more consistently secure.
>
> What kind of situation are we talking about here?  The original mail
> mentioned "admin systems and CMS systems", but what is the problem
> with using an auto-incrementing primary ID in these cases? If a given
> user has access to only certain parts of these systems through a login
> module, and every page is checked for apropriate username/password
> before served, how could a hacker utilize information about an
> auto-incremented primary ID? And if he could utilize information about
> this, then it would seem like the real problem would be some sort of
> flaw in the login module itself?
>
> Do you have any examples of what you are reffering to here?
>
> Thanks!
>
> Best regards,
> Richard Taubo
>
>
>
> --
> ------------------------------
> Lasso Support: http://support.omnipilot.com/
> Search the list archives: http://www.listsearch.com/lassotalk.lasso
> Manage your list subscription:  
> http://www.listsearch.com/lassotalk.lasso?manage
>

---
Doug Gentry
Dynapolis & Southern Oregon University
p:  541-261-8501 / Toll Free: 888-490-0644
[hidden email]


--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Primary key and security in access restricted areas

Fletcher Sandbeck
In reply to this post by Nikolaj de Fine Licht
On 7/12/05 at 12:05 PM by [hidden email] (Doug Gentry):

>Hmm - let's see how big a hole I can dig for myself...
>
>I think the original question said something like the key/id in
>question was in the administrative area of a CMS system, so only
>trusted users would be exposed to it, and if you can't trust them who
>can you trust...etc.  I've used exactly the same rationale when trying
>to cut a corner or two.
>
>What my note below was trying to convey (perhaps really a reminder to
>myself) is that generally it is better to err towards caution. Maybe we
>think only an admin person can see the key, but what if the hacker is
>more clever than thee or me?  So I just mentally filed this in the
>"good practices" category.

It does depend on the goals of your site though.  For example, I have a site that has categories that are numbered sequentially from 1 to about 1000.  These aren't really secret.  I don't care if someone increments the category number to quickly cycle through all the categories on the site.

Instead, the category system was designed for speed.  It uses the smallest INTs possible, the fewest number of fields, and the most efficient indexing to ensure that the joins from article to multiple categories don't slow down the site.  Using random keys wouldn't necessarily slow things down, but switching to longer keys or alphanumeric keys might.

These considerations, like using 11 bytes to store a 10-digit key in a VARCHAR versus storing essentially the same key in 4 bytes in an INT, don't matter when the number of records is small or the traffic on a site is relatively low, but they start to matter a lot with bigger databases and heavier traffic sites.

[fletcher]
--
Fletcher Sandbeck                         [hidden email]
Lasso Product Specialist              [hidden email]
OmniPilot Software, Inc.                http://www.omnipilot.com

--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Primary key and security in access restricted areas

Greg Willits
In reply to this post by Nikolaj de Fine Licht
On Jul 12, 2005, at 7:09 AM, Nikolaj de Fine Licht wrote:

> It's recommended as a security messure not to use the primary key from
> MySQL tables as record id in scripts etc. but rather use a unique
> random id to identify records. Makes 100% sense for public product
> catalogues etc.

I think the, err, key here is that it is wise to not use an easily
guessed or sequential key value. I don't think it matters whether the
key is the primary key or not, it's just that the IDs you pass around
from page to page, function to function should not be something which
can be substituted with a high probability of that value being a real
one.

IMO, people just shouldn't use autoinc columns as primary keys (with
some exceptions for cases of generic refc data -- i.e. a table of
States or Cities or something--who cares if you can guess one of
those).


> But how important is this in access restricted areas like admin
> systems and CMS systems? I mean, if you can't trust those few people
> with access not to start tampering with the parameters being passed,
> then you have no deal anyway. And if a hacker first manages to get
> pass you access limitation, well, then he can do anything, not only
> play with record ids.

In the strictest sense, it probably depends (as to whether it matters),
but if your code is written to always do it the most secure way then,
it's always a non-issue. If you write your code to do it this way now,
it's ready to go the next time. Also, you never know the true nature of
even "trusted" users. They feel a layoff is coming, find their spouse
with the boss... you just never know. Your job is to protect your
client's data. Assume everyone and all input in evil. The old replace
the password after the first use practice assumes that even people
maintaining the systems are (could be) evil.


> I'm asking because using an extra identifier seems to me as an extra
> level of complexity, which I wouldn't mind avoiding in cases where
> it's not necessary...

Don't make it "extra" -- replace your autoinc field with random string
value as the primary key to start with. Create the ID as part of your
add record process.


>> On Jul 12, 2005, at 10:58 AM, Richard Taubo wrote:
>> What kind of situation are we talking about here?  The original mail
>> mentioned "admin systems and CMS systems", but what is the problem
>> with using an auto-incrementing primary ID in these cases? If a given
>> user has access to only certain parts of these systems through a
>> login module, and every page is checked for apropriate
>> username/password before served, how could a hacker utilize
>> information about an auto-incremented primary ID? And if he could
>> utilize information about this, then it would seem like the real
>> problem would be some sort of flaw in the login module itself?
>>
>> Do you have any examples of what you are reffering to here?

The situations are more principles based than cut & dry examples.
There's two main discussion to this practice, and I'll say up front
some people just don't buy it (which I just don't understand :-)

First, the simple scenario of you having a list of records with a
detail link provides everyone with a list of records IDs. If those IDs
are easy to guess, then I can potentially look at any record I want by
guessing another ID.

Second, forget about how it happens, but let's say someone finds a hole
in your application, and can either extract data or even delete or
modify data that they shouldn't be. Assuming the primary key is
involved, if that key is a simple autoinc, then it is very easy to
write a script to automate stepping through every record in your data.
If instead that key is a random string, then it becomes very
computationally expensive to automate a script, and the attacker is
likely to go play somewhere else.

OK, so now the typical "but..." debates begin. Let's start with the
first scenario.

If you have records which are filtered for use based on the user. Then
simply testing for a valid un/pw is not good enough. You obviously need
some type of application level permission (not a Lasso permission)
which defines which user can see which records. The mistake is often
made that if you only show certain records to that user, those are the
only ones which can be manipulated by that user. If your details page
simply uses the record ID to select the record to display, then I
simply guess another ID, submit that, your original filter is useless.
So, if the application (and not all do) requires that certain users can
only manipulate certain records, those records need to be stamped with
some identifier to that effect, and your details page of course needs
to reiterate that by including that filter into the select along with
the record ID. Then even if you do guess another ID, the app can say,
"hey, that's not yours."

So, in the end, yes, this has more to do with coding the application
properly than it does with any inherent wrongness of using an easy to
guess key field value. But I'm not done yet :-)

Let's look at scenario two. The debatable issue here is that with SQL,
any field in a where clause can be used to determine which records to
update or delete, or worse, the lack of a field impacts all records.
So, if through some hole in your application I can change a record
based on a city name, what difference does it make whether the primary
ID is sequential or not -- or even whether it is obscured with a
temporary server side map? Well in that worse case scenario it doesn't,
but most often applications are written to update and delete based on
the primary key, so again, we can foil the automation potential by
using a random string, even though it may not cover every possible
scenario (which nothing ever does).

In the end, this comes down to two principles: CYA and concentric rings
of defenses.

The CYA factor comes into play when you've programmed in error a hole
in your application. Of course there should not be a case where
manipulating your forms allows a delete when it isn't authorized.
But... if you screw up, forget, or through some complex scenario create
such a critter you just didn't see as possible, then you need another
line of defense to make it difficult to exploit that hole. That brings
us to the concentric rings principle.

A fundamental aspect of security (of any type) is having more than one
line of defense. Now, if you're guarding Fort Knox, you might want 20
lines. You'd never assume that a motion detector was good enough. For
your average web app, you want at least a few: a login password, short
time expired session, specific user permissions matrix, records stamped
with ownership to verify each query with (if applicable), and difficult
to guess key fields, etc.

Most of our homes only have a single line of defense -- a door or
window lock. Get past any one of those, and a person has free reign to
your home. Leave your garage door opener in the car, and same thing.
Steal the opener and your registration, and now I'm in your home (and I
bet you don't lock the door between the garage and house do you). If
you program to the minimum standard, then that's what you have--one
line of defense. If any of those "should" be "good enough" areas fails
you due to a problem in your code, a problem with the server code, etc.
then you have nothing else to make an attacker's life difficult. If the
attack is a difficult one, they'll go somewhere else. You don't get
that with minimum requirements coding.

If you're a captive developer making that one application for your
employer from scratch, maybe you can get away with it or justify the
cost benefit for the app. If you're a for-hire developer, you're not
doing your job IMO if you settle for just the basics. Also if you're a
for-hire developer you should be making some libraries of reusable code
with decent security practices built in. When you do that, the extra
security measures become free. They're already there, and every
developer should be working towards that IMO.

-- greg willits



--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Primary key and security in access restricted areas

Hans de Wit
In reply to this post by Nikolaj de Fine Licht
In a secured area or not I always use a second identifier. It is a 20-22
digit cryptic key. This is due to the fact that on a number of occasions
these are reflected in the URL as well as in type="hidden" statements.
This stops the user of playing with the URL and seeing what happens.
Mostly unintentional usage, but I like to be on the safe side. Perhaps
it is overkill, but better safe than sorry, especially on a tiered
ECommerce site as big as www.printer.ca

Hans


Nikolaj de Fine Licht wrote:

> Hi,
>
> It's recommended as a security messure not to use the primary key from
> MySQL tables as record id in scripts etc. but rather use a unique
> random id to identify records. Makes 100% sense for public product
> catalogues etc.
>
> But how important is this in access restricted areas like admin
> systems and CMS systems? I mean, if you can't trust those few people
> with access not to start tampering with the parameters being passed,
> then you have no deal anyway. And if a hacker first manages to get
> pass you access limitation, well, then he can do anything, not only
> play with record ids.
>
> I'm asking because using an extra identifier seems to me as an extra
> level of complexity, which I wouldn't mind avoiding in cases where
> it's not necessary...
>
> /nikolaj
>


--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Primary key and security in access restricted areas

hannan
In reply to this post by Nikolaj de Fine Licht
Ouch.

On Jul 12, 2005, at 2:45 PM, Greg Willits wrote:

> On Jul 12, 2005, at 7:09 AM, Nikolaj de Fine Licht wrote:
>
>
>> It's recommended as a security messure not to use the primary key  
>> from MySQL tables as record id in scripts etc. but rather use a  
>> unique random id to identify records. Makes 100% sense for public  
>> product catalogues etc.
>>
>
> I think the, err, key here is that it is wise to not use an easily  
> guessed or sequential key value. I don't think it matters whether  
> the key is the primary key or not, it's just that the IDs you pass  
> around from page to page, function to function should not be  
> something which can be substituted with a high probability of that  
> value being a real one.
>
> IMO, people just shouldn't use autoinc columns as primary keys  
> (with some exceptions for cases of generic refc data -- i.e. a  
> table of States or Cities or something--who cares if you can guess  
> one of those).
>
>
>
>> But how important is this in access restricted areas like admin  
>> systems and CMS systems? I mean, if you can't trust those few  
>> people with access not to start tampering with the parameters  
>> being passed, then you have no deal anyway. And if a hacker first  
>> manages to get pass you access limitation, well, then he can do  
>> anything, not only play with record ids.
>>
>
> In the strictest sense, it probably depends (as to whether it  
> matters), but if your code is written to always do it the most  
> secure way then, it's always a non-issue. If you write your code to  
> do it this way now, it's ready to go the next time. Also, you never  
> know the true nature of even "trusted" users. They feel a layoff is  
> coming, find their spouse with the boss... you just never know.  
> Your job is to protect your client's data. Assume everyone and all  
> input in evil. The old replace the password after the first use  
> practice assumes that even people maintaining the systems are  
> (could be) evil.
>
>
>
>> I'm asking because using an extra identifier seems to me as an  
>> extra level of complexity, which I wouldn't mind avoiding in cases  
>> where it's not necessary...
>>
>
> Don't make it "extra" -- replace your autoinc field with random  
> string value as the primary key to start with. Create the ID as  
> part of your add record process.
>
>
>
>>> On Jul 12, 2005, at 10:58 AM, Richard Taubo wrote:
>>> What kind of situation are we talking about here?  The original  
>>> mail mentioned "admin systems and CMS systems", but what is the  
>>> problem with using an auto-incrementing primary ID in these  
>>> cases? If a given user has access to only certain parts of these  
>>> systems through a login module, and every page is checked for  
>>> apropriate username/password before served, how could a hacker  
>>> utilize information about an auto-incremented primary ID? And if  
>>> he could utilize information about this, then it would seem like  
>>> the real problem would be some sort of flaw in the login module  
>>> itself?
>>>
>>> Do you have any examples of what you are reffering to here?
>>>
>
> The situations are more principles based than cut & dry examples.  
> There's two main discussion to this practice, and I'll say up front  
> some people just don't buy it (which I just don't understand :-)
>
> First, the simple scenario of you having a list of records with a  
> detail link provides everyone with a list of records IDs. If those  
> IDs are easy to guess, then I can potentially look at any record I  
> want by guessing another ID.
>
> Second, forget about how it happens, but let's say someone finds a  
> hole in your application, and can either extract data or even  
> delete or modify data that they shouldn't be. Assuming the primary  
> key is involved, if that key is a simple autoinc, then it is very  
> easy to write a script to automate stepping through every record in  
> your data. If instead that key is a random string, then it becomes  
> very computationally expensive to automate a script, and the  
> attacker is likely to go play somewhere else.
>
> OK, so now the typical "but..." debates begin. Let's start with the  
> first scenario.
>
> If you have records which are filtered for use based on the user.  
> Then simply testing for a valid un/pw is not good enough. You  
> obviously need some type of application level permission (not a  
> Lasso permission) which defines which user can see which records.  
> The mistake is often made that if you only show certain records to  
> that user, those are the only ones which can be manipulated by that  
> user. If your details page simply uses the record ID to select the  
> record to display, then I simply guess another ID, submit that,  
> your original filter is useless. So, if the application (and not  
> all do) requires that certain users can only manipulate certain  
> records, those records need to be stamped with some identifier to  
> that effect, and your details page of course needs to reiterate  
> that by including that filter into the select along with the record  
> ID. Then even if you do guess another ID, the app can say, "hey,  
> that's not yours."
>
> So, in the end, yes, this has more to do with coding the  
> application properly than it does with any inherent wrongness of  
> using an easy to guess key field value. But I'm not done yet :-)
>
> Let's look at scenario two. The debatable issue here is that with  
> SQL, any field in a where clause can be used to determine which  
> records to update or delete, or worse, the lack of a field impacts  
> all records. So, if through some hole in your application I can  
> change a record based on a city name, what difference does it make  
> whether the primary ID is sequential or not -- or even whether it  
> is obscured with a temporary server side map? Well in that worse  
> case scenario it doesn't, but most often applications are written  
> to update and delete based on the primary key, so again, we can  
> foil the automation potential by using a random string, even though  
> it may not cover every possible scenario (which nothing ever does).
>
> In the end, this comes down to two principles: CYA and concentric  
> rings of defenses.
>
> The CYA factor comes into play when you've programmed in error a  
> hole in your application. Of course there should not be a case  
> where manipulating your forms allows a delete when it isn't  
> authorized. But... if you screw up, forget, or through some complex  
> scenario create such a critter you just didn't see as possible,  
> then you need another line of defense to make it difficult to  
> exploit that hole. That brings us to the concentric rings principle.
>
> A fundamental aspect of security (of any type) is having more than  
> one line of defense. Now, if you're guarding Fort Knox, you might  
> want 20 lines. You'd never assume that a motion detector was good  
> enough. For your average web app, you want at least a few: a login  
> password, short time expired session, specific user permissions  
> matrix, records stamped with ownership to verify each query with  
> (if applicable), and difficult to guess key fields, etc.
>
> Most of our homes only have a single line of defense -- a door or  
> window lock. Get past any one of those, and a person has free reign  
> to your home. Leave your garage door opener in the car, and same  
> thing. Steal the opener and your registration, and now I'm in your  
> home (and I bet you don't lock the door between the garage and  
> house do you). If you program to the minimum standard, then that's  
> what you have--one line of defense. If any of those "should" be  
> "good enough" areas fails you due to a problem in your code, a  
> problem with the server code, etc. then you have nothing else to  
> make an attacker's life difficult. If the attack is a difficult  
> one, they'll go somewhere else. You don't get that with minimum  
> requirements coding.
>
> If you're a captive developer making that one application for your  
> employer from scratch, maybe you can get away with it or justify  
> the cost benefit for the app. If you're a for-hire developer,  
> you're not doing your job IMO if you settle for just the basics.  
> Also if you're a for-hire developer you should be making some  
> libraries of reusable code with decent security practices built in.  
> When you do that, the extra security measures become free. They're  
> already there, and every developer should be working towards that IMO.
>
> -- greg willits
>
>
>
> --
> ------------------------------
> Lasso Support: http://support.omnipilot.com/
> Search the list archives: http://www.listsearch.com/lassotalk.lasso
> Manage your list subscription:  http://www.listsearch.com/ 
> lassotalk.lasso?manage
>


--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Primary key and security in access restricted areas

Greg Willits
In reply to this post by Nikolaj de Fine Licht
On Jul 12, 2005, at 5:13 PM, Duane Hannan wrote:

> Ouch.

Ouch? Hmm.... too many "thou shalts"?

Of course all the "you"s are supposed to be "we"s... writing quickly
tends to create forceful dictations, but they're all supposed to be
aimed at a collective "us" as developers. Hey, the archives (and my old
code) have plenty of evidence of my early ignorance. And some recent
ignorance too probably :-P

-- gw



On Jul 12, 2005, at 5:13 PM, Duane Hannan wrote:

> Ouch.
>
> On Jul 12, 2005, at 2:45 PM, Greg Willits wrote:
> [forty pages of drivel...]


--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Primary key and security in access restricted areas

Nikolaj de Fine Licht
In reply to this post by Nikolaj de Fine Licht
Thank you to all who posted thoughts on this :)

And thank you in particular to Greg for a once again extremely well
expressed text with very good points, I'm convinced ;)

Especially I like the 'concentric rings of defense'-visualisation, it
just makes 100& sense.

Only one little sigh: I think I can say "you Americans", 'cause I think
it's special American feature, use these abbrevations that
unfortunately I can't crack. Like CYA. This may be due to my lack of my
knowledge of programmer language use. Another one is IMO. Or FWIW in
other posts.

Maybe someone wouldn't mind to post (or mail me directly) a little list
of typical acronyms and their translation ;-)

Thanks again to Greg for taking the time. If ever you set up an
advanced Lasso course of some kind I will seriously consider buying a
ticket to wherever you live in the US :)

Or back to the returning discussion of an up-to-date printed Lasso
book: you would be the absolutely perfect person to write that one! You
could start by collecting and editing most of your posts to this list!

/nikolaj

On 12. jul 2005, at 21:45, Greg Willits wrote:

> If you're a captive developer making that one application for your
> employer from scratch, maybe you can get away with it or justify the
> cost benefit for the app. If you're a for-hire developer, you're not
> doing your job IMO if you settle for just the basics. Also if you're a
> for-hire developer you should be making some libraries of reusable
> code with decent security practices built in. When you do that, the
> extra security measures become free. They're already there, and every
> developer should be working towards that IMO.


--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Primary key and security in access restricted areas

Greg Willits
In reply to this post by Nikolaj de Fine Licht
On Jul 13, 2005, at 8:37 AM, Nikolaj de Fine Licht wrote:

> Only one little sigh: I think I can say "you Americans", 'cause I
> think it's special American feature, use these abbrevations that
> unfortunately I can't crack. Like CYA. This may be due to my lack of
> my knowledge of programmer language use. Another one is IMO. Or FWIW
> in other posts.

CYA = cover your arse - self preservation "just in case"
IMO = in my opinion
IMHO = in my humble opinion
FWIW = for what it's worth
AFAIK = as far as I know
AFAICT = as far as I can tell
RTFM = read the 'friggin' manual

http://www.netlingo.com/emailsh.cfm -- this is an overboard list. I've
never seen half of them actually used, but it's thorough

> Thanks again to Greg for taking the time. If ever you set up an
> advanced Lasso course of some kind I will seriously consider buying a
> ticket to wherever you live in the US :)

Maybe I'd rather come to where you are! :-)


> Or back to the returning discussion of an up-to-date printed Lasso
> book: you would be the absolutely perfect person to write that one!
> You could start by collecting and editing most of your posts to this
> list!

If I could make the time, I would... thought about it many times. Even
have some outlines done. Alas, many projects on the "what's next" list
and hard to tell where this one stacks right now.

-- gw


--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Primary key and security in access restricted areas

Pierre Yelle
In reply to this post by Nikolaj de Fine Licht

On 13-Jul-05, at 8:37 AM, Nikolaj de Fine Licht wrote:

> Maybe someone wouldn't mind to post (or mail me directly) a little
> list of typical acronyms and their translation ;-)
>
> Thanks again to Greg for taking the time. If ever you set up an
> advanced Lasso course of some kind I will seriously consider buying a
> ticket to wherever you live in the US :)
>
> Or back to the returning discussion of an up-to-date printed Lasso
> book: you would be the absolutely perfect person to write that one!
> You could start by collecting and editing most of your posts to this
> list!
>
>

and chiming in also with the other discussion about PHP vs Lasso,

It would be nice for Lasso, if Omnipilot, Geg Willits, Bil Cory and
some of the other geniuses got to set up a
company à la MySQL AB.

Lasso would be free
Framework would be free
Security would be well defined.
etc..etc

and this Lasso AB entitiy, would make their money dispensing classes,
books, customization and optimization....

I'm pretty sure the model (or variation on it) would be profitable big
time for all involved...


Pierre


--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Primary key and security in access restricted areas

Nikolaj de Fine Licht
In reply to this post by Nikolaj de Fine Licht
On 13. jul 2005, at 18:04, Greg Willits wrote:

>>  If ever you set up an advanced Lasso course of some kind I will
>> seriously consider buying a ticket to wherever you live in the US :)
>
> Maybe I'd rather come to where you are! :-)

I don't know if you know but, eventhough I'm Danish, I live in Brazil?
So yes, Brazil is worth a visit :) As is Denmark, I would say (of
course). Some parts more than others though, like everywhere. Here
where I live (the very South) is not what people normally associate
with Brazil... I can recommend Bahia, will go there myself in December
(= summer there).

But, being nerdish again, Lasso in Brazil...that's very difficult. I
still didn't manage to convince any ISP to buy just one single license.
I need one big job here where the customer would pay for a license...
And then we are back to that other discussion: how to convince somebody
to not do what all the others do...?

/nikolaj


--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Primary key and security in access restricted areas

Dan McComb
In reply to this post by Nikolaj de Fine Licht
I really prefer the simplicity of using auto-incrementing id fields,  
so what I do to prevent showing the ID to users is to use a single  
line of blowfish encryption and decryption whenever it's necessary to  
expose the id to users. For example, if I'm giving an id in a url,  
without blowfish encryption it would look like:

      www.domain.com/index.html?id=25.

Users could page through other records by simply changing the id and  
reloading the page. But with this line you get an encrypted id:

     Encrypt_Blowfish: -Seed='blah blah blah something you make up  
here',(var:'id');

Then you just use the reverse on the receiving page:

     Decrypt_BlowFish: -Seed='blah blah blah something you make up  
here', (var:'id');

Now the url looks like: www.domain.com/index.html?id=2l3kj4jk2344lk

Nobody's likely to guess the id number now. If you're worried that  
someone can read your source code and steal your seed, you can put  
the seed into a page variable file, and include the file at the top  
of every page on your site. Then change the permissions on the page  
variables file so it's owned by Lasso, with no permissions for  
others. I believe this method makes my pages secure enough, but I'm  
no security expert, so I may be missing something. Any suggestions?

/dan

------------------------------------------------------------------------
------------

Visual Contact
4318 5th Ave. NW
Seattle, WA 98107
206.228.0780

[hidden email]
http://www.visualcontact.com


--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Primary key and security in access restricted areas

Nikolaj de Fine Licht
In reply to this post by Nikolaj de Fine Licht
On 13. jul 2005, at 18:15, Pierre Yelle wrote:

> It would be nice for Lasso, if Omnipilot, Greg Willits, Bil Corry and
> some of the other geniuses got to set up a company à la MySQL AB.
>
> Lasso would be free
> Framework would be free
> Security would be well defined.
> etc..etc
>
> and this Lasso AB entitiy, would make their money dispensing classes,
> books, customization and optimization....
>
> I'm pretty sure the model (or variation on it) would be profitable big
> time for all involved...

I think this is one of the nicest, most radical ideas that has come up
on these subjects for a very long time, if not ever. I doubt it would
ever happen - but what a nice dream :)

/nikolaj

--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Primary key and security in access restricted areas

Greg Willits
In reply to this post by Nikolaj de Fine Licht
On Jul 13, 2005, at 4:47 PM, Dan McComb wrote:

> I really prefer the simplicity of using auto-incrementing id fields,
> so what I do to prevent showing the ID to users is to use a single
> line of blowfish encryption and decryption whenever it's necessary to
> expose the id to users. For example, if I'm giving an id in a url,
> without blowfish encryption it would look like:
>
>      www.domain.com/index.html?id=25.
>
> Users could page through other records by simply changing the id and
> reloading the page. But with this line you get an encrypted id:
>
>     Encrypt_Blowfish: -Seed='blah blah blah something you make up
> here',(var:'id');
>
> Then you just use the reverse on the receiving page:
>
>     Decrypt_BlowFish: -Seed='blah blah blah something you make up
> here', (var:'id');
>
> Now the url looks like: www.domain.com/index.html?id=2l3kj4jk2344lk
>
> Nobody's likely to guess the id number now. If you're worried that
> someone can read your source code and steal your seed, you can put the
> seed into a page variable file, and include the file at the top of
> every page on your site. Then change the permissions on the page
> variables file so it's owned by Lasso, with no permissions for others.
> I believe this method makes my pages secure enough, but I'm no
> security expert, so I may be missing something. Any suggestions?

It may be totally effective (haven't thought about it), and of course
you need to do this in [records] loops for records lists with links to
detail pages to remain consistent, but it would not address where
there's a hole that allows for SQL injection which would bypass your
encryption system. Again, yes such a failure is not supposed to happen,
but if it did, you're subject to the simple incremental ID number
problems. And, you're doing a bunch of encrypt / decrypt workload
that's not really necessary (if you had random keys) -- although some
people like doing what you do to obscure the actual IDs anyway (even if
they are random).

As the only measure of protection, philosophically I would consider
that an after the fact design band-aid. But, from a practical
standpoint, it may be fine. As a secondary measure it could be a good
idea too.

However, I think there's a more effective and probably less
computationally intensive solution -- that is to use random IDs, and
then deliver simple IDs on a per page basis.

The idea (first brought to my attention by Jim Van Heule) is to store
the real id(s) in an array server side (and into a session) and display
the loop_count value. On the response page you use the loop_count "id"
as your index value to retrieve the real recordID from the array. This
combined with random ID values in my opinion is one of the most elegant
and effective solutions to all the concerns about recordID values. Of
course you have to write some defensive code so that if someone tries
entering 26 when you only supplied 25 records, that Lasso doesn't barf
on the invalid array index, but that's simple stuff you have to do with
arrays anyway.

-- greg willits



--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Primary key and security in access restricted areas

Bil Corry
In reply to this post by Nikolaj de Fine Licht
> It would be nice for Lasso, if Omnipilot, Geg Willits, Bil Cory and
> some of the other geniuses got to set up a
> company à la MySQL AB.

There would have to be a buyout of Omnipilot's position.  If you know of 100
people that have $5k to donate (or a thousand people with $500), let me know.
Perhaps OP would be open to selling Lasso to the non-profit Lasso Software
Foundation.


- Bil

------

Bil Corry
[hidden email]

Enterprise internet application development and security consulting
  http://www.fivegeeks.com/

Tools for Rapid Lasso Development
  http://www.lassoware.com/
 
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of
Pierre Yelle
Sent: Wednesday, July 13, 2005 9:15 AM
To: [hidden email]
Subject: Re: Primary key and security in access restricted areas


On 13-Jul-05, at 8:37 AM, Nikolaj de Fine Licht wrote:

> Maybe someone wouldn't mind to post (or mail me directly) a little
> list of typical acronyms and their translation ;-)
>
> Thanks again to Greg for taking the time. If ever you set up an
> advanced Lasso course of some kind I will seriously consider buying a
> ticket to wherever you live in the US :)
>
> Or back to the returning discussion of an up-to-date printed Lasso
> book: you would be the absolutely perfect person to write that one!
> You could start by collecting and editing most of your posts to this
> list!
>
>

and chiming in also with the other discussion about PHP vs Lasso,

It would be nice for Lasso, if Omnipilot, Geg Willits, Bil Cory and
some of the other geniuses got to set up a
company à la MySQL AB.

Lasso would be free
Framework would be free
Security would be well defined.
etc..etc

and this Lasso AB entitiy, would make their money dispensing classes,
books, customization and optimization....

I'm pretty sure the model (or variation on it) would be profitable big
time for all involved...


Pierre



--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Primary key and security in access restricted areas

Johan Solve
In reply to this post by Nikolaj de Fine Licht
On 7/14/05, Greg Willits <[hidden email]> wrote:
> The idea (first brought to my attention by Jim Van Heule) is to store
> the real id(s) in an array server side (and into a session) and display
> the loop_count value. On the response page you use the loop_count "id"
> as your index value to retrieve the real recordID from the array.

Nice apprpoach. One problem with this is that the temp ids are
volatile, which can make the server and browser become out of sync for
example if back/forward is used.

--
     Johan Sölve    [FSA Partner, Lasso Partner]
     Web Application/Lasso/FileMaker Developer
     MONTANIA SOFTWARE & SOLUTIONS
http://www.montania.se   mailto:[hidden email]
 (spam-safe email address, replace '-' with 'a')

--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Primary key and security in access restricted areas

Greg Willits
In reply to this post by Nikolaj de Fine Licht
On Jul 13, 2005, at 11:33 PM, Johan Solve wrote:

> On 7/14/05, Greg Willits <[hidden email]> wrote:
>> The idea (first brought to my attention by Jim Van Heule) is to store
>> the real id(s) in an array server side (and into a session) and
>> display
>> the loop_count value. On the response page you use the loop_count "id"
>> as your index value to retrieve the real recordID from the array.
>
> Nice apprpoach. One problem with this is that the temp ids are
> volatile, which can make the server and browser become out of sync for
> example if back/forward is used.

I believe the full method included using shown_first and possibly a map
of arrays.

So the detail link would have to pass the shown_first value and the
loop_count value. The server data structure is actually a map of arrays

        1 = wert, oiuy, nmlk, kjhk, vcgdf
        6 = dhye, kwuf, ghwy, igdy, qvya
        11 =
        16 =
        etc...

So, now if you browser back a page, you can still pick out the right
record.

Each row (array) would only get added if the user actually viewed that
page of the results. You easily have

        1 = wert, oiuy, nmlk, kjhk, vcgdf
        6 = dhye, kwuf, ghwy, igdy, qvya
        151 = axcr, plok, hbgv, lmfc, wgeh

because the user skipped to the last page of the results list, and it
would still work.

I suppose though if you go back many pages into a whole new search,
that could be a problem because now 6-1 isn't really for the record
kwuf anymore. Solvable by an outer map which identifies each search
result set (a random ID that is used as the map name, and then passed
with shown_first & loop_count).

        gsheyab7shdbb =
                1 = wert, oiuy, nmlk, kjhk, vcgdf
                6 = dhye, kwuf, ghwy, igdy, qvya
                11 =
                16 =
        hdb629sjsmns87 =
                1 = dhye, kwuf, ghwy, igdy, qvya
                6 = wert, oiuy, nmlk, kjhk, vcgdf
                11 =
                16 =
        etc...

Sounds complex, but it really isn't, and still less CPU time than
encryption. Though, I guess it could get real big if it was something
you allow 50 results per page, and the user did a couple dozen
searches.

I like the idea, but I haven't actually implemented it yet (need to
update my auto list drawing system to do that).

-- greg




--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
Reply | Threaded
Open this post in threaded view
|

Re: Primary key and security in access restricted areas

Richard Taubo
In reply to this post by Nikolaj de Fine Licht
Hi!

I like security, but before switching to using any Primary Keys with
random IDs I have to be convinced about their real advantage.
What I don't get in this discussion is the Holy Grail kinda status
going for the Primary Key.  :-)
If an SQL database server was like Filemaker where you would have to
know the Primary Key to delete or update a record, then I would
understand this more.
But in SQL you have much more freedom and can wipe out a whole database
by using a command like: DELETE FROM my_table or retrieve all columns
and rows by:
SELECT * FROM my_table

1) Why is therefore so important to protect the Primary Key?
2) What about other columns that have some sort of system to them like
phone numbers and first names, what are the difference between such
columns and the Primary Key?


As I said, I like security but I want to know what I am programming
against before applying a given method.

Can anyone provide one example where not using random ID for the
Primary Key will get you into trouble?
I am not talking about systems where you can just add one number in the
url to get a record you were not supposed to see - it would have to be
a little more advanced than that.

Thanks, and I hope you are able to convince my of the strength of the
random ID concept -> I am always willing to learn! :-)


Best regards,
Richard Taubo


--
------------------------------
Lasso Support: http://support.omnipilot.com/
Search the list archives: http://www.listsearch.com/lassotalk.lasso
Manage your list subscription:  
http://www.listsearch.com/lassotalk.lasso?manage
12