It seems the authority for DBA is too much to control the safety of .mdf
, why not add an additional password or key to protect it, if someone
copy the .mdf files and install to a new sql server service, they can
read everything using sa facility, is it worse than ms.access ?
at least ms.access still need some extra job to crack it, but the .mdf
is too simple, just copy and read it.
Especially the MSDE version in one single computer, even the hardware
technician can duplicate and sell your important data.
Anyone have solution for this security problem ?
Best regards,
Ridwan
PemBukuan.Com
http://www.as3000.com
RW,
Security in general is said to start with the physical box - once this is
compromised then there's little you can do (eg Linux can be used to bypass
NTFS so file system security doesn't help). SQL Server security itself is
based on logins, users and permissions/roles, all of which exist in the
database file, so, after the box is accessed (compromised), someone needs to
be able to access/compromise the file.
There's no simple solution apart from securing the box and the files; you
can password protect your backups but not the datafiles.
Regards,
Paul Ibison
|||Why not MS add an additional physics login password as an option ? just
like what we have in excel, word, access ? I know that kind of password
is too simple, they can build a more advance password, I think may be
they don't want to take the risk of while users forget the password.
If developer want to distribute an application with safe and small
capacity database, then I think the MSDE is not a choice.
Paul Ibison wrote:
> RW,
> Security in general is said to start with the physical box - once this is
> compromised then there's little you can do (eg Linux can be used to bypass
> NTFS so file system security doesn't help). SQL Server security itself is
> based on logins, users and permissions/roles, all of which exist in the
> database file, so, after the box is accessed (compromised), someone needs to
> be able to access/compromise the file.
> There's no simple solution apart from securing the box and the files; you
> can password protect your backups but not the datafiles.
> Regards,
> Paul Ibison
sql
Showing posts with label mdf. Show all posts
Showing posts with label mdf. Show all posts
Wednesday, March 21, 2012
ms sql server 2000 too weak ?
It seems the authority for DBA is too much to control the safety of .mdf
, why not add an additional password or key to protect it, if someone
copy the .mdf files and install to a new sql server service, they can
read everything using sa facility, is it worse than ms.access ?
at least ms.access still need some extra job to crack it, but the .mdf
is too simple, just copy and read it.
Especially the MSDE version in one single computer, even the hardware
technician can duplicate and sell your important data.
Anyone have solution for this security problem ?
--
Best regards,
Ridwan
--
PemBukuan.Com
http://www.as3000.comRW,
Security in general is said to start with the physical box - once this is
compromised then there's little you can do (eg Linux can be used to bypass
NTFS so file system security doesn't help). SQL Server security itself is
based on logins, users and permissions/roles, all of which exist in the
database file, so, after the box is accessed (compromised), someone needs to
be able to access/compromise the file.
There's no simple solution apart from securing the box and the files; you
can password protect your backups but not the datafiles.
Regards,
Paul Ibison|||Why not MS add an additional physics login password as an option ? just
like what we have in excel, word, access ? I know that kind of password
is too simple, they can build a more advance password, I think may be
they don't want to take the risk of while users forget the password.
If developer want to distribute an application with safe and small
capacity database, then I think the MSDE is not a choice.
Paul Ibison wrote:
> RW,
> Security in general is said to start with the physical box - once this is
> compromised then there's little you can do (eg Linux can be used to bypass
> NTFS so file system security doesn't help). SQL Server security itself is
> based on logins, users and permissions/roles, all of which exist in the
> database file, so, after the box is accessed (compromised), someone needs to
> be able to access/compromise the file.
> There's no simple solution apart from securing the box and the files; you
> can password protect your backups but not the datafiles.
> Regards,
> Paul Ibison
--
, why not add an additional password or key to protect it, if someone
copy the .mdf files and install to a new sql server service, they can
read everything using sa facility, is it worse than ms.access ?
at least ms.access still need some extra job to crack it, but the .mdf
is too simple, just copy and read it.
Especially the MSDE version in one single computer, even the hardware
technician can duplicate and sell your important data.
Anyone have solution for this security problem ?
--
Best regards,
Ridwan
--
PemBukuan.Com
http://www.as3000.comRW,
Security in general is said to start with the physical box - once this is
compromised then there's little you can do (eg Linux can be used to bypass
NTFS so file system security doesn't help). SQL Server security itself is
based on logins, users and permissions/roles, all of which exist in the
database file, so, after the box is accessed (compromised), someone needs to
be able to access/compromise the file.
There's no simple solution apart from securing the box and the files; you
can password protect your backups but not the datafiles.
Regards,
Paul Ibison|||Why not MS add an additional physics login password as an option ? just
like what we have in excel, word, access ? I know that kind of password
is too simple, they can build a more advance password, I think may be
they don't want to take the risk of while users forget the password.
If developer want to distribute an application with safe and small
capacity database, then I think the MSDE is not a choice.
Paul Ibison wrote:
> RW,
> Security in general is said to start with the physical box - once this is
> compromised then there's little you can do (eg Linux can be used to bypass
> NTFS so file system security doesn't help). SQL Server security itself is
> based on logins, users and permissions/roles, all of which exist in the
> database file, so, after the box is accessed (compromised), someone needs to
> be able to access/compromise the file.
> There's no simple solution apart from securing the box and the files; you
> can password protect your backups but not the datafiles.
> Regards,
> Paul Ibison
--
ms sql server 2000 too weak ?
It seems the authority for DBA is too much to control the safety of .mdf
, why not add an additional password or key to protect it, if someone
copy the .mdf files and install to a new sql server service, they can
read everything using sa facility, is it worse than ms.access ?
at least ms.access still need some extra job to crack it, but the .mdf
is too simple, just copy and read it.
Especially the MSDE version in one single computer, even the hardware
technician can duplicate and sell your important data.
Anyone have solution for this security problem ?
Best regards,
Ridwan
--
PemBukuan.Com
http://www.as3000.comRW,
Security in general is said to start with the physical box - once this is
compromised then there's little you can do (eg Linux can be used to bypass
NTFS so file system security doesn't help). SQL Server security itself is
based on logins, users and permissions/roles, all of which exist in the
database file, so, after the box is accessed (compromised), someone needs to
be able to access/compromise the file.
There's no simple solution apart from securing the box and the files; you
can password protect your backups but not the datafiles.
Regards,
Paul Ibison|||Why not MS add an additional physics login password as an option ? just
like what we have in excel, word, access ? I know that kind of password
is too simple, they can build a more advance password, I think may be
they don't want to take the risk of while users forget the password.
If developer want to distribute an application with safe and small
capacity database, then I think the MSDE is not a choice.
Paul Ibison wrote:
> RW,
> Security in general is said to start with the physical box - once this is
> compromised then there's little you can do (eg Linux can be used to bypass
> NTFS so file system security doesn't help). SQL Server security itself is
> based on logins, users and permissions/roles, all of which exist in the
> database file, so, after the box is accessed (compromised), someone needs
to
> be able to access/compromise the file.
> There's no simple solution apart from securing the box and the files; you
> can password protect your backups but not the datafiles.
> Regards,
> Paul Ibison
, why not add an additional password or key to protect it, if someone
copy the .mdf files and install to a new sql server service, they can
read everything using sa facility, is it worse than ms.access ?
at least ms.access still need some extra job to crack it, but the .mdf
is too simple, just copy and read it.
Especially the MSDE version in one single computer, even the hardware
technician can duplicate and sell your important data.
Anyone have solution for this security problem ?
Best regards,
Ridwan
--
PemBukuan.Com
http://www.as3000.comRW,
Security in general is said to start with the physical box - once this is
compromised then there's little you can do (eg Linux can be used to bypass
NTFS so file system security doesn't help). SQL Server security itself is
based on logins, users and permissions/roles, all of which exist in the
database file, so, after the box is accessed (compromised), someone needs to
be able to access/compromise the file.
There's no simple solution apart from securing the box and the files; you
can password protect your backups but not the datafiles.
Regards,
Paul Ibison|||Why not MS add an additional physics login password as an option ? just
like what we have in excel, word, access ? I know that kind of password
is too simple, they can build a more advance password, I think may be
they don't want to take the risk of while users forget the password.
If developer want to distribute an application with safe and small
capacity database, then I think the MSDE is not a choice.
Paul Ibison wrote:
> RW,
> Security in general is said to start with the physical box - once this is
> compromised then there's little you can do (eg Linux can be used to bypass
> NTFS so file system security doesn't help). SQL Server security itself is
> based on logins, users and permissions/roles, all of which exist in the
> database file, so, after the box is accessed (compromised), someone needs
to
> be able to access/compromise the file.
> There's no simple solution apart from securing the box and the files; you
> can password protect your backups but not the datafiles.
> Regards,
> Paul Ibison
ms sql server 2000 security too weak ?
It seems the authority for DBA is too much to control the safety of .mdf
, why not add an additional password or key to protect it, if someone
copy the .mdf files and install to a new sql server service, they can
read everything using sa facility, is it worse than ms.access ?
at least ms.access still need some extra job to crack it, but the .mdf
is too simple, just copy and read it.
Especially the MSDE version in one single computer, even the hardware
technician can duplicate and sell your important data.
Anyone have solution for this security problem ?
Best regards,
Ridwan
--
PemBukuan.Com
http://www.as3000.com"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
You have a choice. Have MSDE run, on a reserved account
- NTFS security
- Data Encryption
- Also, you can store data on a raw partition, that cannot be copied so
easily.
b.t.w. there is nearly no protection against harddisk access by a
technician. You can't blame MS for that. But data encryption by the
application that uses MSDE is a solution...|||1. using NTFS security still allow to get in, and duplicate the
database, this is not why I mean, but they can copy and open it in
another server without any protection.
2. using data encryption of course will slow down the performance while
we process large amount of data
I am not blaming MS, actually the sql server is quite a good and easy to
maintain database, only we are so curious, why other user data like
excel spreadsheet, word, access can have their own password, and
specially the most important data container (sql server) open like a
mall and welcome in, u just login in as 'sa' and u get everything.
Why not MS add an additional login password as an option, may be that's
much better than let it open.
> You have a choice. Have MSDE run, on a reserved account
> - NTFS security
> - Data Encryption
> - Also, you can store data on a raw partition, that cannot be copied so
> easily.
> b.t.w. there is nearly no protection against harddisk access by a
> technician. You can't blame MS for that. But data encryption by the
> application that uses MSDE is a solution...|||"RW" <goldbase@.centrin.net.id> wrote in message
news:407AB799.4F6F@.centrin.net.id...
> 1. using NTFS security still allow to get in, and duplicate the
> database, this is not why I mean, but they can copy and open it in
> another server without any protection.
> 2. using data encryption of course will slow down the performance while
> we process large amount of data
see below...
> I am not blaming MS, actually the sql server is quite a good and easy to
> maintain database, only we are so curious, why other user data like
> excel spreadsheet, word, access can have their own password, and
> specially the most important data container (sql server) open like a
> mall and welcome in, u just login in as 'sa' and u get everything.
> Why not MS add an additional login password as an option, may be that's
> much better than let it open.
Applying a single password is really a nope-operation. for instance, SQL
stored procs can be encrypted, but they can be decripted using 'tools' that
are available on the net.
So that's why the 'slow' operation, that is a 3 key-algorithm
(public/private/session) is the ONLY viable solution to safegard a file. A
single password with 'xor' encryption on a file is as explained, useless.
Cheers,|||hi
what is necessary to do for encrypt data?
atte,
Hernn Castelo
UTN Buenos Aires
. . . . . . . . . . . . . . . . . . . . . . . . .
.
"Egbert Nierop (MVP for IIS)" <egbert_nierop@.nospam.invalid> escribi en el
mensaje
news:uj3L1IFIEHA.3356@.TK2MSFTNGP11.phx.gbl...
"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
You have a choice. Have MSDE run, on a reserved account
- NTFS security
- Data Encryption
- Also, you can store data on a raw partition, that cannot be copied so
easily.
b.t.w. there is nearly no protection against harddisk access by a
technician. You can't blame MS for that. But data encryption by the
application that uses MSDE is a solution...|||> "Egbert Nierop (MVP for IIS)" <egbert_nierop@.nospam.invalid> escribi en
el mensaje
> news:uj3L1IFIEHA.3356@.TK2MSFTNGP11.phx.gbl...
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:4079FBD2.559B@.centrin.net.id...
> You have a choice. Have MSDE run, on a reserved account
> - NTFS security
> - Data Encryption
> - Also, you can store data on a raw partition, that cannot be copied so
> easily.
"Hernn Castelo" <hhh@.hotmail.com> wrote in message
news:%23KshfkMIEHA.3476@.TK2MSFTNGP11.phx.gbl...
> hi
> what is necessary to do for encrypt data?
> --
> atte,
> Hernn Castelo
> UTN Buenos Aires
> . . . . . . . . . . . . . . . . . . . . . . . . .
.
Your application can encrypt data. If you have .NET you can use Rijnhaeve
(If I spell correctly) and such. .NET samples show how to do it.
With C++ (7.0 and higher) there are encryption templates as well.|||You didn't get my question, what I mean is if your database which you
have protect with the algorithm and re-install by somebody in their
server, then all your data will be seen and access using their 'sa'
login, so where's the protection ?
Egbert Nierop (MVP for IIS) wrote:
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:407AB799.4F6F@.centrin.net.id...
> see below...
>
> Applying a single password is really a nope-operation. for instance, SQL
> stored procs can be encrypted, but they can be decripted using 'tools' tha
t
> are available on the net.
> So that's why the 'slow' operation, that is a 3 key-algorithm
> (public/private/session) is the ONLY viable solution to safegard a file. A
> single password with 'xor' encryption on a file is as explained, useless.
> Cheers,|||If the user is an administrator of the SQL Server, then they can steal your
MDF files. But then, they can do anything anyway.
If the user is an administrator of the Windows machine that SQL Server is
on, then they can steal everything on the server anyway.
Normal users can not do this.
So, you need to trust your administrators.
Anyway, even if there was a "separate" password, how would your applications
access the database? They would need the password, which means it has to be
stored somewhere, which means the administrator could steal it from there
(eg from the client application, or by monitoring the traffic that goes into
SQL Server).
Cheers
Ken
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~
"RW" <goldbase@.centrin.net.id> wrote in message
news:407B4E73.682C@.centrin.net.id...
: You didn't get my question, what I mean is if your database which you
: have protect with the algorithm and re-install by somebody in their
: server, then all your data will be seen and access using their 'sa'
: login, so where's the protection ?
:
:
:
: Egbert Nierop (MVP for IIS) wrote:
: >
: > "RW" <goldbase@.centrin.net.id> wrote in message
: > news:407AB799.4F6F@.centrin.net.id...
: > > 1. using NTFS security still allow to get in, and duplicate the
: > > database, this is not why I mean, but they can copy and open it in
: > > another server without any protection.
: > >
: > > 2. using data encryption of course will slow down the performance
while
: > > we process large amount of data
: >
: > see below...
: >
: > > I am not blaming MS, actually the sql server is quite a good and easy
to
: > > maintain database, only we are so curious, why other user data like
: > > excel spreadsheet, word, access can have their own password, and
: > > specially the most important data container (sql server) open like a
: > > mall and welcome in, u just login in as 'sa' and u get everything.
: > >
: > > Why not MS add an additional login password as an option, may be
that's
: > > much better than let it open.
: >
: > Applying a single password is really a nope-operation. for instance, SQL
: > stored procs can be encrypted, but they can be decripted using 'tools'
that
: > are available on the net.
: > So that's why the 'slow' operation, that is a 3 key-algorithm
: > (public/private/session) is the ONLY viable solution to safegard a file.
A
: > single password with 'xor' encryption on a file is as explained,
useless.
: >
: > Cheers,
:|||Sometimes trusting people too full is risky to the company, it should be
a double checking procedure and control by two authorized person.
About the monitoring data traffic is not very easy do that if the
application using a native database driver, except ODBC.
My suggestion is when attaching the MDF files will require the original
serial number of ms.sql server 2000 where it was created, I think at
least this is another way to protect the MDF files, even somebody or the
kick out administrator copy it, then it's useless, they should know the
serial number to access the MDF.
What do you think ?
brgs,
Ridwan
Ken Schaefer wrote:
> If the user is an administrator of the SQL Server, then they can steal you
r
> MDF files. But then, they can do anything anyway.
> If the user is an administrator of the Windows machine that SQL Server is
> on, then they can steal everything on the server anyway.
> Normal users can not do this.
> So, you need to trust your administrators.
> Anyway, even if there was a "separate" password, how would your applicatio
ns
> access the database? They would need the password, which means it has to b
e
> stored somewhere, which means the administrator could steal it from there
> (eg from the client application, or by monitoring the traffic that goes in
to
> SQL Server).
> Cheers
> Ken
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:407B4E73.682C@.centrin.net.id...
> : You didn't get my question, what I mean is if your database which you
> : have protect with the algorithm and re-install by somebody in their
> : server, then all your data will be seen and access using their 'sa'
> : login, so where's the protection ?
> :
> :
> :
> : Egbert Nierop (MVP for IIS) wrote:
> : >
> : > "RW" <goldbase@.centrin.net.id> wrote in message
> : > news:407AB799.4F6F@.centrin.net.id...
> : > > 1. using NTFS security still allow to get in, and duplicate the
> : > > database, this is not why I mean, but they can copy and open it in
> : > > another server without any protection.
> : > >
> : > > 2. using data encryption of course will slow down the performance
> while
> : > > we process large amount of data
> : >
> : > see below...
> : >
> : > > I am not blaming MS, actually the sql server is quite a good and eas
y
> to
> : > > maintain database, only we are so curious, why other user data like
> : > > excel spreadsheet, word, access can have their own password, and
> : > > specially the most important data container (sql server) open like a
> : > > mall and welcome in, u just login in as 'sa' and u get everything.
> : > >
> : > > Why not MS add an additional login password as an option, may be
> that's
> : > > much better than let it open.
> : >
> : > Applying a single password is really a nope-operation. for instance, S
QL
> : > stored procs can be encrypted, but they can be decripted using 'tools'
> that
> : > are available on the net.
> : > So that's why the 'slow' operation, that is a 3 key-algorithm
> : > (public/private/session) is the ONLY viable solution to safegard a fil
e.
> A
> : > single password with 'xor' encryption on a file is as explained,
> useless.
> : >
> : > Cheers,
> :|||> what is necessary to do for encrypt data?
>
Checkout www.database-encryption.com
www.sql-shield.com
, why not add an additional password or key to protect it, if someone
copy the .mdf files and install to a new sql server service, they can
read everything using sa facility, is it worse than ms.access ?
at least ms.access still need some extra job to crack it, but the .mdf
is too simple, just copy and read it.
Especially the MSDE version in one single computer, even the hardware
technician can duplicate and sell your important data.
Anyone have solution for this security problem ?
Best regards,
Ridwan
--
PemBukuan.Com
http://www.as3000.com"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
You have a choice. Have MSDE run, on a reserved account
- NTFS security
- Data Encryption
- Also, you can store data on a raw partition, that cannot be copied so
easily.
b.t.w. there is nearly no protection against harddisk access by a
technician. You can't blame MS for that. But data encryption by the
application that uses MSDE is a solution...|||1. using NTFS security still allow to get in, and duplicate the
database, this is not why I mean, but they can copy and open it in
another server without any protection.
2. using data encryption of course will slow down the performance while
we process large amount of data
I am not blaming MS, actually the sql server is quite a good and easy to
maintain database, only we are so curious, why other user data like
excel spreadsheet, word, access can have their own password, and
specially the most important data container (sql server) open like a
mall and welcome in, u just login in as 'sa' and u get everything.
Why not MS add an additional login password as an option, may be that's
much better than let it open.
> You have a choice. Have MSDE run, on a reserved account
> - NTFS security
> - Data Encryption
> - Also, you can store data on a raw partition, that cannot be copied so
> easily.
> b.t.w. there is nearly no protection against harddisk access by a
> technician. You can't blame MS for that. But data encryption by the
> application that uses MSDE is a solution...|||"RW" <goldbase@.centrin.net.id> wrote in message
news:407AB799.4F6F@.centrin.net.id...
> 1. using NTFS security still allow to get in, and duplicate the
> database, this is not why I mean, but they can copy and open it in
> another server without any protection.
> 2. using data encryption of course will slow down the performance while
> we process large amount of data
see below...
> I am not blaming MS, actually the sql server is quite a good and easy to
> maintain database, only we are so curious, why other user data like
> excel spreadsheet, word, access can have their own password, and
> specially the most important data container (sql server) open like a
> mall and welcome in, u just login in as 'sa' and u get everything.
> Why not MS add an additional login password as an option, may be that's
> much better than let it open.
Applying a single password is really a nope-operation. for instance, SQL
stored procs can be encrypted, but they can be decripted using 'tools' that
are available on the net.
So that's why the 'slow' operation, that is a 3 key-algorithm
(public/private/session) is the ONLY viable solution to safegard a file. A
single password with 'xor' encryption on a file is as explained, useless.
Cheers,|||hi
what is necessary to do for encrypt data?
atte,
Hernn Castelo
UTN Buenos Aires
. . . . . . . . . . . . . . . . . . . . . . . . .
.
"Egbert Nierop (MVP for IIS)" <egbert_nierop@.nospam.invalid> escribi en el
mensaje
news:uj3L1IFIEHA.3356@.TK2MSFTNGP11.phx.gbl...
"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
You have a choice. Have MSDE run, on a reserved account
- NTFS security
- Data Encryption
- Also, you can store data on a raw partition, that cannot be copied so
easily.
b.t.w. there is nearly no protection against harddisk access by a
technician. You can't blame MS for that. But data encryption by the
application that uses MSDE is a solution...|||> "Egbert Nierop (MVP for IIS)" <egbert_nierop@.nospam.invalid> escribi en
el mensaje
> news:uj3L1IFIEHA.3356@.TK2MSFTNGP11.phx.gbl...
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:4079FBD2.559B@.centrin.net.id...
> You have a choice. Have MSDE run, on a reserved account
> - NTFS security
> - Data Encryption
> - Also, you can store data on a raw partition, that cannot be copied so
> easily.
"Hernn Castelo" <hhh@.hotmail.com> wrote in message
news:%23KshfkMIEHA.3476@.TK2MSFTNGP11.phx.gbl...
> hi
> what is necessary to do for encrypt data?
> --
> atte,
> Hernn Castelo
> UTN Buenos Aires
> . . . . . . . . . . . . . . . . . . . . . . . . .
.
Your application can encrypt data. If you have .NET you can use Rijnhaeve
(If I spell correctly) and such. .NET samples show how to do it.
With C++ (7.0 and higher) there are encryption templates as well.|||You didn't get my question, what I mean is if your database which you
have protect with the algorithm and re-install by somebody in their
server, then all your data will be seen and access using their 'sa'
login, so where's the protection ?
Egbert Nierop (MVP for IIS) wrote:
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:407AB799.4F6F@.centrin.net.id...
> see below...
>
> Applying a single password is really a nope-operation. for instance, SQL
> stored procs can be encrypted, but they can be decripted using 'tools' tha
t
> are available on the net.
> So that's why the 'slow' operation, that is a 3 key-algorithm
> (public/private/session) is the ONLY viable solution to safegard a file. A
> single password with 'xor' encryption on a file is as explained, useless.
> Cheers,|||If the user is an administrator of the SQL Server, then they can steal your
MDF files. But then, they can do anything anyway.
If the user is an administrator of the Windows machine that SQL Server is
on, then they can steal everything on the server anyway.
Normal users can not do this.
So, you need to trust your administrators.
Anyway, even if there was a "separate" password, how would your applications
access the database? They would need the password, which means it has to be
stored somewhere, which means the administrator could steal it from there
(eg from the client application, or by monitoring the traffic that goes into
SQL Server).
Cheers
Ken
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~
"RW" <goldbase@.centrin.net.id> wrote in message
news:407B4E73.682C@.centrin.net.id...
: You didn't get my question, what I mean is if your database which you
: have protect with the algorithm and re-install by somebody in their
: server, then all your data will be seen and access using their 'sa'
: login, so where's the protection ?
:
:
:
: Egbert Nierop (MVP for IIS) wrote:
: >
: > "RW" <goldbase@.centrin.net.id> wrote in message
: > news:407AB799.4F6F@.centrin.net.id...
: > > 1. using NTFS security still allow to get in, and duplicate the
: > > database, this is not why I mean, but they can copy and open it in
: > > another server without any protection.
: > >
: > > 2. using data encryption of course will slow down the performance
while
: > > we process large amount of data
: >
: > see below...
: >
: > > I am not blaming MS, actually the sql server is quite a good and easy
to
: > > maintain database, only we are so curious, why other user data like
: > > excel spreadsheet, word, access can have their own password, and
: > > specially the most important data container (sql server) open like a
: > > mall and welcome in, u just login in as 'sa' and u get everything.
: > >
: > > Why not MS add an additional login password as an option, may be
that's
: > > much better than let it open.
: >
: > Applying a single password is really a nope-operation. for instance, SQL
: > stored procs can be encrypted, but they can be decripted using 'tools'
that
: > are available on the net.
: > So that's why the 'slow' operation, that is a 3 key-algorithm
: > (public/private/session) is the ONLY viable solution to safegard a file.
A
: > single password with 'xor' encryption on a file is as explained,
useless.
: >
: > Cheers,
:|||Sometimes trusting people too full is risky to the company, it should be
a double checking procedure and control by two authorized person.
About the monitoring data traffic is not very easy do that if the
application using a native database driver, except ODBC.
My suggestion is when attaching the MDF files will require the original
serial number of ms.sql server 2000 where it was created, I think at
least this is another way to protect the MDF files, even somebody or the
kick out administrator copy it, then it's useless, they should know the
serial number to access the MDF.
What do you think ?
brgs,
Ridwan
Ken Schaefer wrote:
> If the user is an administrator of the SQL Server, then they can steal you
r
> MDF files. But then, they can do anything anyway.
> If the user is an administrator of the Windows machine that SQL Server is
> on, then they can steal everything on the server anyway.
> Normal users can not do this.
> So, you need to trust your administrators.
> Anyway, even if there was a "separate" password, how would your applicatio
ns
> access the database? They would need the password, which means it has to b
e
> stored somewhere, which means the administrator could steal it from there
> (eg from the client application, or by monitoring the traffic that goes in
to
> SQL Server).
> Cheers
> Ken
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:407B4E73.682C@.centrin.net.id...
> : You didn't get my question, what I mean is if your database which you
> : have protect with the algorithm and re-install by somebody in their
> : server, then all your data will be seen and access using their 'sa'
> : login, so where's the protection ?
> :
> :
> :
> : Egbert Nierop (MVP for IIS) wrote:
> : >
> : > "RW" <goldbase@.centrin.net.id> wrote in message
> : > news:407AB799.4F6F@.centrin.net.id...
> : > > 1. using NTFS security still allow to get in, and duplicate the
> : > > database, this is not why I mean, but they can copy and open it in
> : > > another server without any protection.
> : > >
> : > > 2. using data encryption of course will slow down the performance
> while
> : > > we process large amount of data
> : >
> : > see below...
> : >
> : > > I am not blaming MS, actually the sql server is quite a good and eas
y
> to
> : > > maintain database, only we are so curious, why other user data like
> : > > excel spreadsheet, word, access can have their own password, and
> : > > specially the most important data container (sql server) open like a
> : > > mall and welcome in, u just login in as 'sa' and u get everything.
> : > >
> : > > Why not MS add an additional login password as an option, may be
> that's
> : > > much better than let it open.
> : >
> : > Applying a single password is really a nope-operation. for instance, S
QL
> : > stored procs can be encrypted, but they can be decripted using 'tools'
> that
> : > are available on the net.
> : > So that's why the 'slow' operation, that is a 3 key-algorithm
> : > (public/private/session) is the ONLY viable solution to safegard a fil
e.
> A
> : > single password with 'xor' encryption on a file is as explained,
> useless.
> : >
> : > Cheers,
> :|||> what is necessary to do for encrypt data?
>
Checkout www.database-encryption.com
www.sql-shield.com
ms sql server 2000 security too weak ?
It seems the authority for DBA is too much to control the safety of .mdf
, why not add an additional password or key to protect it, if someone
copy the .mdf files and install to a new sql server service, they can
read everything using sa facility, is it worse than ms.access ?
at least ms.access still need some extra job to crack it, but the .mdf
is too simple, just copy and read it.
Especially the MSDE version in one single computer, even the hardware
technician can duplicate and sell your important data.
Anyone have solution for this security problem ?
--
Best regards,
Ridwan
--
PemBukuan.Com
http://www.as3000.com"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
You have a choice. Have MSDE run, on a reserved account
- NTFS security
- Data Encryption
- Also, you can store data on a raw partition, that cannot be copied so
easily.
b.t.w. there is nearly no protection against harddisk access by a
technician. You can't blame MS for that. But data encryption by the
application that uses MSDE is a solution...|||1. using NTFS security still allow to get in, and duplicate the
database, this is not why I mean, but they can copy and open it in
another server without any protection.
2. using data encryption of course will slow down the performance while
we process large amount of data
I am not blaming MS, actually the sql server is quite a good and easy to
maintain database, only we are so curious, why other user data like
excel spreadsheet, word, access can have their own password, and
specially the most important data container (sql server) open like a
mall and welcome in, u just login in as 'sa' and u get everything.
Why not MS add an additional login password as an option, may be that's
much better than let it open.
> You have a choice. Have MSDE run, on a reserved account
> - NTFS security
> - Data Encryption
> - Also, you can store data on a raw partition, that cannot be copied so
> easily.
> b.t.w. there is nearly no protection against harddisk access by a
> technician. You can't blame MS for that. But data encryption by the
> application that uses MSDE is a solution...|||"RW" <goldbase@.centrin.net.id> wrote in message
news:407AB799.4F6F@.centrin.net.id...
> 1. using NTFS security still allow to get in, and duplicate the
> database, this is not why I mean, but they can copy and open it in
> another server without any protection.
> 2. using data encryption of course will slow down the performance while
> we process large amount of data
see below...
> I am not blaming MS, actually the sql server is quite a good and easy to
> maintain database, only we are so curious, why other user data like
> excel spreadsheet, word, access can have their own password, and
> specially the most important data container (sql server) open like a
> mall and welcome in, u just login in as 'sa' and u get everything.
> Why not MS add an additional login password as an option, may be that's
> much better than let it open.
Applying a single password is really a nope-operation. for instance, SQL
stored procs can be encrypted, but they can be decripted using 'tools' that
are available on the net.
So that's why the 'slow' operation, that is a 3 key-algorithm
(public/private/session) is the ONLY viable solution to safegard a file. A
single password with 'xor' encryption on a file is as explained, useless.
Cheers,|||hi
what is necessary to do for encrypt data?
--
atte,
Hernán Castelo
UTN Buenos Aires
. . . . . . . . . . . . . . . . . . . . . . . . . .
"Egbert Nierop (MVP for IIS)" <egbert_nierop@.nospam.invalid> escribió en el mensaje
news:uj3L1IFIEHA.3356@.TK2MSFTNGP11.phx.gbl...
"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
You have a choice. Have MSDE run, on a reserved account
- NTFS security
- Data Encryption
- Also, you can store data on a raw partition, that cannot be copied so
easily.
b.t.w. there is nearly no protection against harddisk access by a
technician. You can't blame MS for that. But data encryption by the
application that uses MSDE is a solution...|||> "Egbert Nierop (MVP for IIS)" <egbert_nierop@.nospam.invalid> escribió en
el mensaje
> news:uj3L1IFIEHA.3356@.TK2MSFTNGP11.phx.gbl...
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:4079FBD2.559B@.centrin.net.id...
> > It seems the authority for DBA is too much to control the safety of .mdf
> > , why not add an additional password or key to protect it, if someone
> > copy the .mdf files and install to a new sql server service, they can
> > read everything using sa facility, is it worse than ms.access ?
> >
> > at least ms.access still need some extra job to crack it, but the .mdf
> > is too simple, just copy and read it.
> >
> > Especially the MSDE version in one single computer, even the hardware
> > technician can duplicate and sell your important data.
> >
> > Anyone have solution for this security problem ?
> You have a choice. Have MSDE run, on a reserved account
> - NTFS security
> - Data Encryption
> - Also, you can store data on a raw partition, that cannot be copied so
> easily.
"Hernán Castelo" <hhh@.hotmail.com> wrote in message
news:%23KshfkMIEHA.3476@.TK2MSFTNGP11.phx.gbl...
> hi
> what is necessary to do for encrypt data?
> --
> atte,
> Hernán Castelo
> UTN Buenos Aires
> . . . . . . . . . . . . . . . . . . . . . . . . .
.
Your application can encrypt data. If you have .NET you can use Rijnhaeve
(If I spell correctly) and such. .NET samples show how to do it.
With C++ (7.0 and higher) there are encryption templates as well.|||You didn't get my question, what I mean is if your database which you
have protect with the algorithm and re-install by somebody in their
server, then all your data will be seen and access using their 'sa'
login, so where's the protection ?
Egbert Nierop (MVP for IIS) wrote:
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:407AB799.4F6F@.centrin.net.id...
> > 1. using NTFS security still allow to get in, and duplicate the
> > database, this is not why I mean, but they can copy and open it in
> > another server without any protection.
> >
> > 2. using data encryption of course will slow down the performance while
> > we process large amount of data
> see below...
> > I am not blaming MS, actually the sql server is quite a good and easy to
> > maintain database, only we are so curious, why other user data like
> > excel spreadsheet, word, access can have their own password, and
> > specially the most important data container (sql server) open like a
> > mall and welcome in, u just login in as 'sa' and u get everything.
> >
> > Why not MS add an additional login password as an option, may be that's
> > much better than let it open.
> Applying a single password is really a nope-operation. for instance, SQL
> stored procs can be encrypted, but they can be decripted using 'tools' that
> are available on the net.
> So that's why the 'slow' operation, that is a 3 key-algorithm
> (public/private/session) is the ONLY viable solution to safegard a file. A
> single password with 'xor' encryption on a file is as explained, useless.
> Cheers,|||If the user is an administrator of the SQL Server, then they can steal your
MDF files. But then, they can do anything anyway.
If the user is an administrator of the Windows machine that SQL Server is
on, then they can steal everything on the server anyway.
Normal users can not do this.
So, you need to trust your administrators.
Anyway, even if there was a "separate" password, how would your applications
access the database? They would need the password, which means it has to be
stored somewhere, which means the administrator could steal it from there
(eg from the client application, or by monitoring the traffic that goes into
SQL Server).
Cheers
Ken
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"RW" <goldbase@.centrin.net.id> wrote in message
news:407B4E73.682C@.centrin.net.id...
: You didn't get my question, what I mean is if your database which you
: have protect with the algorithm and re-install by somebody in their
: server, then all your data will be seen and access using their 'sa'
: login, so where's the protection ?
:
:
:
: Egbert Nierop (MVP for IIS) wrote:
: >
: > "RW" <goldbase@.centrin.net.id> wrote in message
: > news:407AB799.4F6F@.centrin.net.id...
: > > 1. using NTFS security still allow to get in, and duplicate the
: > > database, this is not why I mean, but they can copy and open it in
: > > another server without any protection.
: > >
: > > 2. using data encryption of course will slow down the performance
while
: > > we process large amount of data
: >
: > see below...
: >
: > > I am not blaming MS, actually the sql server is quite a good and easy
to
: > > maintain database, only we are so curious, why other user data like
: > > excel spreadsheet, word, access can have their own password, and
: > > specially the most important data container (sql server) open like a
: > > mall and welcome in, u just login in as 'sa' and u get everything.
: > >
: > > Why not MS add an additional login password as an option, may be
that's
: > > much better than let it open.
: >
: > Applying a single password is really a nope-operation. for instance, SQL
: > stored procs can be encrypted, but they can be decripted using 'tools'
that
: > are available on the net.
: > So that's why the 'slow' operation, that is a 3 key-algorithm
: > (public/private/session) is the ONLY viable solution to safegard a file.
A
: > single password with 'xor' encryption on a file is as explained,
useless.
: >
: > Cheers,
:|||Sometimes trusting people too full is risky to the company, it should be
a double checking procedure and control by two authorized person.
About the monitoring data traffic is not very easy do that if the
application using a native database driver, except ODBC.
My suggestion is when attaching the MDF files will require the original
serial number of ms.sql server 2000 where it was created, I think at
least this is another way to protect the MDF files, even somebody or the
kick out administrator copy it, then it's useless, they should know the
serial number to access the MDF.
What do you think ?
brgs,
Ridwan
Ken Schaefer wrote:
> If the user is an administrator of the SQL Server, then they can steal your
> MDF files. But then, they can do anything anyway.
> If the user is an administrator of the Windows machine that SQL Server is
> on, then they can steal everything on the server anyway.
> Normal users can not do this.
> So, you need to trust your administrators.
> Anyway, even if there was a "separate" password, how would your applications
> access the database? They would need the password, which means it has to be
> stored somewhere, which means the administrator could steal it from there
> (eg from the client application, or by monitoring the traffic that goes into
> SQL Server).
> Cheers
> Ken
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:407B4E73.682C@.centrin.net.id...
> : You didn't get my question, what I mean is if your database which you
> : have protect with the algorithm and re-install by somebody in their
> : server, then all your data will be seen and access using their 'sa'
> : login, so where's the protection ?
> :
> :
> :
> : Egbert Nierop (MVP for IIS) wrote:
> : >
> : > "RW" <goldbase@.centrin.net.id> wrote in message
> : > news:407AB799.4F6F@.centrin.net.id...
> : > > 1. using NTFS security still allow to get in, and duplicate the
> : > > database, this is not why I mean, but they can copy and open it in
> : > > another server without any protection.
> : > >
> : > > 2. using data encryption of course will slow down the performance
> while
> : > > we process large amount of data
> : >
> : > see below...
> : >
> : > > I am not blaming MS, actually the sql server is quite a good and easy
> to
> : > > maintain database, only we are so curious, why other user data like
> : > > excel spreadsheet, word, access can have their own password, and
> : > > specially the most important data container (sql server) open like a
> : > > mall and welcome in, u just login in as 'sa' and u get everything.
> : > >
> : > > Why not MS add an additional login password as an option, may be
> that's
> : > > much better than let it open.
> : >
> : > Applying a single password is really a nope-operation. for instance, SQL
> : > stored procs can be encrypted, but they can be decripted using 'tools'
> that
> : > are available on the net.
> : > So that's why the 'slow' operation, that is a 3 key-algorithm
> : > (public/private/session) is the ONLY viable solution to safegard a file.
> A
> : > single password with 'xor' encryption on a file is as explained,
> useless.
> : >
> : > Cheers,
> :|||> what is necessary to do for encrypt data?
>
Checkout www.database-encryption.com
www.sql-shield.com|||Hi
You are quite right Ridwan. MSSQL is exceptionally weak when it comes to
this. You have hit the nail right on the head. We are quite astonished
that MS has not taken data security seriously. They could at least have
provided some sort of encryption technique that could have restricted access
to all objects in the database outside of SA or sysadmin. The basic
underlying structure of their SQL engine is at fault here. The SA login is
a disaster as is the total control given to sysadmin. It basically makes
the product quite unusable in a mission critical environment. Nothing more,
nothing less. If you do not turn to third party tools to help you with this
dilemna you are basically stuck. If you take data security seriously you
are snookered. You may have to look for a more serious DBMS. We are
currently looking at third party options but most of them do not lock down
table structures and relationships. Hoping to find something that will lock
down the entire database so that it is NOT accessible on another server by
some individual that has gaily made his/her self system administrator. A
shocking state of affairs.
Cheers
Andre
"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
> --
> Best regards,
>
> Ridwan
> --
> PemBukuan.Com
> http://www.as3000.com
>
, why not add an additional password or key to protect it, if someone
copy the .mdf files and install to a new sql server service, they can
read everything using sa facility, is it worse than ms.access ?
at least ms.access still need some extra job to crack it, but the .mdf
is too simple, just copy and read it.
Especially the MSDE version in one single computer, even the hardware
technician can duplicate and sell your important data.
Anyone have solution for this security problem ?
--
Best regards,
Ridwan
--
PemBukuan.Com
http://www.as3000.com"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
You have a choice. Have MSDE run, on a reserved account
- NTFS security
- Data Encryption
- Also, you can store data on a raw partition, that cannot be copied so
easily.
b.t.w. there is nearly no protection against harddisk access by a
technician. You can't blame MS for that. But data encryption by the
application that uses MSDE is a solution...|||1. using NTFS security still allow to get in, and duplicate the
database, this is not why I mean, but they can copy and open it in
another server without any protection.
2. using data encryption of course will slow down the performance while
we process large amount of data
I am not blaming MS, actually the sql server is quite a good and easy to
maintain database, only we are so curious, why other user data like
excel spreadsheet, word, access can have their own password, and
specially the most important data container (sql server) open like a
mall and welcome in, u just login in as 'sa' and u get everything.
Why not MS add an additional login password as an option, may be that's
much better than let it open.
> You have a choice. Have MSDE run, on a reserved account
> - NTFS security
> - Data Encryption
> - Also, you can store data on a raw partition, that cannot be copied so
> easily.
> b.t.w. there is nearly no protection against harddisk access by a
> technician. You can't blame MS for that. But data encryption by the
> application that uses MSDE is a solution...|||"RW" <goldbase@.centrin.net.id> wrote in message
news:407AB799.4F6F@.centrin.net.id...
> 1. using NTFS security still allow to get in, and duplicate the
> database, this is not why I mean, but they can copy and open it in
> another server without any protection.
> 2. using data encryption of course will slow down the performance while
> we process large amount of data
see below...
> I am not blaming MS, actually the sql server is quite a good and easy to
> maintain database, only we are so curious, why other user data like
> excel spreadsheet, word, access can have their own password, and
> specially the most important data container (sql server) open like a
> mall and welcome in, u just login in as 'sa' and u get everything.
> Why not MS add an additional login password as an option, may be that's
> much better than let it open.
Applying a single password is really a nope-operation. for instance, SQL
stored procs can be encrypted, but they can be decripted using 'tools' that
are available on the net.
So that's why the 'slow' operation, that is a 3 key-algorithm
(public/private/session) is the ONLY viable solution to safegard a file. A
single password with 'xor' encryption on a file is as explained, useless.
Cheers,|||hi
what is necessary to do for encrypt data?
--
atte,
Hernán Castelo
UTN Buenos Aires
. . . . . . . . . . . . . . . . . . . . . . . . . .
"Egbert Nierop (MVP for IIS)" <egbert_nierop@.nospam.invalid> escribió en el mensaje
news:uj3L1IFIEHA.3356@.TK2MSFTNGP11.phx.gbl...
"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
You have a choice. Have MSDE run, on a reserved account
- NTFS security
- Data Encryption
- Also, you can store data on a raw partition, that cannot be copied so
easily.
b.t.w. there is nearly no protection against harddisk access by a
technician. You can't blame MS for that. But data encryption by the
application that uses MSDE is a solution...|||> "Egbert Nierop (MVP for IIS)" <egbert_nierop@.nospam.invalid> escribió en
el mensaje
> news:uj3L1IFIEHA.3356@.TK2MSFTNGP11.phx.gbl...
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:4079FBD2.559B@.centrin.net.id...
> > It seems the authority for DBA is too much to control the safety of .mdf
> > , why not add an additional password or key to protect it, if someone
> > copy the .mdf files and install to a new sql server service, they can
> > read everything using sa facility, is it worse than ms.access ?
> >
> > at least ms.access still need some extra job to crack it, but the .mdf
> > is too simple, just copy and read it.
> >
> > Especially the MSDE version in one single computer, even the hardware
> > technician can duplicate and sell your important data.
> >
> > Anyone have solution for this security problem ?
> You have a choice. Have MSDE run, on a reserved account
> - NTFS security
> - Data Encryption
> - Also, you can store data on a raw partition, that cannot be copied so
> easily.
"Hernán Castelo" <hhh@.hotmail.com> wrote in message
news:%23KshfkMIEHA.3476@.TK2MSFTNGP11.phx.gbl...
> hi
> what is necessary to do for encrypt data?
> --
> atte,
> Hernán Castelo
> UTN Buenos Aires
> . . . . . . . . . . . . . . . . . . . . . . . . .
.
Your application can encrypt data. If you have .NET you can use Rijnhaeve
(If I spell correctly) and such. .NET samples show how to do it.
With C++ (7.0 and higher) there are encryption templates as well.|||You didn't get my question, what I mean is if your database which you
have protect with the algorithm and re-install by somebody in their
server, then all your data will be seen and access using their 'sa'
login, so where's the protection ?
Egbert Nierop (MVP for IIS) wrote:
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:407AB799.4F6F@.centrin.net.id...
> > 1. using NTFS security still allow to get in, and duplicate the
> > database, this is not why I mean, but they can copy and open it in
> > another server without any protection.
> >
> > 2. using data encryption of course will slow down the performance while
> > we process large amount of data
> see below...
> > I am not blaming MS, actually the sql server is quite a good and easy to
> > maintain database, only we are so curious, why other user data like
> > excel spreadsheet, word, access can have their own password, and
> > specially the most important data container (sql server) open like a
> > mall and welcome in, u just login in as 'sa' and u get everything.
> >
> > Why not MS add an additional login password as an option, may be that's
> > much better than let it open.
> Applying a single password is really a nope-operation. for instance, SQL
> stored procs can be encrypted, but they can be decripted using 'tools' that
> are available on the net.
> So that's why the 'slow' operation, that is a 3 key-algorithm
> (public/private/session) is the ONLY viable solution to safegard a file. A
> single password with 'xor' encryption on a file is as explained, useless.
> Cheers,|||If the user is an administrator of the SQL Server, then they can steal your
MDF files. But then, they can do anything anyway.
If the user is an administrator of the Windows machine that SQL Server is
on, then they can steal everything on the server anyway.
Normal users can not do this.
So, you need to trust your administrators.
Anyway, even if there was a "separate" password, how would your applications
access the database? They would need the password, which means it has to be
stored somewhere, which means the administrator could steal it from there
(eg from the client application, or by monitoring the traffic that goes into
SQL Server).
Cheers
Ken
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"RW" <goldbase@.centrin.net.id> wrote in message
news:407B4E73.682C@.centrin.net.id...
: You didn't get my question, what I mean is if your database which you
: have protect with the algorithm and re-install by somebody in their
: server, then all your data will be seen and access using their 'sa'
: login, so where's the protection ?
:
:
:
: Egbert Nierop (MVP for IIS) wrote:
: >
: > "RW" <goldbase@.centrin.net.id> wrote in message
: > news:407AB799.4F6F@.centrin.net.id...
: > > 1. using NTFS security still allow to get in, and duplicate the
: > > database, this is not why I mean, but they can copy and open it in
: > > another server without any protection.
: > >
: > > 2. using data encryption of course will slow down the performance
while
: > > we process large amount of data
: >
: > see below...
: >
: > > I am not blaming MS, actually the sql server is quite a good and easy
to
: > > maintain database, only we are so curious, why other user data like
: > > excel spreadsheet, word, access can have their own password, and
: > > specially the most important data container (sql server) open like a
: > > mall and welcome in, u just login in as 'sa' and u get everything.
: > >
: > > Why not MS add an additional login password as an option, may be
that's
: > > much better than let it open.
: >
: > Applying a single password is really a nope-operation. for instance, SQL
: > stored procs can be encrypted, but they can be decripted using 'tools'
that
: > are available on the net.
: > So that's why the 'slow' operation, that is a 3 key-algorithm
: > (public/private/session) is the ONLY viable solution to safegard a file.
A
: > single password with 'xor' encryption on a file is as explained,
useless.
: >
: > Cheers,
:|||Sometimes trusting people too full is risky to the company, it should be
a double checking procedure and control by two authorized person.
About the monitoring data traffic is not very easy do that if the
application using a native database driver, except ODBC.
My suggestion is when attaching the MDF files will require the original
serial number of ms.sql server 2000 where it was created, I think at
least this is another way to protect the MDF files, even somebody or the
kick out administrator copy it, then it's useless, they should know the
serial number to access the MDF.
What do you think ?
brgs,
Ridwan
Ken Schaefer wrote:
> If the user is an administrator of the SQL Server, then they can steal your
> MDF files. But then, they can do anything anyway.
> If the user is an administrator of the Windows machine that SQL Server is
> on, then they can steal everything on the server anyway.
> Normal users can not do this.
> So, you need to trust your administrators.
> Anyway, even if there was a "separate" password, how would your applications
> access the database? They would need the password, which means it has to be
> stored somewhere, which means the administrator could steal it from there
> (eg from the client application, or by monitoring the traffic that goes into
> SQL Server).
> Cheers
> Ken
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:407B4E73.682C@.centrin.net.id...
> : You didn't get my question, what I mean is if your database which you
> : have protect with the algorithm and re-install by somebody in their
> : server, then all your data will be seen and access using their 'sa'
> : login, so where's the protection ?
> :
> :
> :
> : Egbert Nierop (MVP for IIS) wrote:
> : >
> : > "RW" <goldbase@.centrin.net.id> wrote in message
> : > news:407AB799.4F6F@.centrin.net.id...
> : > > 1. using NTFS security still allow to get in, and duplicate the
> : > > database, this is not why I mean, but they can copy and open it in
> : > > another server without any protection.
> : > >
> : > > 2. using data encryption of course will slow down the performance
> while
> : > > we process large amount of data
> : >
> : > see below...
> : >
> : > > I am not blaming MS, actually the sql server is quite a good and easy
> to
> : > > maintain database, only we are so curious, why other user data like
> : > > excel spreadsheet, word, access can have their own password, and
> : > > specially the most important data container (sql server) open like a
> : > > mall and welcome in, u just login in as 'sa' and u get everything.
> : > >
> : > > Why not MS add an additional login password as an option, may be
> that's
> : > > much better than let it open.
> : >
> : > Applying a single password is really a nope-operation. for instance, SQL
> : > stored procs can be encrypted, but they can be decripted using 'tools'
> that
> : > are available on the net.
> : > So that's why the 'slow' operation, that is a 3 key-algorithm
> : > (public/private/session) is the ONLY viable solution to safegard a file.
> A
> : > single password with 'xor' encryption on a file is as explained,
> useless.
> : >
> : > Cheers,
> :|||> what is necessary to do for encrypt data?
>
Checkout www.database-encryption.com
www.sql-shield.com|||Hi
You are quite right Ridwan. MSSQL is exceptionally weak when it comes to
this. You have hit the nail right on the head. We are quite astonished
that MS has not taken data security seriously. They could at least have
provided some sort of encryption technique that could have restricted access
to all objects in the database outside of SA or sysadmin. The basic
underlying structure of their SQL engine is at fault here. The SA login is
a disaster as is the total control given to sysadmin. It basically makes
the product quite unusable in a mission critical environment. Nothing more,
nothing less. If you do not turn to third party tools to help you with this
dilemna you are basically stuck. If you take data security seriously you
are snookered. You may have to look for a more serious DBMS. We are
currently looking at third party options but most of them do not lock down
table structures and relationships. Hoping to find something that will lock
down the entire database so that it is NOT accessible on another server by
some individual that has gaily made his/her self system administrator. A
shocking state of affairs.
Cheers
Andre
"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
> --
> Best regards,
>
> Ridwan
> --
> PemBukuan.Com
> http://www.as3000.com
>
ms sql server 2000 security too weak ?
It seems the authority for DBA is too much to control the safety of .mdf
, why not add an additional password or key to protect it, if someone
copy the .mdf files and install to a new sql server service, they can
read everything using sa facility, is it worse than ms.access ?
at least ms.access still need some extra job to crack it, but the .mdf
is too simple, just copy and read it.
Especially the MSDE version in one single computer, even the hardware
technician can duplicate and sell your important data.
Anyone have solution for this security problem ?
Best regards,
Ridwan
PemBukuan.Com
http://www.as3000.com
"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
You have a choice. Have MSDE run, on a reserved account
- NTFS security
- Data Encryption
- Also, you can store data on a raw partition, that cannot be copied so
easily.
b.t.w. there is nearly no protection against harddisk access by a
technician. You can't blame MS for that. But data encryption by the
application that uses MSDE is a solution...
|||1. using NTFS security still allow to get in, and duplicate the
database, this is not why I mean, but they can copy and open it in
another server without any protection.
2. using data encryption of course will slow down the performance while
we process large amount of data
I am not blaming MS, actually the sql server is quite a good and easy to
maintain database, only we are so curious, why other user data like
excel spreadsheet, word, access can have their own password, and
specially the most important data container (sql server) open like a
mall and welcome in, u just login in as 'sa' and u get everything.
Why not MS add an additional login password as an option, may be that's
much better than let it open.
> You have a choice. Have MSDE run, on a reserved account
> - NTFS security
> - Data Encryption
> - Also, you can store data on a raw partition, that cannot be copied so
> easily.
> b.t.w. there is nearly no protection against harddisk access by a
> technician. You can't blame MS for that. But data encryption by the
> application that uses MSDE is a solution...
|||"RW" <goldbase@.centrin.net.id> wrote in message
news:407AB799.4F6F@.centrin.net.id...
> 1. using NTFS security still allow to get in, and duplicate the
> database, this is not why I mean, but they can copy and open it in
> another server without any protection.
> 2. using data encryption of course will slow down the performance while
> we process large amount of data
see below...
> I am not blaming MS, actually the sql server is quite a good and easy to
> maintain database, only we are so curious, why other user data like
> excel spreadsheet, word, access can have their own password, and
> specially the most important data container (sql server) open like a
> mall and welcome in, u just login in as 'sa' and u get everything.
> Why not MS add an additional login password as an option, may be that's
> much better than let it open.
Applying a single password is really a nope-operation. for instance, SQL
stored procs can be encrypted, but they can be decripted using 'tools' that
are available on the net.
So that's why the 'slow' operation, that is a 3 key-algorithm
(public/private/session) is the ONLY viable solution to safegard a file. A
single password with 'xor' encryption on a file is as explained, useless.
Cheers,
|||hi
what is necessary to do for encrypt data?
atte,
Hernn Castelo
UTN Buenos Aires
.. . . . . . . . . . . . . . . . . . . . . . . . . .
"Egbert Nierop (MVP for IIS)" <egbert_nierop@.nospam.invalid> escribi en el mensaje
news:uj3L1IFIEHA.3356@.TK2MSFTNGP11.phx.gbl...
"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
You have a choice. Have MSDE run, on a reserved account
- NTFS security
- Data Encryption
- Also, you can store data on a raw partition, that cannot be copied so
easily.
b.t.w. there is nearly no protection against harddisk access by a
technician. You can't blame MS for that. But data encryption by the
application that uses MSDE is a solution...
|||> "Egbert Nierop (MVP for IIS)" <egbert_nierop@.nospam.invalid> escribi en
el mensaje
> news:uj3L1IFIEHA.3356@.TK2MSFTNGP11.phx.gbl...
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:4079FBD2.559B@.centrin.net.id...
> You have a choice. Have MSDE run, on a reserved account
> - NTFS security
> - Data Encryption
> - Also, you can store data on a raw partition, that cannot be copied so
> easily.
"Hernn Castelo" <hhh@.hotmail.com> wrote in message
news:%23KshfkMIEHA.3476@.TK2MSFTNGP11.phx.gbl...
> hi
> what is necessary to do for encrypt data?
> --
> atte,
> Hernn Castelo
> UTN Buenos Aires
> . . . . . . . . . . . . . . . . . . . . . . . . .
..
Your application can encrypt data. If you have .NET you can use Rijnhaeve
(If I spell correctly) and such. .NET samples show how to do it.
With C++ (7.0 and higher) there are encryption templates as well.
|||You didn't get my question, what I mean is if your database which you
have protect with the algorithm and re-install by somebody in their
server, then all your data will be seen and access using their 'sa'
login, so where's the protection ?
Egbert Nierop (MVP for IIS) wrote:
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:407AB799.4F6F@.centrin.net.id...
> see below...
>
> Applying a single password is really a nope-operation. for instance, SQL
> stored procs can be encrypted, but they can be decripted using 'tools' that
> are available on the net.
> So that's why the 'slow' operation, that is a 3 key-algorithm
> (public/private/session) is the ONLY viable solution to safegard a file. A
> single password with 'xor' encryption on a file is as explained, useless.
> Cheers,
|||If the user is an administrator of the SQL Server, then they can steal your
MDF files. But then, they can do anything anyway.
If the user is an administrator of the Windows machine that SQL Server is
on, then they can steal everything on the server anyway.
Normal users can not do this.
So, you need to trust your administrators.
Anyway, even if there was a "separate" password, how would your applications
access the database? They would need the password, which means it has to be
stored somewhere, which means the administrator could steal it from there
(eg from the client application, or by monitoring the traffic that goes into
SQL Server).
Cheers
Ken
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"RW" <goldbase@.centrin.net.id> wrote in message
news:407B4E73.682C@.centrin.net.id...
: You didn't get my question, what I mean is if your database which you
: have protect with the algorithm and re-install by somebody in their
: server, then all your data will be seen and access using their 'sa'
: login, so where's the protection ?
:
:
:
: Egbert Nierop (MVP for IIS) wrote:
: >
: > "RW" <goldbase@.centrin.net.id> wrote in message
: > news:407AB799.4F6F@.centrin.net.id...
: > > 1. using NTFS security still allow to get in, and duplicate the
: > > database, this is not why I mean, but they can copy and open it in
: > > another server without any protection.
: > >
: > > 2. using data encryption of course will slow down the performance
while
: > > we process large amount of data
: >
: > see below...
: >
: > > I am not blaming MS, actually the sql server is quite a good and easy
to
: > > maintain database, only we are so curious, why other user data like
: > > excel spreadsheet, word, access can have their own password, and
: > > specially the most important data container (sql server) open like a
: > > mall and welcome in, u just login in as 'sa' and u get everything.
: > >
: > > Why not MS add an additional login password as an option, may be
that's
: > > much better than let it open.
: >
: > Applying a single password is really a nope-operation. for instance, SQL
: > stored procs can be encrypted, but they can be decripted using 'tools'
that
: > are available on the net.
: > So that's why the 'slow' operation, that is a 3 key-algorithm
: > (public/private/session) is the ONLY viable solution to safegard a file.
A
: > single password with 'xor' encryption on a file is as explained,
useless.
: >
: > Cheers,
:
|||Sometimes trusting people too full is risky to the company, it should be
a double checking procedure and control by two authorized person.
About the monitoring data traffic is not very easy do that if the
application using a native database driver, except ODBC.
My suggestion is when attaching the MDF files will require the original
serial number of ms.sql server 2000 where it was created, I think at
least this is another way to protect the MDF files, even somebody or the
kick out administrator copy it, then it's useless, they should know the
serial number to access the MDF.
What do you think ?
brgs,
Ridwan
Ken Schaefer wrote:
> If the user is an administrator of the SQL Server, then they can steal your
> MDF files. But then, they can do anything anyway.
> If the user is an administrator of the Windows machine that SQL Server is
> on, then they can steal everything on the server anyway.
> Normal users can not do this.
> So, you need to trust your administrators.
> Anyway, even if there was a "separate" password, how would your applications
> access the database? They would need the password, which means it has to be
> stored somewhere, which means the administrator could steal it from there
> (eg from the client application, or by monitoring the traffic that goes into
> SQL Server).
> Cheers
> Ken
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:407B4E73.682C@.centrin.net.id...
> : You didn't get my question, what I mean is if your database which you
> : have protect with the algorithm and re-install by somebody in their
> : server, then all your data will be seen and access using their 'sa'
> : login, so where's the protection ?
> :
> :
> :
> : Egbert Nierop (MVP for IIS) wrote:
> : >
> : > "RW" <goldbase@.centrin.net.id> wrote in message
> : > news:407AB799.4F6F@.centrin.net.id...
> : > > 1. using NTFS security still allow to get in, and duplicate the
> : > > database, this is not why I mean, but they can copy and open it in
> : > > another server without any protection.
> : > >
> : > > 2. using data encryption of course will slow down the performance
> while
> : > > we process large amount of data
> : >
> : > see below...
> : >
> : > > I am not blaming MS, actually the sql server is quite a good and easy
> to
> : > > maintain database, only we are so curious, why other user data like
> : > > excel spreadsheet, word, access can have their own password, and
> : > > specially the most important data container (sql server) open like a
> : > > mall and welcome in, u just login in as 'sa' and u get everything.
> : > >
> : > > Why not MS add an additional login password as an option, may be
> that's
> : > > much better than let it open.
> : >
> : > Applying a single password is really a nope-operation. for instance, SQL
> : > stored procs can be encrypted, but they can be decripted using 'tools'
> that
> : > are available on the net.
> : > So that's why the 'slow' operation, that is a 3 key-algorithm
> : > (public/private/session) is the ONLY viable solution to safegard a file.
> A
> : > single password with 'xor' encryption on a file is as explained,
> useless.
> : >
> : > Cheers,
> :
|||> what is necessary to do for encrypt data?
>
Checkout www.database-encryption.com
www.sql-shield.com
sql
, why not add an additional password or key to protect it, if someone
copy the .mdf files and install to a new sql server service, they can
read everything using sa facility, is it worse than ms.access ?
at least ms.access still need some extra job to crack it, but the .mdf
is too simple, just copy and read it.
Especially the MSDE version in one single computer, even the hardware
technician can duplicate and sell your important data.
Anyone have solution for this security problem ?
Best regards,
Ridwan
PemBukuan.Com
http://www.as3000.com
"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
You have a choice. Have MSDE run, on a reserved account
- NTFS security
- Data Encryption
- Also, you can store data on a raw partition, that cannot be copied so
easily.
b.t.w. there is nearly no protection against harddisk access by a
technician. You can't blame MS for that. But data encryption by the
application that uses MSDE is a solution...
|||1. using NTFS security still allow to get in, and duplicate the
database, this is not why I mean, but they can copy and open it in
another server without any protection.
2. using data encryption of course will slow down the performance while
we process large amount of data
I am not blaming MS, actually the sql server is quite a good and easy to
maintain database, only we are so curious, why other user data like
excel spreadsheet, word, access can have their own password, and
specially the most important data container (sql server) open like a
mall and welcome in, u just login in as 'sa' and u get everything.
Why not MS add an additional login password as an option, may be that's
much better than let it open.
> You have a choice. Have MSDE run, on a reserved account
> - NTFS security
> - Data Encryption
> - Also, you can store data on a raw partition, that cannot be copied so
> easily.
> b.t.w. there is nearly no protection against harddisk access by a
> technician. You can't blame MS for that. But data encryption by the
> application that uses MSDE is a solution...
|||"RW" <goldbase@.centrin.net.id> wrote in message
news:407AB799.4F6F@.centrin.net.id...
> 1. using NTFS security still allow to get in, and duplicate the
> database, this is not why I mean, but they can copy and open it in
> another server without any protection.
> 2. using data encryption of course will slow down the performance while
> we process large amount of data
see below...
> I am not blaming MS, actually the sql server is quite a good and easy to
> maintain database, only we are so curious, why other user data like
> excel spreadsheet, word, access can have their own password, and
> specially the most important data container (sql server) open like a
> mall and welcome in, u just login in as 'sa' and u get everything.
> Why not MS add an additional login password as an option, may be that's
> much better than let it open.
Applying a single password is really a nope-operation. for instance, SQL
stored procs can be encrypted, but they can be decripted using 'tools' that
are available on the net.
So that's why the 'slow' operation, that is a 3 key-algorithm
(public/private/session) is the ONLY viable solution to safegard a file. A
single password with 'xor' encryption on a file is as explained, useless.
Cheers,
|||hi
what is necessary to do for encrypt data?
atte,
Hernn Castelo
UTN Buenos Aires
.. . . . . . . . . . . . . . . . . . . . . . . . . .
"Egbert Nierop (MVP for IIS)" <egbert_nierop@.nospam.invalid> escribi en el mensaje
news:uj3L1IFIEHA.3356@.TK2MSFTNGP11.phx.gbl...
"RW" <goldbase@.centrin.net.id> wrote in message
news:4079FBD2.559B@.centrin.net.id...
> It seems the authority for DBA is too much to control the safety of .mdf
> , why not add an additional password or key to protect it, if someone
> copy the .mdf files and install to a new sql server service, they can
> read everything using sa facility, is it worse than ms.access ?
> at least ms.access still need some extra job to crack it, but the .mdf
> is too simple, just copy and read it.
> Especially the MSDE version in one single computer, even the hardware
> technician can duplicate and sell your important data.
> Anyone have solution for this security problem ?
You have a choice. Have MSDE run, on a reserved account
- NTFS security
- Data Encryption
- Also, you can store data on a raw partition, that cannot be copied so
easily.
b.t.w. there is nearly no protection against harddisk access by a
technician. You can't blame MS for that. But data encryption by the
application that uses MSDE is a solution...
|||> "Egbert Nierop (MVP for IIS)" <egbert_nierop@.nospam.invalid> escribi en
el mensaje
> news:uj3L1IFIEHA.3356@.TK2MSFTNGP11.phx.gbl...
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:4079FBD2.559B@.centrin.net.id...
> You have a choice. Have MSDE run, on a reserved account
> - NTFS security
> - Data Encryption
> - Also, you can store data on a raw partition, that cannot be copied so
> easily.
"Hernn Castelo" <hhh@.hotmail.com> wrote in message
news:%23KshfkMIEHA.3476@.TK2MSFTNGP11.phx.gbl...
> hi
> what is necessary to do for encrypt data?
> --
> atte,
> Hernn Castelo
> UTN Buenos Aires
> . . . . . . . . . . . . . . . . . . . . . . . . .
..
Your application can encrypt data. If you have .NET you can use Rijnhaeve
(If I spell correctly) and such. .NET samples show how to do it.
With C++ (7.0 and higher) there are encryption templates as well.
|||You didn't get my question, what I mean is if your database which you
have protect with the algorithm and re-install by somebody in their
server, then all your data will be seen and access using their 'sa'
login, so where's the protection ?
Egbert Nierop (MVP for IIS) wrote:
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:407AB799.4F6F@.centrin.net.id...
> see below...
>
> Applying a single password is really a nope-operation. for instance, SQL
> stored procs can be encrypted, but they can be decripted using 'tools' that
> are available on the net.
> So that's why the 'slow' operation, that is a 3 key-algorithm
> (public/private/session) is the ONLY viable solution to safegard a file. A
> single password with 'xor' encryption on a file is as explained, useless.
> Cheers,
|||If the user is an administrator of the SQL Server, then they can steal your
MDF files. But then, they can do anything anyway.
If the user is an administrator of the Windows machine that SQL Server is
on, then they can steal everything on the server anyway.
Normal users can not do this.
So, you need to trust your administrators.
Anyway, even if there was a "separate" password, how would your applications
access the database? They would need the password, which means it has to be
stored somewhere, which means the administrator could steal it from there
(eg from the client application, or by monitoring the traffic that goes into
SQL Server).
Cheers
Ken
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"RW" <goldbase@.centrin.net.id> wrote in message
news:407B4E73.682C@.centrin.net.id...
: You didn't get my question, what I mean is if your database which you
: have protect with the algorithm and re-install by somebody in their
: server, then all your data will be seen and access using their 'sa'
: login, so where's the protection ?
:
:
:
: Egbert Nierop (MVP for IIS) wrote:
: >
: > "RW" <goldbase@.centrin.net.id> wrote in message
: > news:407AB799.4F6F@.centrin.net.id...
: > > 1. using NTFS security still allow to get in, and duplicate the
: > > database, this is not why I mean, but they can copy and open it in
: > > another server without any protection.
: > >
: > > 2. using data encryption of course will slow down the performance
while
: > > we process large amount of data
: >
: > see below...
: >
: > > I am not blaming MS, actually the sql server is quite a good and easy
to
: > > maintain database, only we are so curious, why other user data like
: > > excel spreadsheet, word, access can have their own password, and
: > > specially the most important data container (sql server) open like a
: > > mall and welcome in, u just login in as 'sa' and u get everything.
: > >
: > > Why not MS add an additional login password as an option, may be
that's
: > > much better than let it open.
: >
: > Applying a single password is really a nope-operation. for instance, SQL
: > stored procs can be encrypted, but they can be decripted using 'tools'
that
: > are available on the net.
: > So that's why the 'slow' operation, that is a 3 key-algorithm
: > (public/private/session) is the ONLY viable solution to safegard a file.
A
: > single password with 'xor' encryption on a file is as explained,
useless.
: >
: > Cheers,
:
|||Sometimes trusting people too full is risky to the company, it should be
a double checking procedure and control by two authorized person.
About the monitoring data traffic is not very easy do that if the
application using a native database driver, except ODBC.
My suggestion is when attaching the MDF files will require the original
serial number of ms.sql server 2000 where it was created, I think at
least this is another way to protect the MDF files, even somebody or the
kick out administrator copy it, then it's useless, they should know the
serial number to access the MDF.
What do you think ?
brgs,
Ridwan
Ken Schaefer wrote:
> If the user is an administrator of the SQL Server, then they can steal your
> MDF files. But then, they can do anything anyway.
> If the user is an administrator of the Windows machine that SQL Server is
> on, then they can steal everything on the server anyway.
> Normal users can not do this.
> So, you need to trust your administrators.
> Anyway, even if there was a "separate" password, how would your applications
> access the database? They would need the password, which means it has to be
> stored somewhere, which means the administrator could steal it from there
> (eg from the client application, or by monitoring the traffic that goes into
> SQL Server).
> Cheers
> Ken
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "RW" <goldbase@.centrin.net.id> wrote in message
> news:407B4E73.682C@.centrin.net.id...
> : You didn't get my question, what I mean is if your database which you
> : have protect with the algorithm and re-install by somebody in their
> : server, then all your data will be seen and access using their 'sa'
> : login, so where's the protection ?
> :
> :
> :
> : Egbert Nierop (MVP for IIS) wrote:
> : >
> : > "RW" <goldbase@.centrin.net.id> wrote in message
> : > news:407AB799.4F6F@.centrin.net.id...
> : > > 1. using NTFS security still allow to get in, and duplicate the
> : > > database, this is not why I mean, but they can copy and open it in
> : > > another server without any protection.
> : > >
> : > > 2. using data encryption of course will slow down the performance
> while
> : > > we process large amount of data
> : >
> : > see below...
> : >
> : > > I am not blaming MS, actually the sql server is quite a good and easy
> to
> : > > maintain database, only we are so curious, why other user data like
> : > > excel spreadsheet, word, access can have their own password, and
> : > > specially the most important data container (sql server) open like a
> : > > mall and welcome in, u just login in as 'sa' and u get everything.
> : > >
> : > > Why not MS add an additional login password as an option, may be
> that's
> : > > much better than let it open.
> : >
> : > Applying a single password is really a nope-operation. for instance, SQL
> : > stored procs can be encrypted, but they can be decripted using 'tools'
> that
> : > are available on the net.
> : > So that's why the 'slow' operation, that is a 3 key-algorithm
> : > (public/private/session) is the ONLY viable solution to safegard a file.
> A
> : > single password with 'xor' encryption on a file is as explained,
> useless.
> : >
> : > Cheers,
> :
|||> what is necessary to do for encrypt data?
>
Checkout www.database-encryption.com
www.sql-shield.com
sql
Monday, March 19, 2012
MS SQL Question - Insert data to a new table
Hello, I am using a database .mdf and I want to insert values in a table (I mean how to connect also with a database, open it and store the values). Can someone describe the whole process to do that (as I am newbie in asp.net). I want the whole code if it is possible.
For example I am using the above code to create 2 textboxes where the user will write his name and password. Then I want to store (by clicking the button) the values to a table in database. Thank you
<%@.PageLanguage="VB"AutoEventWireup="false"CodeFile="Manufacturer.aspx.vb"Inherits="Manufacturer" %>
<!DOCTYPEhtmlPUBLIC"-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><htmlxmlns="http://www.w3.org/1999/xhtml">
<headrunat="server">
<title>Untitled Page</title></head>
<body>
<formid="form1"runat="server">
<div>
<asp:LabelID="Label1"runat="server"Text="Name"></asp:Label>
<asp:TextBoxID="TextBox1"runat="server"></asp:TextBox><br/>
<asp:LabelID="Label2"runat="server"Text="Password"></asp:Label>
<asp:TextBoxID="TextBox2"runat="server"></asp:TextBox>
<br/>
<br/>
<asp:ButtonID="Button1"runat="server"Text="Submit"/></div>
</form></body>
</html>
Hi,Have you tried the sqldatasource controls?
For tutorials,http://asp.net/learn/videos/
Monday, March 12, 2012
ms sql mdf database file attached vs created on sql server
Hi all
I have a question concerning sql database mdf files. In the old days I would user a ms access database. This file would be stored with the actual web files and would utilise a dsn connection.
I have noted when designing with vwd 2005 express it allows you to use 2 methods of creating a mdf database. You can either create it as an attachment mdf or you can create it directly using sql manager.
My question is, if you create the mdf database as an attachement file can you store it in the same manner as if you where using a ms access database, meaning can you store it with the web site's files so it uses the file storage allocated size and then create a connection similar to a dsn (but for sql) to the isp's sql engine or does it have to be uploaded to the isp' s sql server.
The reason for this question is some of my customers do not want to pay the extra cost to have an sql allocation, however I do not want to go back to using old asp methods to create advanced sites as I prefer using stored procedures.
Any help will be appreciated
Hi,
you can attach your .mdf file (SQL Server Express) to a database (Attaching a .mdf file when you don't have the .ldf file available). However I think the hosting company will charge your customers for attaching it. To my knowledge you don't have a replacement available like DSN.
Grz, Kris.
|||Hi there,
My first website I did using Visual Studio I used an sql express database. Most hosting companys only use SQL server so you'll have to do some changes to your express database to get it hosted. So it doesnt really matter which way you design your database.
The hosting company will usually place your database on a separate secure server where you'll be able to access through SQL Server Manager once you have a static IP address. I'm not sure which hosting company you use but I live in Ireland and the best company here for windows hosting iswww.blacknight.ie
I use the standard windows hosting which allows you have up to 16 websites and 16 SQL server databases. An excellent company.
I recommend if you are going to use this a lot, upgrade your package to Visual Studio pro and this includes SQL Server Developer edition which allows you to create a SQL Server 2005 database which makes it easier when you go to publish your application.
Hope this is some use to you.
Anthony
|||Hi Kris
So what you are saying is you can attach a database to an sql server without having to import it directly. Which means the database can run externally from the sql server. My hosting company I think offers it for free if you are attaching and they have a control panel which makes it user friendly to do this by yourself. I will contact them again to verify. www.sahost.co.za
|||
Hi,
about 1,5 years ago I tried out a free hosting for ASP.NET 2.0 where you could upload a .mdf file to and in their admin pages they provided such an attach procedure. Unfortunately I don't remember their name.
Grz, Kris.
MS SQL Error 823 I/O Error
Hi there,
I am reinstall my OS (Win2k Server) and try to attach back my database to SQL Server (MS SQL 2000).
After selecting MDF and LDF file. It come out with all those message below in my event viwer. And attach database action is fail.
I had check with Microsoft and download the latest Server Pack 3, but still nothing is change. I am panic here.
Can any one help me to solve this problem.
Your help is very much appreciated.
Thank you.
Dave
Message copy from Event Viwer.
17052 :
Device activation error. The physical file name 'C:\Program Files\Microsoft SQL Server\MSSQL\data\ultra_Log.LDF' may be incorrect.
Error: 823, Severity: 24, State: 6
I/O error (torn page) detected during read at offset 0000000000000000 in file 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\ultra_Log.LDF'.
17207 :
udopen: Operating system error 5(error not found) during the creation/opening of physical device C:\Program Files\Microsoft SQL Server\MSSQL\data\ultra_Data.MDF.
17204 :
FCB::Open failed: Could not open device C:\Program Files\Microsoft SQL Server\MSSQL\data\ultra_Data.MDF for virtual device number (VDN) 1.
17052 :
Device activation error. The physical file name 'C:\Program Files\Microsoft SQL Server\MSSQL\data\ultra_Data.MDF' may be incorrect.Judging from the error messages, are you certain you have the files in the correct path? Just trying to eliminate the obvious, here.|||Originally posted by MCrowley
Judging from the error messages, are you certain you have the files in the correct path? Just trying to eliminate the obvious, here.
Well....i just copy back the file to C:\Program Files\Microsoft SQL Server\MSSQL\Data
so....i just using the utility in the Enterprise Manager call Attach Database...is something like sp_attach_db but in windows graphic mode...
even i am using sp_attach_db command in command prompt, same mssg will appear...
here by i submit my database file...the log file and the data file...
please help to solve it...
i have no idea about all this...
thank you so much
Dave|||Check this link, it may be of relevance to your situation.
Resore database with corrupted log file (http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=uXRytePVCHA.2452%40tkmsftngp09&rnum=4)|||Hey...Thank a lot...
even process in bertween a lot of error reported but it still work. Now i can access to my database now...
Thanks. Very appreciated..
We started out with only the MDF file. The log file had been corrupted and lost due to disk failure and we found out we weren't backing up the
databases, only the file groups so we had a month of semi-useless backups.
Definitions:
<databasename> - this should be replaced, in any query detailed in the steps
below, with the database being recovered.
<database path> - this should be replaced with the path to the SQL data
files.
<database logfile> - this should be replaced with the filename of the SQL
database log file minus the extenstion.
1. In SQL Enterprise Manager, create a new database with the same name as
the old one. Make it the same data file size or larger as the old MDF.
2. Stop SQL Server.
3. Delete the new MDF file and rename the old one back.
4. Start SQL Server. The database should now show up tagged Suspect in
Enterprise Manager.
5. In SQL Query Analyser:
use master
go
sp_configure 'allow', 1
go
reconfigure with override
go
update sysdatabases set status=32768 where name='<databasename>'
go
dbcc rebuild_log('<databasename>','<database path>\<database
logfile>1.ldf')
go
NOTE: the second to last command is not a typo. The last variable of
<databselogfile>1.ldf is correct. If your database was named CONTACTS this
would give you CONTACTS_LOG1.ldf. Don't forget the '1' at the end.
This should result in a message similar to, "Transaction log successfully
rebuilt - transactional consistency lost."
6. In SQL Query Analyzer:
dbcc checkdb('<databasename>')
This may result in a number of errors. If so, go to step 7. If there are no
errors, the process may be complete. Check step 9.
7. In SQL Query Analyzer:
dbcc checkdb('<databasename>',repair_allow_data_loss)
You may have to set the database to single user for this to work. It will
alert you to this. This can be done in Enterprise Manager under the
databases properties.
8. Repeat steps 9 and 10 until step 9 results in no errors.
9. The database may end up with a status of "dbo use only". To clear this,
execute the following in SQL Query Analyzer:
use master
go
exec sp_dboption '<databasename>', 'dbo use only', 'false'
go
You can also do this last step in Enterprise Manager under the databases
properties.
I am reinstall my OS (Win2k Server) and try to attach back my database to SQL Server (MS SQL 2000).
After selecting MDF and LDF file. It come out with all those message below in my event viwer. And attach database action is fail.
I had check with Microsoft and download the latest Server Pack 3, but still nothing is change. I am panic here.
Can any one help me to solve this problem.
Your help is very much appreciated.
Thank you.
Dave
Message copy from Event Viwer.
17052 :
Device activation error. The physical file name 'C:\Program Files\Microsoft SQL Server\MSSQL\data\ultra_Log.LDF' may be incorrect.
Error: 823, Severity: 24, State: 6
I/O error (torn page) detected during read at offset 0000000000000000 in file 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\ultra_Log.LDF'.
17207 :
udopen: Operating system error 5(error not found) during the creation/opening of physical device C:\Program Files\Microsoft SQL Server\MSSQL\data\ultra_Data.MDF.
17204 :
FCB::Open failed: Could not open device C:\Program Files\Microsoft SQL Server\MSSQL\data\ultra_Data.MDF for virtual device number (VDN) 1.
17052 :
Device activation error. The physical file name 'C:\Program Files\Microsoft SQL Server\MSSQL\data\ultra_Data.MDF' may be incorrect.Judging from the error messages, are you certain you have the files in the correct path? Just trying to eliminate the obvious, here.|||Originally posted by MCrowley
Judging from the error messages, are you certain you have the files in the correct path? Just trying to eliminate the obvious, here.
Well....i just copy back the file to C:\Program Files\Microsoft SQL Server\MSSQL\Data
so....i just using the utility in the Enterprise Manager call Attach Database...is something like sp_attach_db but in windows graphic mode...
even i am using sp_attach_db command in command prompt, same mssg will appear...
here by i submit my database file...the log file and the data file...
please help to solve it...
i have no idea about all this...
thank you so much
Dave|||Check this link, it may be of relevance to your situation.
Resore database with corrupted log file (http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=uXRytePVCHA.2452%40tkmsftngp09&rnum=4)|||Hey...Thank a lot...
even process in bertween a lot of error reported but it still work. Now i can access to my database now...
Thanks. Very appreciated..
We started out with only the MDF file. The log file had been corrupted and lost due to disk failure and we found out we weren't backing up the
databases, only the file groups so we had a month of semi-useless backups.
Definitions:
<databasename> - this should be replaced, in any query detailed in the steps
below, with the database being recovered.
<database path> - this should be replaced with the path to the SQL data
files.
<database logfile> - this should be replaced with the filename of the SQL
database log file minus the extenstion.
1. In SQL Enterprise Manager, create a new database with the same name as
the old one. Make it the same data file size or larger as the old MDF.
2. Stop SQL Server.
3. Delete the new MDF file and rename the old one back.
4. Start SQL Server. The database should now show up tagged Suspect in
Enterprise Manager.
5. In SQL Query Analyser:
use master
go
sp_configure 'allow', 1
go
reconfigure with override
go
update sysdatabases set status=32768 where name='<databasename>'
go
dbcc rebuild_log('<databasename>','<database path>\<database
logfile>1.ldf')
go
NOTE: the second to last command is not a typo. The last variable of
<databselogfile>1.ldf is correct. If your database was named CONTACTS this
would give you CONTACTS_LOG1.ldf. Don't forget the '1' at the end.
This should result in a message similar to, "Transaction log successfully
rebuilt - transactional consistency lost."
6. In SQL Query Analyzer:
dbcc checkdb('<databasename>')
This may result in a number of errors. If so, go to step 7. If there are no
errors, the process may be complete. Check step 9.
7. In SQL Query Analyzer:
dbcc checkdb('<databasename>',repair_allow_data_loss)
You may have to set the database to single user for this to work. It will
alert you to this. This can be done in Enterprise Manager under the
databases properties.
8. Repeat steps 9 and 10 until step 9 results in no errors.
9. The database may end up with a status of "dbo use only". To clear this,
execute the following in SQL Query Analyzer:
use master
go
exec sp_dboption '<databasename>', 'dbo use only', 'false'
go
You can also do this last step in Enterprise Manager under the databases
properties.
Monday, February 20, 2012
MS SQL .mdf .ldf files corrupeted.
I have lost my my database due to hardware failure some how I have recovered it now but the problem is when I add in my database Sql unable to recocnize it. I tried some software but all i vain. Any good software or way to recover it.I'm guessing that someone here can help, but at least I need more details to figure out what you need.
I don't understand how you've recovered your database if you can't get SQL Server to recognize it. That seems like a pretty fundamental part of "recovery" to me.
Can you explain what you've actually got, what you've tried, and the results of those attempts? I'm pretty sure someone here can help, I'm just not clear on how that might be yet.
-PatP|||Well I have recovered it via a data recovery tool but when I add it to my database sql give me an error that sql is unable to recognise it and its not a valid sql file bla bla.|||One thing more I already tried mssqlrecovery software from officerecovery.com|||so are u saying that u recovered a .mdf and .ldf file and trying to attach it back or something??
as pat mentioned, u need to explain what exactly u have got recovered and what steps u have taken... then and then some one here might be able to help u with the situation in hand.
I don't understand how you've recovered your database if you can't get SQL Server to recognize it. That seems like a pretty fundamental part of "recovery" to me.
Can you explain what you've actually got, what you've tried, and the results of those attempts? I'm pretty sure someone here can help, I'm just not clear on how that might be yet.
-PatP|||Well I have recovered it via a data recovery tool but when I add it to my database sql give me an error that sql is unable to recognise it and its not a valid sql file bla bla.|||One thing more I already tried mssqlrecovery software from officerecovery.com|||so are u saying that u recovered a .mdf and .ldf file and trying to attach it back or something??
as pat mentioned, u need to explain what exactly u have got recovered and what steps u have taken... then and then some one here might be able to help u with the situation in hand.
Subscribe to:
Posts (Atom)