SEO

On Tue, 22 Apr 2008 12:29:28 -0700 (PDT), lawpoop@gmail.com wrote:
> On Apr 22, 5:46 am, "petethebl...@googlemail.com"
><petethebl...@googlemail.com> wrote:
>> On 21 Apr, 22:40, "Paul Lautman" <paul.laut...@btinternet.com> wrote:
>>
>> > Confidential!!! It will be a list of fields with data types, sizes and field
>> > names. That is what all tables look like. How the !"!"££ can it be
>> > confidential!
>>
>> That's what I was trying to say, but more politely.
>
> Well, if we have a database that's available to the public through a
> website, and some entreprising hacker wants to do an SQL injection,
> they would get quite a leg up if they could look up the exact names of
> our fields and tables.

*cough* If said hacker can amanage and injection, she can ask the
database about the tables and column names. Your help isn't needed.

> Of course we are taking every precaution to prevent SQL injections and
> other hacking attemps, and not broadcasting table definitions on the
> internet is part of that

Maybe, but it appears that your every precaution is a bit fuzzier than
most people's every precaution.

> As far as confidential, saying that no table definition can be
> confidential because it's made up of the same parts ( tables and
> fields ) as any other database is like saying all programs are the
> same because they're all made up of vairable and operators. It's the
> arrangement of the parts that adds value. Surely, you would agree that
> certain database structures are better than others for particular
> problems. Or all they all the same? If they aren't the same, then a
> business person who invested money to get a better data model might
> want to protect their investment.

If it's that clever, you'll have it patented. If it's not patentable,
then it's too obvious to be a strategic advantage.

> Why couldn't Microsoft release the code for Windows? After all, it's
> made up of the same parts as any other program. And I'm not talking
> security wise, but competition-wise -- for example, not giving OS
> providers a leg up in creating platforms to run software written to
> run with the Windows API.

Easy answer. They'd end up with thousands of programmers falling over
laughing.

> Suppose we have a business model, expressed as a database, that is
> superior to our competitions', and that allows us to ship products
> faster for less money. Why would we want to then give our model to our
> competition? We spent a lot of time and money building it; it doesn't
> make business sense to give it to your competition for free.

The first sale to someone connected to your competition gives them the
model. You CANNOT enforce security on someone else's database. It
doesn't work like that.

--
73. I will not agree to let the heroes go free if they win a rigged contest,
even though my advisors assure me it is impossible for them to win.
--Peter Anspach's list of things to do as an Evil Overlord

On Apr 23, 9:14 am, "Peter H. Coffin" <hell...@ninehells.com> wrote:
>
> > Well, if we have a database that's available to the public through a
> > website, and some entreprising hacker wants to do an SQL injection,
> > they would get quite a leg up if they could look up the exact names of
> > our fields and tables.
>
> *cough* If said hacker can amanage and injection, she can ask the
> database about the tables and column names. Your help isn't needed.

If said hacker is injecting using an account with limited permissions,
they can't ask general questions about the database structure. Well,
they can ask, but they won't get the answer they want. : )

They can only inject with the permissions that their account grants
them, unless they can escalate permission. So, if they don't have
permissions for "SHOW TABLES FROM database" or "DESCRIBE table", then
they would have to guess table and field names -- unless, say, we were
to tell them what they are in a usenet group.

>
> If it's that clever, you'll have it patented. If it's not patentable,
> then it's too obvious to be a strategic advantage.
>

The small business people I've dealt with have a pragmatic view of
legal protections, much like nuclear weapons. They like to have them,
and love threatening the other guy with them at the meeting, but to
actually use them is an expensive, risky proposition. It escalates a
situation to all out war ( whereas before you were doing business with
the party, now you are losing ) and has the serious potential to blow
up in your face.

"Instead of making me go to court and pay thousands of dollars to a
lawyer to defend the patents we got, and risk losing the case, how
about you just not post the work I'm paying you to do on the
internet?"

And if they are using our code or data structure, how would we even
find out about it to trigger the patent protections? It's much cheaper
to keep your programmers in line, than to go to court for months.

Even if it's not clever enough to be patentable, it still takes time
( read: money ) to do a job properly. "I'm paying you good money to
write code, and you say it's worth the money. So why are you giving
the work away for free on the internet?" So now

I'm not saying the competition, I'm just giving you the reasoning that
small business people employ. They can't afford patents and months-
long legal cases; the simple, affordable fix is simply not to give
away your investment. Money is worth more to the little guys than it
is to the big guys, because little guys have less of it. If they
surrender some of their hard earned cash to buy some code from you,
they have a real hard time understanding why you're willing to give it
away for free to "your buddies on the internet".

"You've already spent thousands of dollars on database application.
You should spend several more on patents and lawyers defending it in
court. What? Oh, I don't know how you would find out if someone is
infringing on your patent. Probably in the discovery process of the
court case, I guess." At this point, steam is coming out of their
ears.

>
> > Suppose we have a business model, expressed as a database, that is
> > superior to our competitions', and that allows us to ship products
> > faster for less money. Why would we want to then give our model to our
> > competition? We spent a lot of time and money building it; it doesn't
> > make business sense to give it to your competition for free.
>
> The first sale to someone connected to your competition gives them the
> model. You CANNOT enforce security on someone else's database. It
> doesn't work like that.
>

Straw man argument. We sell a service on the web, not a license to run
a program. The only interface the user has to our code and database
structure is through a web page. Given everything working properly,
they would never see a snippet of code or SQL. They never receive code
from us; only pdfs and web pages.

On Apr 22, 5:51 pm, Kees Nuyt <k.n...@nospam.demon.nl> wrote:
> On Tue, 22 Apr 2008 12:29:28 -0700 (PDT),
>
> lawp...@gmail.com wrote:
> >Well, if we have a database that's available to the public through a
> >website, and some entreprising hacker wants to do an SQL injection,
> >they would get quite a leg up if they could look up the exact names of
> >our fields and tables.
>
> They could try to query the INFORMATION_SCHEMA first,
> or use SHOW CREATE ... and explore from there.

If the MySQL user account they're connecting with does not have
permissions for that, then those queries will get them nowhere.

On 23 Apr, 14:22, lawp...@gmail.com wrote:
> On Apr 23, 9:14 am, "Peter H. Coffin" <hell...@ninehells.com> wrote:
>
And of course, it is totally beyond you to export the structure and
just rename the fields.

But I guess that takes a modicum of intelligence.

On Apr 22, 4:25 pm, "Rik Wasmus" <luiheidsgoe...@hotmail.com> wrote:
> On Tue, 22 Apr 2008 21:29:28 +0200, <lawp...@gmail.com> wrote:

>
> If the data/table definition is THAT sensitive, and security necessarily
> THAT tight, I cannot imagine there is no money for an 'expert' reasonably
> savvy enough to troubleshoot a simple unique index problem. If there's an
> attempt at security at database level by people who can't even do this,
> I'd say it's almost certainly doomed to fail or at least have a few holes.

I deal with a lot of small business people. To them, a few thousands
dollars to develop an app is a lot of money . No, they don't have more
money to hire a consultant to trouble shoot a simple error, that's
what they hired me for. If I tell them that they need to pay X for
another consultant, or Y for patenting, or Z for this, then they will
tell me that I mislead them about the true cost of what they were
getting into at the beginning. they make very certain that I am
telling them the full story about all the costs of development from
the outset. They want to get a solid number on the total cost before
we start, and get very upset about putting in more money. It's like
after you closed a deal on a car, and then the salesperson says "You
need to buy rust protection. After all, you're spending X dollars on
this car. Don't you want to protect the investment? Also, you'll need
the extended warranty" . That's how they perceive it. It feels like a
bait and switch to them.

It's not that the table definition is that sensitive, it's just that
the small business people I work for have a hard time understand why
they pay me "all this money" in exchange for code, and then watch me
"turn around and give it away on the internet". "Why should I pay you
to write it then? Why can't you just copy and paste it from the other
people who are posting it?" They are more paranoid about protecting
their investment then the bigger guys, because it is more variable to
them. If a big company spends a few thousand dollars on a table
definition, they can afford to "lose it". A small business owner
cannot. Yes, I know they are not "losing it", and yes, i know you
cannot cut and paste from the internet and have a fully functional
database. But they don't. I try my best to explain it to them, but
they rarely see it from my perspective. So, I don't bite the hand
that feeds me. If it were up to me, I would probably post the table
definition. T

I don't know everything about MySQL; sometimes I get caught up in
simple error, or have a brain fart, or it's something I thought I knew
but was wrong. If it seems like a simple error that someone might know
of the top of the head, that a pair of fresh eyes could easily
recognize, then I post it on the list. I always get right to the
point, provide adequate information, and try to ask yes/no questions.
I am under certain constraints, so therefore I don't expect people to
do a complete troubleshooting. I'm sorry I could not bring this thread
beyond that point.


>
> In short, if you cannot 'broadcast' the table definition here, and my
> simple example demonstrated that MySQL has no problem with a UNIQUE key on
> multiple fields, we cannot help you any further, apart from wildly
> guessing.

That's exactly what I'm looking for. Thank you. I'm sorry I cannot
provide the additional information that you are looking for.

I haven't asked for any additional help beyond my original question. I
tried to explain why I couldn't post additional information for
further assistance; perhaps I did a lousy job communicating those
reasons, but that's water under the bridge now.

>
> My first guess (and almost certainly the correct one) is:
> - the UNIQUE is NOT defined properly, or there are more then 1 UNIQUE keys
> defined on the same table.
>
> My second and final farfetched guess is:
> - client-id is erroneously defined as float and there are float troubles
> (in which case not security but mere shame client-id was defined as a
> float would prevent me from posting the table definition).
>
> No more guesses will be made from here on by me. Without a table
> definition, I leave you to the people with better crystal balls.

Those are good guesses, and I appreciate your assistance. I'm probably
coming off as smarmy, but I'm just relaying information.

All I asked originally was if
"Am I getting the error because my UNIQUE key is too long? "
"Is there a way to actually look at the values for the keys in my
table? "

If you are choosing to answer more than "No, no", then I appreciate
your willingness to go the extra mile to help me troubleshoot me
troubleshoot my problem, and I apologize that I could not provide the
additional information. It's not my decision to make.

All the arguments that others have made on this list are valid and
reasonable to me as a programmer; the problem is, I don't work for a
programmer. I work for a business person, who has a different idea
about the value of code they've bought.

On Wed, 23 Apr 2008 07:22:12 -0700 (PDT), lawpoop@gmail.com wrote:
> On Apr 23, 9:14 am, "Peter H. Coffin" <hell...@ninehells.com> wrote:
>>
>> > Well, if we have a database that's available to the public through a
>> > website, and some entreprising hacker wants to do an SQL injection,
>> > they would get quite a leg up if they could look up the exact names of
>> > our fields and tables.
>>
>> *cough* If said hacker can amanage and injection, she can ask the
>> database about the tables and column names. Your help isn't needed.
>
> If said hacker is injecting using an account with limited permissions,
> they can't ask general questions about the database structure. Well,
> they can ask, but they won't get the answer they want. : )
>
> They can only inject with the permissions that their account grants
> them, unless they can escalate permission. So, if they don't have
> permissions for "SHOW TABLES FROM database" or "DESCRIBE table", then
> they would have to guess table and field names -- unless, say, we were
> to tell them what they are in a usenet group.

That is, unfortunately, not the case.

$ mysql -u altgothic -p altgothic
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 87511
Server version: 5.0.33-log OpenBSD port: mysql-server-5.0.33

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> show tables;
+---------------------+
| Tables_in_altgothic |
+---------------------+
| bids |
| c10vote |
| c11attend |
| c11vote |
| c12import |
| c12vote |
| c8vote |
| c9vote |
| foo |
| itemtype |
| news |
| pingbounce |
| pingbounce_copy |
| purchase |
| purchase_item |
| user_old |
| users |
| users_copy |
| vote |
+---------------------+
19 rows in set (0.00 sec)

mysql> describe users;
+---------------+-----------------------------------+------+-----+---------------------+----------------+
| Field | Type | Null | Key |
Default | Extra |
+---------------+-----------------------------------+------+-----+---------------------+----------------+
| user_seq | int(10) unsigned zerofill | NO | PRI | NULL
| auto_increment |
| id | varchar(19) | NO | MUL |
| |
| name | varchar(24) | YES | | NULL
| |
| password | varchar(32) | YES | | NULL
| |
| nick | varchar(24) | YES | | NULL
| |
| email | varchar(60) | YES | UNI | NULL
| |
| city | varchar(32) | YES | | NULL
| |
| locale | varchar(32) | YES | | NULL
| |
| country | varchar(32) | YES | | NULL
| |
| postal_code | varchar(24) | YES | | NULL
| |
| datasource | varchar(24) | YES | |
Self-registration | |
| validation | enum('valid','invalid','pending') | NO | |
pending | |
| admin_flag | enum('N','Y') | NO | | N
| |
| updated | timestamp | NO | |
CURRENT_TIMESTAMP | |
| created | timestamp | NO | |
0000-00-00 00:00:00 | |
| change_reason | varchar(80) | YES | | NULL
| |
+---------------+-----------------------------------+------+-----+---------------------+----------------+
16 rows in set (0.02 sec)

mysql> show grants for current_user;
+------------------------------------------------------------------------------------------------------------------------------------------------+
| Grants for altgothic@%
|
+------------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'altgothic'@'%' IDENTIFIED BY PASSWORD
'xxxxxxxxxxxxxxxx'
|
| GRANT SELECT, INSERT, UPDATE, DELETE ON `altgothic`.* TO
'altgothic'@'%'
|
| GRANT SELECT, INSERT, UPDATE, DELETE ON `ag_wiki`.* TO 'altgothic'@'%'
|
+------------------------------------------------------------------------------------------------------------------------------------------------+
3 rows in set (0.00 sec)

mysql> quit
Bye
$

In case you're not sure about it, the GRANT USAGE means no privs except
those explicitly assigned [1]. This user can manipulate data only, not
structure, yet has no trouble using those functions you seem to think
would not be accessable to a restricted role user ID.

I am glad you posted here. You will have an opportunity to reassess some
of your security strategy.

[1] http://dev.mysql.com/doc/refman/5.0/en/grant.html

--
"I know it's a buzzword [...], but fsckit, 'Enterprise' editions of things
*should* come with the phasers and photon torpedos and all.
Of course, the first vendor freebie you'd get would be a red shirt..."
-- Anthony de Boer in the Monastery

On Apr 23, 10:26 am, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> On 23 Apr, 14:22, lawp...@gmail.com wrote:> On Apr 23, 9:14 am, "Peter H. Coffin" <hell...@ninehells.com> wrote:
>
> And of course, it is totally beyond you to export the structure and
> just rename the fields.
>
> But I guess that takes a modicum of intelligence.

It's not *totally* beyond me, but it would be an extra, unnecessary
step. I got the answers I was asking for:

Steve Lefevre
"Am I getting the error because my UNIQUE key is too long? This is
MySQL 5.0.24a.

Is there a way to actually look at the values for the keys in my
table? "

Rik Wasmus:
"mysql> insert into unique_test value
('12345678912345678912345678912345',2);
Query OK, 1 row affected (0.01 sec)"

No problems here whatsoever. Your UNIQUE is not properly created.
The
fastest way to show the key is by issuing a SHOW CREATE TABLE
<tablename>;
query. "

Doing more work isn't going to change the answers.

On Wed, 23 Apr 2008 07:53:35 -0700 (PDT), lawpoop@gmail.com wrote:
> On Apr 22, 4:25 pm, "Rik Wasmus" <luiheidsgoe...@hotmail.com> wrote:
>> My first guess (and almost certainly the correct one) is:
>> - the UNIQUE is NOT defined properly, or there are more then 1 UNIQUE keys
>> defined on the same table.
>>
>> My second and final farfetched guess is:
>> - client-id is erroneously defined as float and there are float troubles
>> (in which case not security but mere shame client-id was defined as a
>> float would prevent me from posting the table definition).
>>
>> No more guesses will be made from here on by me. Without a table
>> definition, I leave you to the people with better crystal balls.
>
> Those are good guesses, and I appreciate your assistance. I'm probably
> coming off as smarmy, but I'm just relaying information.
>
> All I asked originally was if
> "Am I getting the error because my UNIQUE key is too long? "
> "Is there a way to actually look at the values for the keys in my
> table? "
>
> If you are choosing to answer more than "No, no", then I appreciate

It's probably more "not in this case from the visible sample, no", but
that doesn't change this instance. Unique keys can get kind of funny
when you're dealing with large objects. But the hash you've chosen
indicates that you've probably intentionally sidestepped that issue.

> your willingness to go the extra mile to help me troubleshoot me
> troubleshoot my problem, and I apologize that I could not provide the
> additional information. It's not my decision to make.

See, now THAT is a fine reason not to share the structure. "Can't, for
internal political reasons. Thanks for your time" is always acceptable,
as are NDAs or even "don't feel like it". The price for those things is
that we can't give much help, and that's usually a pretty small price.
Very few folks here know anything that's not in the doco anyway; we
(collectively) just may be able to cross-corollate faster than one brain
does in a particular instance.

--
Revenge is an integral part of forgiving and forgetting.
-- The BOFH

On 23 Apr, 15:06, lawp...@gmail.com wrote:
> On Apr 23, 10:26 am, Captain Paralytic <paul_laut...@yahoo.com> wrote:
>
> > On 23 Apr, 14:22, lawp...@gmail.com wrote:> On Apr 23, 9:14 am, "Peter H. Coffin" <hell...@ninehells.com> wrote:
>
> > And of course, it is totally beyond you to export the structure and
> > just rename the fields.
>
> > But I guess that takes a modicum of intelligence.
>
> It's not *totally* beyond me, but it would be an extra, unnecessary
> step. I got the answers I was asking for:
>
> Steve Lefevre
> "Am I getting the error because my UNIQUE key is too long? This is
> MySQL 5.0.24a.
>
> Is there a way to actually look at the values for the keys in my
> table? "
>
> Rik Wasmus:
> "mysql> insert into unique_test value
> ('12345678912345678912345678912345',2);
> Query OK, 1 row affected (0.01 sec)"
>
> No problems here whatsoever. Your UNIQUE is not properly created.
> The
> fastest way to show the key is by issuing a SHOW CREATE TABLE
> <tablename>;
> query. "
>
> Doing more work isn't going to change the answers.

But you didn't bother to tell anybody that you had solved it.

On Apr 23, 11:28 am, Captain Paralytic <paul_laut...@yahoo.com> wrote:

> But you didn't bother to tell anybody that you had solved it.

I haven't solved it. Right now, I'm working on other parts of the
project where I'm getting more done. I'll come back to my bug later,
since it appears to be a timesink. Another poster demonstrated to me
that my simple suspicion of what was wrong could not be the case, so
now I know which avenues of attack not to pursue.

I didn't ask anybody to solve my problem. All that's happened is that
I asked a few questions about MySQL, and they got answered. Since I
could not post my specific table structure, I deliberately posted
general questions about MySQL that could be answered without knowing
the specific table structure. People wondered why I wouldn't post the
table structure, and I tried to answer the questions as best as I
could. In retrospect I probably could have done a better job
communicating those reasons.