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
> Hiding The Be Database Decryption Password, Access 2007    
 
   
UrsaMajor
post Aug 17 2016, 06:48 PM
Post#1



Posts: 5
Joined: 17-August 16



Hi,

Many years ago cruising UtterAccess I came across a lively discussion on securing the then new accdb file in Access 2007. Coming back to UtterAccess I can find reference to the fact that Alan Cossey was inspired through the discussion to develop a set of tools to hide the BE database decryption password that is normally stored in the MSysObjects table in the FE database. These tools were made available in UtterAccess under the name vPPC. However, I can't find the original thread or the tools.

The discussions I have found about vPPC are a bit old and links to the tools and, more importantly, the thread, don't seem to work any more. Does anyone know if the tools and the thread still available anywhere?

Regards
Go to the top of the page
 
DanielPineault
post Aug 17 2016, 07:15 PM
Post#2


UtterAccess VIP
Posts: 5,951
Joined: 30-June 11



How about

http://www.hitechcoach.com/index.php/micro...oolkit-for-2007 ?

Or

http://www.UtterAccess.com/forum/index.php...685&hl=vPPC ?
Go to the top of the page
 
nvogel
post Aug 18 2016, 03:29 AM
Post#3



Posts: 852
Joined: 26-January 14
From: London, UK


I'd say that regulations and laws are stronger now than they were back then - and enforcement gets stricter all the time. Think very carefully before relying on Access encryption and hiding passwords. If security is important to you then it's probably wiser to look elsewhere. Just my suggestion.
Go to the top of the page
 
UrsaMajor
post Aug 18 2016, 06:04 AM
Post#4



Posts: 5
Joined: 17-August 16



Hi Daniel,

Thanks for the links. I have tried to download from hitechcoach.com but it doesn't seem to work. It shows up on the listing but reports File Size: EMPTY so I guess it is not there anymore.

The link to pere de chipsticks's post works fine and I going through the download trying to figure it out. It looks like it should move me on.

Regards, Robert
Go to the top of the page
 
UrsaMajor
post Aug 18 2016, 06:13 AM
Post#5



Posts: 5
Joined: 17-August 16



Thanks for your suggestion nvogel. I thought the Access .accdb Database encryption was AES and so fairly secure. The weak link seemed to be that the password is stored in plaintext in the FE database. Is the situation worse than that?

I am not looking for very high security as the application will only be installed on an office LAN. However, not having the password available to anyone with a passing knowledge of Access seems to be desirable.

What do you think would be the next step to increasing security of data if I am committed to developing in Access, using a SQL Server database? Or would this still be compromised by using Access to connect to it?
Go to the top of the page
 
nvogel
post Aug 18 2016, 06:49 AM
Post#6



Posts: 852
Joined: 26-January 14
From: London, UK


The weak link exactly. Password hiding is "security by obscurity" and makes the encryption scheme obsolete and irrelevant. In any case role-based-security is impossible because with an encrypted database file the access is either all or nothing.

SQL Server and all other DBMSs have integrated, role-based security which doesn't rely on hidden passwords. The database should sit on a server where the users can't even access it over the file system.
Go to the top of the page
 
DanielPineault
post Aug 18 2016, 07:37 AM
Post#7


UtterAccess VIP
Posts: 5,951
Joined: 30-June 11



Access has never been truly secure. If your situation requires true security then you need to migrate your BE to something like SQL Server, Oracle, ...
Go to the top of the page
 
UrsaMajor
post Aug 21 2016, 09:29 AM
Post#8



Posts: 5
Joined: 17-August 16



I understand that Microsoft want to pitch Access and its ACCDB database at a lower level than its other database products. I expect this to mean less speed, less flexibility and less security but easier to use. I am quite happy with this. The security that Access appears to provide seems more than adequate for my purposes. Right up to the point where the password for a linked database is stored in plain text in a easily access table. It seems amazingly inconsistent.

Although there is no user level or role level access control built in to Access, I am happy to implement this using a SHA1 hash function together with AES encryption and decryption functions. Once I have validated a user I can decrypt the linked database password and connect to the linked database. This all seems reasonably secure to me. All I need to do is stop Access storing the password every time I set up a connection.
Go to the top of the page
 
gemmathehusky
post Aug 21 2016, 04:45 PM
Post#9


UtterAccess VIP
Posts: 4,434
Joined: 5-June 07
From: UK


If you are using access tables, then the password is visible in plain text in the table's connect property.
Go to the top of the page
 
theDBguy
post Aug 21 2016, 07:51 PM
Post#10


Access Wiki and Forums Moderator
Posts: 72,430
Joined: 19-June 07
From: SunnySandyEggo


Hi UrsaMajor,

Welcome to UtterAccess!
welcome2UA.gif
I am not sure you can stop Access from storing the BE password although vPPC manages to establish the connection through an intermediate database file to hide it. I think maybe the only way to avoid showing the password to the user is to not use linked tables and only use unbound forms and recordsets.

Just a thought...
Go to the top of the page
 
DanielPineault
post Aug 22 2016, 09:01 AM
Post#11


UtterAccess VIP
Posts: 5,951
Joined: 30-June 11



You can't stop Access from doing so if you are building a standard BE->FE linked table database.

  • You can build an unbound system, then again, you will still need to stored a password somewhere to establish your connection, but you could encrypt it at the very least.
  • You can switch over to use
SQL Server Express.
Go to the top of the page
 
UrsaMajor
post Oct 17 2016, 06:02 AM
Post#12



Posts: 5
Joined: 17-August 16



Thanks for the responses. I have considered the other alternatives suggested but they seem to have their own problems. Indeed it seems very easy to set up a connection to a SQL Server and still have the password stored in plain test, if not in the application then in the registry.

Going through this I have come across a number of discussions about DSN-Less connections. This seems to provide a way of making a connection to any ODBC without having the password stored. Most these discussion relate to connections to SQL Server databases but it seems that the same method could be used to connect from an Access 2013 front end to an Access 2013 backend. However, I have not been able to bottom this out and get a working connection.

Firstly, is it true that the password isn't stored when using a DNS-Less connection? Secondly, if it is true how can I a make a DNS-Less connection from one Access 2013 to another?

Any pointers would be very gratefully received!
Go to the top of the page
 
DanielPineault
post Oct 17 2016, 07:28 AM
Post#13


UtterAccess VIP
Posts: 5,951
Joined: 30-June 11



Have you seen: http://www.accessmvp.com/DJSteele/DSNLessLinks.html ?
Go to the top of the page
 
datAdrenaline
post Dec 9 2017, 09:56 PM
Post#14


UtterAccess Editor
Posts: 17,956
Joined: 4-December 03
From: Northern Virginia, USA


I know I am late to the party, but ... since I and Alan "created" (used loosely) vPPC, I thought I would join in.

First off. It is unfortunately that mega thread with Alan and I got misplaced along the way -- between transition to new software to power UA and Gords cleanup efforts, the vPPC thread got lost. I have found it on the Wayback machine ..

https://web.archive.org/web/20120801130129/...y-t1242310.html

and have meant to summarize it and repost, but ... 10 kids with an extra family living with us has pretty much consumed my time! I will try to find it again, and post.

However, after the vPPC mega-thread, Ben Clothier (BananaRepublic) summarized the process nicely here:
https://blogs.office.com/en-us/2011/04/08/p...se-connections/


The premise of vPPC (virtual password protected connection)

---

- Link to the BACK END when it is NOT password protected or don't store the pwd on ODBC tables.
- After you link, then pwd protect the BE.
- Then, in startup code, open the BE via use of the pwd IN CODE (ie: OpenDatabase, the variety of ways to open a recordset via a connection string with the pwd). Once you have opened the BE using the pwd, Access caches the pwd and all your other linked tables will work fine with out the pwd in the .Connect property.

Here is the caveat.... if you create a linked table object to the BE, when the pwd is cached, the pwd can be written to the .Connect property when you create the linked table object. Also, vPPC enhanced can help prevent that byproduct of Access's power and further obfuscate as its a redirecting technique, but, its not unbeatable. Also, You can prevent the writting of the pwd with ODBC tables by creating the MSysConf table in the source database. Documentation for the MSysConf table is scarce, but here is a quick article that does a pretty good job of it: http://sourcedaddy.com/ms-access/SQL-server-profiler.html

Just in case the link goes dead one day, here is the T-SQL from the article:
CODE
CREATE TABLE MSysConf(
Config   SMALLINT NOT     NULL,
chValue  VARCHAR(255)     NULL,
nValue   INTEGER     NULL,
Comments VARCHAR(255)     NULL
)
GO
INSERT INTO MSysConf(Config,nValue,Comments)
VALUES(101,0,'Prevent storage of the logon ID and password in linked tables.')
--VALUES(103, 50,'number of rows retrieved.')
--VALUES(101,1,'Allow storage of the logon ID and password in linked tables.')
--VALUES(102,1,'delay in seconds between each retrieval.')
--Note Setting a higher delay time decreases network traffic,
-- but increases the amount of time that read-locks are left on data
-- (if the server uses read-locks).
GO


That is all I have for the moment --- sorry it took me a few months to get here!

--------------------
Brent Spaulding | datAdrenaline | Access MVP
It's all very well to tell us to forgive our enemies; our enemies can never hurt us very much. But oh, what about forgiving our friends? - Willa Cather; As always - Pay it Forward!
Go to the top of the page
 
datAdrenaline
post Dec 9 2017, 10:09 PM
Post#15


UtterAccess Editor
Posts: 17,956
Joined: 4-December 03
From: Northern Virginia, USA


Here is another good link that describes the MSysConf table ...

https://docs.oracle.com/cd/B10501_01/win.920/a97262/ch5.htm

--------------------
Brent Spaulding | datAdrenaline | Access MVP
It's all very well to tell us to forgive our enemies; our enemies can never hurt us very much. But oh, what about forgiving our friends? - Willa Cather; As always - Pay it Forward!
Go to the top of the page
 
pere_de_chipstic...
post Feb 10 2018, 10:48 AM
Post#16


UtterAccess Editor
Posts: 10,239
Joined: 8-November 07
From: South coast, England


Just a quick addendum to Brent's post.

the process with vPPC is, as Brent states:
- Link to the BACK END when it is NOT password protected or don't store the pwd on ODBC tables.
- After you link, then pwd protect the BE.

I use a dummy Back End, with the same table structure as the 'live' BE. when linking to the BE
1. temporarily rename the live BE,
2. change the name of the dummy BE to live BE name,
3. establish the link to the (dummy) BE
4. Rename the dummy BE to its original name
5. rename the real BE to its original name

Using this the Front End can be relinked to a BE without the live data file needing to exist in an unprotected file.

Note: You should avoid using Multi Value Fields with this method unless you create the dummy file from a working (up to date) live BE.

--------------------
Warm regards
Bernie
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    21st June 2018 - 06:49 PM