Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

Photo

Database Security


  • Please log in to reply
6 replies to this topic

#1 Andrew

Andrew

    Bleepin' Night Watchman


  • Moderator
  • 8,259 posts
  • OFFLINE
  •  
  • Gender:Not Telling
  • Location:Right behind you
  • Local time:06:19 AM

Posted 31 December 2009 - 05:32 PM

Okay, so here's the deal:

I'm finally delving into creating databases and interacting with them via a self-built front end. At the moment, I'm focusing on SQLite since it can run without needing a daemon running all the time.

I want to restrict access to the data contained in the database. This is not a high-security environment, nor are any critical data in jeopardy. This is strictly "let's test this" kinda stuff.

My first goal is to deny easy access to the database by someone using a generic SQlite tool to dump tables or whatever. I plan to accomplish this by encrypting the DB file with a symmetric cipher (cipher TBD, open to suggestions and not married to symmetric ciphers.)

The first issue that comes to mind now is where to store the decryption key. Storing it in plaintext within the executable would render it available to anyone with a string viewer. My current plan is to merely obfuscate the key with a simple replacement cipher hardcoded into the program, but would like a better solution.

Next is how to allow for multiple (non-concurrent) users, with varying levels of access, each with their own username/password combo. Obviously I can't store this data inside the encrypted database since I'd need to authenticate the user before decryption takes place. My idea is to have a separate DB containing the user info that gets loaded at runtime.

This second DB (I'll call it usersDB) has a single table (called users) with three columns: username as VacChar, pwdHash as VarChar, and accessLevel as integer (accesslevel is interpreted by the frontend, which applies the restrictions associated with the accesslevel. Values are 0-5 where 0 is access denied and 5 is SuperDuperDBA; invalid values default to 0.) I'm considering a fourth column that hashes the other three + salt to verify that there haven't been unauthorized alterations to the record.

The usersDB.users.pwdHash column values are generated by MD5'ing a static salt string prepended to the user's actual password.

The pseudocode used to query the usersDB is like this:

var record as RecordSet = userDB.SQLQuery("SELECT * FROM users WHERE (userName LIKE '" + userName + "') AND (pwdHash LIKE '" + MD5(salt+password) + "');")

If record.countRecords <> 1 then
//GO AWAY
Else
enumerateUserPermissions(record as RecordSet) 
decryptMainDB()
End If



Any thought/suggestions/critiques so far?

BC AdBot (Login to Remove)

 


#2 groovicus

groovicus

  • Security Colleague
  • 9,963 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Centerville, SD
  • Local time:07:19 AM

Posted 31 December 2009 - 07:07 PM

I don't have time to read this right now, but the first thought is why worry about encryption? Databases are user name/password protected, so unless someone has those, or admin access to the database, which also requires a username and password, nobody can get it anyway.

#3 Andrew

Andrew

    Bleepin' Night Watchman

  • Topic Starter

  • Moderator
  • 8,259 posts
  • OFFLINE
  •  
  • Gender:Not Telling
  • Location:Right behind you
  • Local time:06:19 AM

Posted 31 December 2009 - 08:27 PM

Erm, no. This is an SQLite database. Anyone with access to the DB file can dump the contents, modify, etc.

#4 groovicus

groovicus

  • Security Colleague
  • 9,963 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Centerville, SD
  • Local time:07:19 AM

Posted 31 December 2009 - 09:40 PM

Oh, I see; no GRANTS. Embedded system.

#5 Andrew

Andrew

    Bleepin' Night Watchman

  • Topic Starter

  • Moderator
  • 8,259 posts
  • OFFLINE
  •  
  • Gender:Not Telling
  • Location:Right behind you
  • Local time:06:19 AM

Posted 31 December 2009 - 11:39 PM

Exactamundo.

Amazing Andrew Learned A New Term: Grants.

Googling Now

#6 Totty

Totty

  • Members
  • 29 posts
  • OFFLINE
  •  
  • Local time:01:19 PM

Posted 02 January 2010 - 07:32 AM

I havn't been able to read this fully but for the first issue could you not make the decryption key a function of the users password? Then I guess its probably not suited to a multi user environment if you do it that way.

But I'd never store the decryption key on the same system as the one the database is being run on. I'll have a good think on this and get back to you. If you're into security a good book is applied cryptography by Bruce Schenier (I think thats how you spell it)
OS: 1. Slackware Linux........................... 2. Windows XP Home Edition
Mobo: Asus P5N-D.................................GFX : Nvidia Geforce 8800GTS 512MB
CPU : Intel E8400 Core 2 Duo @ 3.6GHz........... RAM : 2GB DDRII Coirsair Twinx
HDD1: Maxtor 80GB SATA II Hard drive.............HDD2: Western Digital 40GB IDE
Case: Antec Gamer 300 case.......................PSU : Corsair HX620 620W - Modular

#7 Andrew

Andrew

    Bleepin' Night Watchman

  • Topic Starter

  • Moderator
  • 8,259 posts
  • OFFLINE
  •  
  • Gender:Not Telling
  • Location:Right behind you
  • Local time:06:19 AM

Posted 02 January 2010 - 01:21 PM

I could make the user password the key to decrypt the DB, but like you said that would make it a single-user DB. It would also complicate the process of changing the password a great deal.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users