Security when source code is public

Question

I realize that the answer to this question is likely quite obvious (if somewhat inconvenient to me), but I'm hoping someone will have an ingenious solution.

I'm slowly building an application in my free time that I hope will be useful at work. It's a simple tracking application for the assignment of peer reviews. Basically, I'm just trying to teach myself some C#.

My problem is that since I really can't install anything, and I can't use my own website for this (two reasons - 1) the DoD probably wouldn't allow it, 2) I want this to be a desktop (WinForms) project, not Web), I'm using Jet (like Access) as a data store.

I need a way to secure the database from prying eyes, since there are some things I really only want an Admin-level user (like a team lead) to access. I've basically decided to set a database password. A password will be picked at install time, used to secure the database, then encrypted for the application to pick up, decrypt, and use to open db connections.

My problem is that I want this code to be somewhat public. I eventually want to post my code on my website, and ask StackOverflow and maybe the programming subReddit for some quick reviews and insights. Think of it like a poor mans mentorship program. For maintenance, especially after I leave this job, the source will eventually be available to my co-workers. If they have access to the encrypted 'key file' and the source, they'll be able to determine the db password.

Is there any way to code this so that even with the file and the code, my co-workers won't be able to get into the db? I assume not, but it's worth something to ask.

If there's no way to do this, I guess my second option is to change the encryption when I put it up on my site (change the encryption equivalent to a hash - IV? - to something different when published), and provide the source in a password-protected rar-file, giving the password only to management.

Any ideas?

Answer 1

Unfortunatly, Access security just isn't that good. Even if your connection credentials weren't in your source, it would only be a matter of time before someone got in if they really wanted to.

The most secure option with access is to store the file on a server with good file-share permissions setup and use ODBC to get to it. - Doesn't really solve your distribution problem though.

Why not take a look at some of the alternatives out there? SQL Compact is more secure and provides a very similar programming experience. If you can afford to go a bit 'heavier' SQL Express is excellent. There are also lots of good open source offerings. Firebird might suit you well here.

Hope this helps..

Edit: S.lott is spot on here. Ultimately, if people have access to your code and your db and know what do do with it, they'll be able to get in.

Answer 2

There is no "Security Through Obscurity". If you consider all code public at all times, you stand a better chance of implementing something that is actually secure. If you "hide" code or "hide" the passwords, you've made a terrible mistake.

Here's how to hack the password on Jet. http://lastbit.com/access/

Security is a deep issue. You can't throw a password in a file. You can throw hashes of passwords in files.

You have two complementary issues.

• Authentication. Who is the user? This is what passwords and passphrases can tell you: Who's connecting.

• Authorization. What can this user do? This is why you have separation of duties. Security officers who set passwords and users who must provide passwords and have access to data need to be separate people.

---

Edit

"A password will be picked at install time, used to secure the database, then encrypted for the application to pick up, decrypt, and use to open db connections." Doesn't work. The encryption key for the password file is available in the application, making it all open.

"Is there any way to code this so that even with the file and the code, my co-workers won't be able to get into the db?" Yes. This is easy. Use hashes of passwords, not encrypted passwords.

"giving the password only to management" Wrong. If you give the password to someone then too many people know the password. This breaks authentication. People have to set their own passwords, otherwise they're not authenticated.

---

Edit

What to do?

1. Define -- precisely -- your authentication and authorization needs. Don't pick a technology. Define the users and their use cases. Define the authorizations each class of users has. Don't pick the technology. Define the access.

   You don't mention really, really important things in your question. You don't mention if you have multiple users, for example. You just mention a specific technology (JET) and a specific technique (the DB-level password). You don't mention if these users share a database.

   If you have multiple users with a shared database, then it's best for this database to be on a server somewhere. Not on a desktop somewhere. Not part of a specific desktop. Not spread across multiple desktops.

   If you don't have a shared database -- if every user has a private database -- then you have separate installations where the ordinary Windows security is fine. Why obscure anything?

2. Pick an architecture.

   • You have Active Directory. This gives you user names and securely hashed passwords. Leverage this.

   • SQL/Server can use AD for user authentication and authorization. This is reasonably secure if people don't share their passwords.

3. Build something that works.

   • AD groups.

   • Central DB in SQL/Server.

   • Admin procedures for creating users, resetting passwords, moving users from group to group, etc. This isn't hard. It's in the AD documentation. Any Windows Sysadmin can provide guidance on how they like to do this. Document the procedures. They're part of the security model.

   • Winforms application that can be installed on desktops. Users will be leveraging their existing windows credentials. Logged into windows means your winforms app can log them into the database and away they go. Securely.

   • MSI for the desktop component. Since there's no "master db password" or other junk, they're just installing a simple app. They configure the location of the central DB server. They login with their existing windows credentials.