Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
AskSQLTeam
Ask SQLTeam Question
0 Posts |
 Posted - 2002-05-06 : 09:01:17
|
| Edward Fernandes writes "I am developing an application for a PDA using Embedded VB & SQL CE. In the application we have to transfer data from and to a desktop PC which has MSDE installed.Now whatever data is tranferred from the PDA to the Destop PC is stored in the MSDE on the Desktop PC. Now we want to ensure that nobody is able to tamper with the MSDE database on the Desktop PC. For this we are programmatically deleting all the users except "sa" on the PC and also changing the password of "sa"So now nobody can connect to the MSDE Database unless he knows the "sa" password. Only thru the PDA Application can the tranfer of data take place in which the "sa" password is hardcoded as the password on the Desktop PC.But we just found out that if we create a database with the same name on some other machine having SQL Server & then stop the SQL Server on that machine and then copy the .mdf & .ldf file from the MSDE Machine to that machine we were able to view or modify the data on that machine and then after modification transfer the data back to the MSDE database on the Desktop PC.Can u please suggest any way we can prevent that, so that nobody can view / modify data even is they transfer the physical .mdf & .ldf file to another machine." |
|
|
chadmat
The Chadinator
1974 Posts |
Posted - 2002-05-07 : 01:38:11
|
| Lock down security on those files/diectories using NTFS file security.If you have a FAT file system, you need to upgrade to NTFS.-Chad |
 |
|
|
goblyn27
Starting Member
39 Posts |
Posted - 2002-05-23 : 12:54:09
|
| That'll only work, of course, if the desktop app is residing on an NT or Win2000 operating system. If it is residing on a Win95/98 OS then you dont have the option to convert the file system to NTFS. I dont think there is a way around the sa thing. Thats kind of the point of the sa login. But I could be wrong about that. I'll be insterested in hearing what other people here suggest. One thing to keep in mind if data security is an issue is that your application can internally encrypt and decrypt data before placing it in the database, though there would be a significant performance hit if the server sees a lot of activity. That way, anyone that swipes the files and tries to open them on their own sql server will just get a lot of rows they would have to spend a very very long time (and a lot of cereal box decoder rings) trying to understand. That way the application is as necessary as the datafiles. Likewise, for a private encryption key you can use something specific about the installation that would be unique to that computer, but the downside is that that can lock a legit user out if they ever need to format and reinstall their system."DuuuDe!! I suck!" |
|
|
|
|
|
|
SQL Server Security