Need good idea

Hi guys

We have a following problem. For security reasons in each table in our
DB we have addition field which is calculated as hash value of all
columns in particular row.

Every time when some field in particular row is changed we create and
call select query from our application to obtain all fields for this
row and then re-calculate and update the hash value again.

Obviously such approach is very ineffective, the alternative is to
create trigger on update event and then execute stored procedure which
will re-calculate and update the hash value. The problem with this
approach is that end user could then change the date in the tables and
then run this store procedure to adjust hash value.

We are looking for some solution that could speed up the hash value
updating without allowing authorized user to do it

Thanks in advance,
LeonVlad Olevsky wrote:
> Hi guys
> We have a following problem. For security reasons in each table in our
> DB we have addition field which is calculated as hash value of all
> columns in particular row.
> Every time when some field in particular row is changed we create and
> call select query from our application to obtain all fields for this
> row and then re-calculate and update the hash value again.
> Obviously such approach is very ineffective, the alternative is to
> create trigger on update event and then execute stored procedure which
> will re-calculate and update the hash value. The problem with this
> approach is that end user could then change the date in the tables and
> then run this store procedure to adjust hash value.
> We are looking for some solution that could speed up the hash value
> updating without allowing authorized user to do it
> Thanks in advance,
> Leon
In DB2 for LUW you can define the column as a generated column.
I presume you have some sort of UDF already that does the actually
hashing. Last I heard SS 2005 will have persistent generated columns as
well.
In general (x-product) you can use a combination of a check constraint
and (before) triggers.

One must but wonder WHY this column is required. Are you affraid of
corruption or sabotage?

Cheers
Serge
--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab|||"Vlad Olevsky" <leonid4142@.yahoo.com> schrieb im Newsbeitrag news:50540181.0505030658.64f68390@.posting.google.c om...
> Obviously such approach is very ineffective, the alternative is to
> create trigger on update event and then execute stored procedure which
> will re-calculate and update the hash value. The problem with this
> approach is that end user could then change the date in the tables and
> then run this store procedure to adjust hash value.
> We are looking for some solution that could speed up the hash value
> updating without allowing authorized user to do it
As Frank pointed out, try to create a trigger which calls a function.
Let the function run with the grants of the caller and give only
authorized callers the exec grant of the function.

Greetings!
Volker|||Vlad Olevsky wrote:

> Hi guys
> We have a following problem. For security reasons in each table in our
> DB we have addition field which is calculated as hash value of all
> columns in particular row.
> Every time when some field in particular row is changed we create and
> call select query from our application to obtain all fields for this
> row and then re-calculate and update the hash value again.
> Obviously such approach is very ineffective, the alternative is to
> create trigger on update event and then execute stored procedure which
> will re-calculate and update the hash value. The problem with this
> approach is that end user could then change the date in the tables and
> then run this store procedure to adjust hash value.
> We are looking for some solution that could speed up the hash value
> updating without allowing authorized user to do it
> Thanks in advance,
> Leon

This may come as a shock to you Leon but the solution in each of the
products whose usenet group you copied on this uses a completely
different solution.

I'd suggest you start by apologizing, to all, for your lack of
identifying the product and version and for posting to every usenet
group you can spell.

And then repost in the one, and only, group where your query is
appropriate.

Thank you.
--
Daniel A. Morgan
University of Washington
damorgan@.x.washington.edu
(replace 'x' with 'u' to respond)|||Serge Rielau (srielau@.ca.ibm.com) writes:
> In DB2 for LUW you can define the column as a generated column.
> I presume you have some sort of UDF already that does the actually
> hashing. Last I heard SS 2005 will have persistent generated columns as
> well.

Actually, SQL 2000 has it as well. The difference is that PERSISTED is
a keyword in SQL 2005, and, I assume, that in SQL 2005 you can persist
a computed colum, without indexing it.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Erland Sommarskog wrote:
> Serge Rielau (srielau@.ca.ibm.com) writes:
>>In DB2 for LUW you can define the column as a generated column.
>>I presume you have some sort of UDF already that does the actually
>>hashing. Last I heard SS 2005 will have persistent generated columns as
>>well.
>
> Actually, SQL 2000 has it as well. The difference is that PERSISTED is
> a keyword in SQL 2005, and, I assume, that in SQL 2005 you can persist
> a computed colum, without indexing it.
Yes, in SS2000 the generated column is virtual (i.e. not persisted). The
planned syntax in the standard is "GENERATED BY REFERENCE", being the
default for compatibility with SS2000.

Cheers
Serge
--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab|||Serge Rielau (srielau@.ca.ibm.com) writes:
> Yes, in SS2000 the generated column is virtual (i.e. not persisted).

Unless, as I said, it is indexed, in which case it is implicitly persisted.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Need example of a "Hash" function.....

Many articles on sql server security make reference to Hash functions. Do you know of a simple example of a hash function that I could show to others?

For example, would taking the first eight bytes of the mathematical "sin" of a number be a good function? I don't know. Or is a hash "function" actually an involved algorithm, so the "simple" formula I was looking for really doesn't exist.

TIA,

Barkingdog

In SQL Server 2005 we have a new builtin to calculate hash functions: HashBytes.

For more details on this builtin I recommend consulting BOL (http://msdn2.microsoft.com/en-us/library/ms174415.aspx), but here is a short example:

SELECT HashBytes( 'sha1', '1234' )

-- returns 0x7110EDA4D09E062AA5E4A390B0A572AC0D2C0220

SELECT HashBytes( 'md5', '1234' )

--returns 0x81DC9BDB52D04DC20036DBD8313ED055

-Raul Garcia

SDE/T

SQL Server Engine

|||

I have read that both MD5 and SHA1 (its successor) have been "compromised". Is this true?

Barkingdog

Need a good idea

Hi guys
We have a following problem. For security reasons in each table in our
DB we have addition field which is calculated as hash value of all
columns in particular row.
Every time when some field in particular row is changed we create and
call select query from our application to obtain all fields for this
row and then re-calculate and update the hash value again.
Obviously such approach is very ineffective, the alternative is to
create trigger on updating event and then execute stored procedure
which will re-calculate and update the hash value. The problem with
this approach is that end user could then change the date in the
tables and then run this stored procedure to adjust hash value.
We are looking for some solution that could speed up the hash value
updating without allowing unauthorized user to do itHave you checked out CHECKSUM() in BOL?
"Vlad Olevsky" <leonid4142@.yahoo.com> wrote in message
news:50540181.0505030708.b3397b6@.posting.google.com...
> Hi guys
> We have a following problem. For security reasons in each table in our
> DB we have addition field which is calculated as hash value of all
> columns in particular row.
> Every time when some field in particular row is changed we create and
> call select query from our application to obtain all fields for this
> row and then re-calculate and update the hash value again.
> Obviously such approach is very ineffective, the alternative is to
> create trigger on updating event and then execute stored procedure
> which will re-calculate and update the hash value. The problem with
> this approach is that end user could then change the date in the
> tables and then run this stored procedure to adjust hash value.
> We are looking for some solution that could speed up the hash value
> updating without allowing unauthorized user to do it|||If you want to enforce that values can only be changed through your
application, the best way to do that is make sure that only your application
has permissions to use certain stored procedures and tables. For this you
can use application roles.
Having a trigger on the table to calculate the hash value won't do anything
useful, because anyone who updates the table, will fire that trigger and the
hash value will updated correctly.
Jacco Schalkwijk
SQL Server MVP
"Vlad Olevsky" <leonid4142@.yahoo.com> wrote in message
news:50540181.0505030708.b3397b6@.posting.google.com...
> Hi guys
> We have a following problem. For security reasons in each table in our
> DB we have addition field which is calculated as hash value of all
> columns in particular row.
> Every time when some field in particular row is changed we create and
> call select query from our application to obtain all fields for this
> row and then re-calculate and update the hash value again.
> Obviously such approach is very ineffective, the alternative is to
> create trigger on updating event and then execute stored procedure
> which will re-calculate and update the hash value. The problem with
> this approach is that end user could then change the date in the
> tables and then run this stored procedure to adjust hash value.
> We are looking for some solution that could speed up the hash value
> updating without allowing unauthorized user to do it|||How are you using this hash value? Is it supposed to provide some
user-authentication? Without understanding the application of this it's
difficult to recommend an alternative.
David Portas
SQL Server MVP
--|||If the Checksum() function is not sufficient, you might try a computed colum
n.
Thomas
"Vlad Olevsky" <leonid4142@.yahoo.com> wrote in message
news:50540181.0505030708.b3397b6@.posting.google.com...
> Hi guys
> We have a following problem. For security reasons in each table in our
> DB we have addition field which is calculated as hash value of all
> columns in particular row.
> Every time when some field in particular row is changed we create and
> call select query from our application to obtain all fields for this
> row and then re-calculate and update the hash value again.
> Obviously such approach is very ineffective, the alternative is to
> create trigger on updating event and then execute stored procedure
> which will re-calculate and update the hash value. The problem with
> this approach is that end user could then change the date in the
> tables and then run this stored procedure to adjust hash value.
> We are looking for some solution that could speed up the hash value
> updating without allowing unauthorized user to do it|||Jacco raised a very good point. If your intent is to store a hash value of
some sort to indicate that a row has not been tampered with by any means
outside of your application, you should probably generate the hash code and
insert it from the application side, not via a trigger or other mechanism
internal to the database that users would have access to via QA.
"Vlad Olevsky" <leonid4142@.yahoo.com> wrote in message
news:50540181.0505030708.b3397b6@.posting.google.com...
> Hi guys
> We have a following problem. For security reasons in each table in our
> DB we have addition field which is calculated as hash value of all
> columns in particular row.
> Every time when some field in particular row is changed we create and
> call select query from our application to obtain all fields for this
> row and then re-calculate and update the hash value again.
> Obviously such approach is very ineffective, the alternative is to
> create trigger on updating event and then execute stored procedure
> which will re-calculate and update the hash value. The problem with
> this approach is that end user could then change the date in the
> tables and then run this stored procedure to adjust hash value.
> We are looking for some solution that could speed up the hash value
> updating without allowing unauthorized user to do it|||you could continue to use a trigger, but the trigger only does something if
called by your application, so if someone changed a row via query analyser
the trigger will not fire.. see below
create trigger mytrigger on mytable after update
as
begin
if app_name() = 'myapp'
begin
' do stuff here
end
end
go
"Vlad Olevsky" <leonid4142@.yahoo.com> wrote in message
news:50540181.0505030708.b3397b6@.posting.google.com...
> Hi guys
> We have a following problem. For security reasons in each table in our
> DB we have addition field which is calculated as hash value of all
> columns in particular row.
> Every time when some field in particular row is changed we create and
> call select query from our application to obtain all fields for this
> row and then re-calculate and update the hash value again.
> Obviously such approach is very ineffective, the alternative is to
> create trigger on updating event and then execute stored procedure
> which will re-calculate and update the hash value. The problem with
> this approach is that end user could then change the date in the
> tables and then run this stored procedure to adjust hash value.
> We are looking for some solution that could speed up the hash value
> updating without allowing unauthorized user to do it|||Thanks Mark!
The only one remark. To prevent end-user from looking and modifying the
trigger code we could create trigger using 'WITH ENCRYPTION' flag.
This flag encrypts the syscomments entries that contain the text of
CREATE TRIGGER. Using WITH ENCRYPTION prevents the trigger from being
published as part of SQL Server replication. So tamper will never know
what we check within trigger.
Mark wrote:
> you could continue to use a trigger, but the trigger only does
something if
> called by your application, so if someone changed a row via query
analyser
> the trigger will not fire.. see below
> create trigger mytrigger on mytable after update
> as
> begin
> if app_name() = 'myapp'
> begin
> ' do stuff here
> end
> end
> go
> "Vlad Olevsky" <leonid4142@.yahoo.com> wrote in message
> news:50540181.0505030708.b3397b6@.posting.google.com...
our
and
this