UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Is There And Alternative To Database Encryption, Any Version    
 
   
johnpdmccall
post Jun 27 2020, 05:46 AM
Post#1



Posts: 1,850
Joined: 14-March 00
From: Ayrshire, Scotland


Hi Folks

Here's my set up:
Back End is encrypted
FrontEnd.accde links to backend tables
Front End Security uses Richard Rensels's code
Also I use an Audit Trail - unfortunately the code doesn't credit the author.

Here is the problem
Currently I can access the data in the tables by importing their links from the FE to a new accdb
If I encrypt the Front end then I can't link the tables without the db password.
However that means that the user needs to know the database password for the front end in order to open it, which link of defeats the purpose of using some of the user level features in Richards code.

The question is: Is it possible to use some vba or something other than database encryption to prevent users importing the table links from my Front End?

Thanks for any help


--------------------
Cheers,
John
Go to the top of the page
 
isladogs
post Jun 27 2020, 06:13 AM
Post#2


UtterAccess VIP
Posts: 2,396
Joined: 4-June 18
From: Somerset, UK


I'm not familiar with Richard's code so I don't know what security you already have or don't have.
If your FE is an ACCDE file, users CAN import or link tables from it whether or not it is encrypted.
If you ensure the navigation pane is hidden or other security measures are applied, users won't be able to view the connection strings so won't be able to deduce the BE password.

For a comprehensive article on this topic, see my article Improve Security in Access databases
That should be more than sufficient for all practical purposes.
If your data is highly sensitive then you could try the approach in this example app: Encrypted Split No Strings Database or better still use e.g. a SQL Server BE.

Hope that helps

--------------------
Colin (Mendip Data Systems)
Website, email
Go to the top of the page
 
johnpdmccall
post Jun 27 2020, 06:49 AM
Post#3



Posts: 1,850
Joined: 14-March 00
From: Ayrshire, Scotland


Thanks Colin,

I can created a New.accdb and (in the New.accdb) import the tables from my un-encrypted FE.accde to the New.accdb. The tables in the FE are links to tables in the encrypted BE.
That's my problem.

The link to the article goes here:
https://www.w3schools.com/SQL/sql_alter.asp


This post has been edited by johnpdmccall: Jun 27 2020, 06:50 AM

--------------------
Cheers,
John
Go to the top of the page
 
johnpdmccall
post Jun 27 2020, 07:22 AM
Post#4



Posts: 1,850
Joined: 14-March 00
From: Ayrshire, Scotland


Hi Colin, and anyone else who can help

I don't think this is correct:
QUOTE
If your FE is an ACCDE file, users cannot import or link tables from it whether or not it is encrypted
.
I've just been able to do that using three new access databases

NewBE.accdb - encrypted and contains tblRecords (no other objects)
NewFE.accde - not encrypted, linked to tblRecords

In NewMMSAccess.accdb:
It is not possible to Link to the linked tables in NewFE.accde
However is it possible to import the link to tblRecords from NewFE.accde and view the data without being asked for any password.

I'm on Access 2016 so I also just did an update and it is still allowing me to do the above.

tblRecords is the only object.

--------------------
Cheers,
John
Go to the top of the page
 
nvogel
post Jun 27 2020, 07:24 AM
Post#5



Posts: 1,120
Joined: 26-January 14
From: London, UK


If security is a requirement then you really should consider using a secure DBMS like SQL Server, Oracle, PostgreSQL, etc. All of those are available in free editions.

If your data includes personal information subject to GDPR then you shouldn't be using Access in my opinion (but I am not a lawyer).


This post has been edited by nvogel: Jun 27 2020, 07:24 AM
Go to the top of the page
 
GroverParkGeorge
post Jun 27 2020, 07:28 AM
Post#6


UA Admin
Posts: 37,474
Joined: 20-June 02
From: Newcastle, WA


While it is possible to put hurdles in front of your Access users, if your data REQUIRES total security, or as close to total security as possible, you need to move that data to a more secure storage, i.e. SQL Server, etc.

Look at this way, if your data is so valuable that it's worth a thief's time to break through your efforts to secure it in Access, then it's too valuable to risk, and that means Access isn't the right environment for it.

If you're only worried about casual users poking their noses into places you would prefer they not go, then Access can indeed be made secure enough for that.

--------------------
My Real Name Is George. Grover Park Consulting is where I did business for 20 years.
How to Ask a Good Question
Beginning SQL Server
Go to the top of the page
 
johnpdmccall
post Jun 27 2020, 07:36 AM
Post#7



Posts: 1,850
Joined: 14-March 00
From: Ayrshire, Scotland


Ok thanks for your help folks. It's just to stop folks messing about. Anything valuable is on SQL.

--------------------
Cheers,
John
Go to the top of the page
 
GroverParkGeorge
post Jun 27 2020, 07:53 AM
Post#8


UA Admin
Posts: 37,474
Joined: 20-June 02
From: Newcastle, WA


I can't remember if I've shared this story here at UtterAccess, but this seems like a good place to repeat it in any event.

One of the senior HR VPs at a company where I worked gave this talk regularly. In it she pointed out that MOST employees come to work every day thinking, "I wonder what I can do today to impress my supervisor and get a promotion or a raise." Very, very few come to work every day thinking, "I wonder what I can screw up today so I'll get fired."

In other words, the problem isn't that you can't trust the people who you work with; the problem is that you don't trust them.

--------------------
My Real Name Is George. Grover Park Consulting is where I did business for 20 years.
How to Ask a Good Question
Beginning SQL Server
Go to the top of the page
 
PhilS
post Jun 27 2020, 08:34 AM
Post#9



Posts: 700
Joined: 26-May 15
From: The middle of Germany


QUOTE (nvogel)
If your data includes personal information subject to GDPR then you shouldn't be using Access in my opinion (but I am not a lawyer).

You cannot generalize personal information. It's not an issue to store low risk personal information in an Access database if you add reasonable security measures to the Access application.

I'm not a lawyer either, but I teamed up with two certified data protection officers to write a guide on the GDPR particularly for Access developers.

--------------------
A professional Access developer tool: Find and Replace for Access and VBA
Go to the top of the page
 
tina t
post Jun 27 2020, 10:06 AM
Post#10



Posts: 6,680
Joined: 11-November 10
From: SoCal, USA


with all due respect, George, that seems to miss the point. security isn't about the majority of people who you can trust, it's about the minority you can't trust. protecting a database is no different than protecting your house or your car - and who would advise not locking your doors at night? or leaving the key in the ignition?

and of course, a lot of damage can be done unintentionally by a person who doesn't know how much s/he doesn't know. you wouldn't take an adult's hand to cross the street, but you would take a two-year-old child's hand when going anywhere outside your home or fenced yard.

hth
tina

--------------------
"the wheel never stops turning"
Go to the top of the page
 
johnpdmccall
post Jun 27 2020, 10:31 AM
Post#11



Posts: 1,850
Joined: 14-March 00
From: Ayrshire, Scotland


Thanks PhilS for the link to the paper on GDPR - I'll have a good look at that - I'm a developer for small business and need all the help I can get thumbup.gif

Hi Tina T - I agree, and in my humble experience if you leave something open to being messed up, it will be!
Substitute your own favourite word for "messed".

--------------------
Cheers,
John
Go to the top of the page
 
isladogs
post Jun 27 2020, 11:45 AM
Post#12


UtterAccess VIP
Posts: 2,396
Joined: 4-June 18
From: Somerset, UK


Hi @johnpdmmccall
Sorry, I've been away from my computer for several hours.
I must have had a senior moment as I wrote the opposite of what I meant in post #2 (and messed up both links!)

I've now corrected the second line in post #2 which should of course have been:
QUOTE
If your FE is an ACCDE file, users CAN import or link tables from it whether or not it is encrypted.

That's also true for queries.
Of course forms, reports, modules cannot be imported from ACCDE files whether or not they are encrypted

I've also now fixed both links in that post.
Hope you can spare time to have a look at them!

--------------------
Colin (Mendip Data Systems)
Website, email
Go to the top of the page
 
tina t
post Jun 27 2020, 12:04 PM
Post#13



Posts: 6,680
Joined: 11-November 10
From: SoCal, USA


QUOTE
...in my humble experience if you leave something open to being messed up, it will be!

sooner or later, and sometimes with no intent toward theft or deliberate damage. i'm reminded of a co-worker at a former job, who knew much less about Access than he thought he did. so he opened an unprotected shared db (not one of mine!) on the server, opened tables in Design view, and made changes and saved - all this on the server, and while the db was in use. that didn't end well. another employee, another time, started messing with server permissions, trying to protect one of his folders on the server; he ended up somehow deleting all permissions for a whole block of employees - don't ask me how, i'm not a server admin - and that really didn't end well. these were basically good, honest employees with no intention to cause harm - who only thought they knew what they were doing, and got in over their heads, because nothing stopped them from going where, and doing what, they shouldn't.

hth
tina

--------------------
"the wheel never stops turning"
Go to the top of the page
 
FrankRuperto
post Jun 27 2020, 05:08 PM
Post#14



Posts: 1,099
Joined: 21-September 14
From: Tampa, Florida USA


There's plenty of search results on the web for tools and ways to hack Access, Windows, etc.
One search result shows you how to find DSN credentials for logging into db servers.
Even if the backend were "secure", a disgruntled user can still do damage by using the frontend to maliciously edit data.
Best damage control is to make regular backups.
This post has been edited by FrankRuperto: Jun 27 2020, 05:32 PM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
nvogel
post Jun 28 2020, 04:37 AM
Post#15



Posts: 1,120
Joined: 26-January 14
From: London, UK


QUOTE
(PhilS) It's not an issue to store low risk personal information in an Access database if you add reasonable security measures to the Access application.


Hi Phil,

I can't agree with that statement and here's why. Securing the application and not the database does nothing to protect data since the chances of a data breach ever being confined to one application are practically zero. Effectively you would be creating a facade in front of the data which increases rather than decreases overall risk.

As data management professionals we have to be able to fulfill the principle of "security by design and by default" and not just the appearance of security. Given that state of the art database security is easily available and costs nothing to obtain, and given that ACE is such a stand out exception in lacking security features that most people take for granted it's hard to see how anyone could honestly justify the choice of an ACE database where security by design is mandated by law.
This post has been edited by nvogel: Jun 28 2020, 04:38 AM
Go to the top of the page
 
Jeff B.
post Jun 28 2020, 07:38 AM
Post#16


UtterAccess VIP
Posts: 10,489
Joined: 30-April 10
From: Pacific NorthWet


<Tina>

I'll offer an additional group of folks … people who think they're doing "X" and instead are doing "#99". "If it can go wrong, someone will find (maybe inadvertently) a way … and if it can't go wrong, someone will still find a way <g>"

--------------------
Regards

Jeff Boyce
Microsoft Access MVP (2002-2015)

Mention of hardware or software is, in no way, an endorsement thereof. The FTC of the USA made this disclaimer necessary/possible.
Go to the top of the page
 
tina t
post Jun 28 2020, 09:14 AM
Post#17



Posts: 6,680
Joined: 11-November 10
From: SoCal, USA


QUOTE
people who think they're doing "X" and instead are doing "#99".

oh, yeah, lol! though a few times i've found myself to be one of those people, from a programming standpoint - yikes! ;) the majority of employees are hardworking and honest, they're just looking to get their work done quickly and accurately - and maybe improve a process to impress the boss and get that raise/promotion. hacking even a lightly secured database would never occur to them because doing something "illegal" is not on their agenda at all. but if doors are left open, some of those employees might go through them, and end up doing "#99" when they really thought they were just doing the harmless "X".

hth
tina

--------------------
"the wheel never stops turning"
Go to the top of the page
 


Custom Search


RSSSearch   Top   Lo-Fi    7th July 2020 - 11:02 AM