I am developing one Inventory project to sell by using C# and MS Access. After sell this product, Client(or any other) may open the document and read it. I need to overcome this less secure.
I googled it and found solution that Password protection. But lot of tools there to breach this. Finally I need to close all the ways for steal and view data.
If you feel that the password protection feature of the Access Database Engine (ACE) does not offer a sufficient level of security against unauthorized "snooping" of the data then you really should consider using SQL Server instead of ACE as the back-end database.
Related
Since I am going to ask simple question any help will be appreciated.
I went through SQL tutorial almost everything including (DDL, DML), however, now I have to design a library management application and found that I need to include security such as Administrator, Employee.
I searched the Internet and found that (DCL) is the way to do that
My question :)
1) since I am using ms access, is (DCL) option in it?if not how to apply security in ms access
Your question isn't clear as to what exactly you're trying to do.
If you have an Access DB with a connection to a SQL Server, you can run DCL commands via VBA SQL calls (not from the query window) to apply user control to the SQL Server.
However if you're asking about user control for an MS Access front-end, DCL does not apply, and furthermore, your options are very limited (if any serious level of security is required).
Friends and I use to race to see who could "hack" past MS Office security the fastest... as in, one to two minutes. Nowadays, Microsoft doesn't bother including the features.
You could try using the older .MDB file format, and applying Access User Level Security, as outlined in the Access Security FAQ: ULS was removed from the newer .ACCDB file format.
Recognize, though, that Access security definitely isn't unbreakable. If there's a need for strong security, you'd probably be better off putting your backend database into SQL Server.
(Source)
If you want to learn about Access, I'd suggest you do a couple Access tutorials (not SQL). The two are related but far from interchangeable, kind of like how VB and VBA are related but not interchangeable.
No, DCL is not an option in MS Access.
When you are researching things like this, keep in mind that a lot of generic database concepts have limited application in MS Access because MS Access does not provide many features of advanced database management systems.
If you have chosen MS Access as your platform, try to read only MS Access based sources of information, not generic database information. Otherwise you'll get confused.
Here are some examples of implementing security in MS Access
I know link based answers are not an answer but this may help
Using windows login, so no extra login is required
http://www.blueclaw-db.com/download/access_security_alternative.htm
Native MS Access security - do not use this, it's too complicated and probably not supported any more
https://www.thoughtco.com/microsoft-access-user-level-security-tutorial-1019981
Some other suggestions:
How to implement user-level security in Access 2007
My scenarion is MVC Blog (funnelweb) installed on a server named WEB. The SQL Server 2005 runs on DB. FunnelWeb site requires access to its own database. I have create a new database using SQL Server Management Studio and had named it FunnelWeb. I want to use SQL authentication, so I went ahead and created a SQL login FunnelWebAdmin. In the login mappings I have mapped FunnelWebAdmin to FunnelWeb database, and have granted him a dbowner permission on a db. I have not granted a login any server roles.
SQL Authentication is enabled for the server.
My question is:
Do I need to grant this login any server roles, so that the web site can connect to a database using SQL authentication? If yes, which are the minimum one's in order for site to be able to manipulate database.
Unless I'm missing something setting that user in the role DBAdmin will give it the right to login. It will give it full rights and control over the database.
Be sure you lock down that web application. Giving admin rights to a DB from a web app is dangerous at best. It leaves you open to SQL injection, which can open the door to all sorts of issues. A good attacker (or a mediocre one with access to google) can exploit an SQL Injection attack and gain full control over the operating system if the server isn't locked down properly. http://sqlmap.sourceforge.net/doc/BlackHat-Europe-09-Damele-A-G-Advanced-SQL-injection-whitepaper.pdf
Even if they can't get control over the OS, you still need to worry about data theft, insertion of XSS or XSRF scripts, or any number of attacks.
I'm not saying not to do it, just to be careful and be sure you know what you're doing. Getting access to a database via a web app is childs play if there are any vulnerabilities. There are toolkits that you can buy that do it for you, so attackers don't even need to know what they're doing.
I really have no idea what your experience level is, so forgive me if I'm telling you something you already know. Your question indicates that you're more on the "beginner" end of the spectrum, but I may be wrong.
Assuming I'm right, however, I would really caution you to spend a lot of time on these sites,learning everything you can. They don't teach this stuff adequately in school, or in the "Learning programming" resources (books, web, videos, etc).
OWASP Top 10
Writing Secure Code (Microsoft)
Even if the website itself is not Internet accessible (say it's running on a corporate Intranet and only logged in users have access) you still need to be cautious. Statistics show that disgruntled co-workers with access are just as much of a threat as outside attackers. Just something to bear in mind.
I have a firebird database in format .GDB.
If I setup a interbase server and I open the .GDB with (for ex. IB Expert) with the default password I can open the Database.
So I'd like to prevent the database to be opened by other softwares how could I do it?
with "gsec.exe" I can add and modify users, but this doesn't give me a tool to prevent a database to be opened by a new firebird instance.
As far as I know you can not avoid a .GDB or .FDB database to be opened by a Interbase or Firebird instance. It is a file (or group of files) with a known structure for such an instance and, provided the (malicious) user knows the SYSDBA password, it can be accessed.
Said this, some suggestions:
If you do not need it make sure the Embedded version of Firebird is not present in your installation to avoid giving the user a tool with which the database could be accessed directly.
As far as possible restrict any access to the directory where the database will be. Firewalls, directory user rights, etc.
Use gsec.exe as you said to add/modify users access rights. While this will not prevent the SYSDBA to access the database at least it will prevent a normal user to do so.
Encrypt the filesystem where the database will be. You can find more info on this at How to protect data in Firebird database.
If the database is to be accessed through insecure networks like Internet you could consider using SSL. Check How to protect the connection over insecure networks.
Check Firebird Security FAQ for more information.
There is another solution that might help you partially: encrypting before storing data and decrypting when reading data, but it can cause some problems on searching through the data, since you will not be able to use some indexes (actually only PK and FK indexes will work flawlessly).
I know this is not the answer which you expected, so sorry about that. Maybe someone else will come with an alternative and better solution. :-)
HTH
We have a problem where one of our customers is changing data directly in the database.
As we have an API, we'd prefer our customers to use this. We have threatened not to support their solution if they persist in manually changing data.
My query is, is there a technical way we can prevent access to the database from anything other than our application?
This is a sql server database, and our customers own the server and administer the DB server, So essentially we need a way to lock out SA.
Thanks
First things... you can't:
lock out sa or sysadmin rights at all at the server level
lock out db_owner/dbo at the database level
Now we've cleared that one up, who is accessing data directly?
If you mean end users are changing data, then you have a security issue: they should only be able to use the API and not even be able to connect.
If you mean sysadmin level users (eg DBAs or BOFH types) then there may be a legitimate reason. Does your API support all operations? As a DBA, I had to do open table surgery on badly written 3rd party apps now and then
If end users have sysadmin level rights, then you have a politics issue within the client company
Edit:
After comment by OP on their question... sysadmin users can disable triggers...
Is you API public? It shouldn't be if you can change data without any authentication. I recommend using some internal authentication mechanism. A basic challenge/response protocol that ensures that the incoming query is safe to execute, or something like that.
My customer is a dental practice that has bought a piece of practice management software. This software was installed on their local server, including a patient database, a schedule and all manner of medical records. Now they want me to write some utilities for them that aren't provided with their package, and for this I need the ability to query this database.
I tried calling tech support of the software manufacturers (Patterson/EagleSoft), and it's difficult finding anyone who understands the technology enough to answer my questions. As far as I can tell, there's no API for their software, and understandably they're reluctant to tell me how to query the DB directly, programmatically. They do have an interactive query window, but obviously that's no good for writing automated queries. All that they would let on is that somewhere there's a SQL Server DB, but the ODBC drivers to connect to it are SQL Anywhere drivers (huh?).
So I searched around on the server and couldn't find any database files. Then I discovered that the installation creates some kind of proprietary virtual machine, which is only visible to the EagleSoft software. But while they've been very good at insulating their DB in layers of obfuscation, they have left open an ODBC driver, which is indeed an SQL Anywhere connection.
Now after that fascinating and lengthy preamble, here is my question: What queries can I run over this ODBC connection to interrogate the DB as to its structure? If it's a SQL Server DB underneath I could use the sysobjects table, but I don't fully grasp how you can use a SQL Anywhere ODBC connection to connect to a MSSQL DB. And If they were misinforming me and it really is a SQL Anywhere DB underneath, what are the queries to run to get at the DB structure?
And if there's anyone else out there who's ever succeeded in actually querying EagleSoft (or any similar proprietary package) - please tell me how you did it!
Turns out the simplest way to do it was to write a little app using OdbcDbConnection, and connect using the DSN installed with the software. It took one probing 'select * from sysobjects' to reveal that it is, indeed a MS-SQL database underneath all that, and I'm good to go from there!
I'd use a tool like squirel which is great at browsing any database to check if anyone was successful with "SQL Anywhere" this google result:
http://blog.gmane.org/gmane.comp.db.squirrel-sql.users/month=20091001
Shows that others have managed to get squirrel to do this. It's quite easy to use... assuming of course you manage to get the connection working!
A few tools that might help are SQLWorkbench and Django. I use SQLWorkbench to copy the data from the production system into a Postgres database so I can hack on it without damaging the production environment. Then I use Django's inspectdb to generate models of the database environment. From there it's easy to create 'views' into the database and templates to display exactly what I want.
UPDATE: As of Eaglesoft 19, it looks like Patterson has password protected the database and they have gone out of their way to prevent users from getting at the data without paying them for access.
UPDATE: Like I mentioned before, Eaglesoft 19 has a locked-down version of the database. For read-only access you can call Patterson and ask them for the password to the "Database Admin" section of their "Technical Reference" tool that is installed on your server. Once you are in there, there's an option to set a read-only password for access to the database. The username is 'dba' and whatever password you set. Some times it takes a bit of back-and-forth with them to give you access, but my solution was to say "We've been putting patient data into Eaglesoft for over a decade and we've always had access to the database. Now you're restricting it and telling us we have to pay for access. It sounds like you are trying to extort money by holding our data hostage. I should probably run this by our legal team."
EDIT: Nov 18 2022: You can still easily get read-only access to an Eaglesoft database in 21.20.08 (the latest version) by calling Patterson and getting the "day password" for Technical Reference. From there you can enable a read-only user. Based on some of the changes Patterson is making to their application architecture and the database, I suspect they will stop using direct connections to the database in the next year or two. When they make that change, you will only be able to access the database through their API Server. After playing "phone tag" with one of their salesbros for several weeks and doing some light social engineering, I managed to get their price list for going through the API server. It's atrocious. Most offices pay ~$500/mo to Patterson for free tech support and free upgrades. They want developers to pay nearly as much per office for access to the API. They've realized they can lock practices out of their own data and monetize it. We are working with a company that is actively developing a replacement for Eaglesoft to get away from this horrible vendor lock-in.
I have written my own PHP driven website to access and manipulate data in my eaglesoft database. You simply create odbc connection to local DNS entry and done. To see database structure you can use the technical reference included in eaglesoft or advanced query tool.