Getting old forget mdb password

[FuzMic]

Brothers
This is the one that Passware tell me there is no VBA password but still ask for a password. Can you give it a go to allow me access the modules.

 

[Gasman]

I will PM you the PW.

 

[GPGeorge]

I finally concur even a VBA password should not be used. I came to this realization when VBA password was not found by Passware kit yet when I try to view a module msAccess still expect a password.

I think the more fundamental question is not whether a VBA password (or any password) should or should not be used, but when it is appropriate to password protect your work.

In the case where most of us work, most of the time, for example, I surmise that the user base is either other employees of the same organization, or the employees of a client for whom we do the work. In that environment, password protecting VBA or the mdb/accdb seems to be unnecessary most of the time. If you don't trust the people you work with, you have a serious problem across the organization.

Of course, specific circumstances may apply. For example, you may have sensitive personal information to protect in an HR database application. That is a candidate for password protection for sure. You may have critical Intellectual Property in the database that requires higher levels of security, including password protection. I once had a client that did testing for their clients, and the data regarding the tested materials and test findings about those materials was highly sensitive and restricted to a small team charged with managing that data confidentially. I won't divulge the industry or the kind of testing they did here, but protecting that information was priority one for them.

To return to the statement regarding Passware and similar password crackers. The fact that such software applications exist, and are usually effective, means that relying on password protection in Access is a fool's errand in cases such as the two mentioned above. If anyone can bypass security and read the salary information of every employee in the company, you have pseudo-protection and exposure to employee complaints, at best. If anyone can bypass security and read the raw results for any client's testing protocol, you have pseudo-protection and a potentially devastating lawsuit on your hands. Access is probably not your go-to choice in those situations.

 

[Gasman]

FWIW, DB is split, so only FE is available.
I have also seen the O/P's name in the code/forms, so I am happy they belong to him.

 

[isladogs]

I was recently asked by an experienced developer whether I could deduce the BE password in a split test database with no linked tables.
He had done everything he could think of to lock it down and made a very good job of doing so. AFAIK there were no 'back doors' to exploit
The ACCDE FE automatically opened the BE in code which of course I couldn't access.
Both FE & BE were renamed as ACCDR, shift bypass was disabled and much else besides
The password itself was also encrypted in the FE so using a hex editor wouldn't have helped

The password turned out to be 17 characters long and definitely not possible to guess: y5#BIPWd*sz6$CJQX
Using a password cracker would have taken many years / lifetimes. In other words, cracking is of no use on a long & strong password

However, using another approach (which I'm definitely not going to explain), I was able to find the password & open the BE in less than 5 minutes!
This isn't a weakness of Access itself but of ANY password protected file.

 

[Isaac]

Before I start let me say I'm not trying to be clever or get at FuzMic, but just commenting on the the vicissitudes of IT security.

I know the received knowledge advice is to never write down passwords, but you have to admit that it is virtually a necessity in this day and age (I counted mine and I have 214 passwords and 23 PINs!). And nobody will be able to look up on the internet how crack a securely stored list on paper.

The real advice to not write them down is aimed at people who do the equivalent of putting a post-it note on an office computer.

Personally my list is stored using an Access DB for CRUD, but the BE is on a removable Encrypted 256 Bit AES USB drive that is only mounted when it is needed! I do keep a printed copy of the database locked in my safe. (Especially the PW to the BE encryption!)

The one piece of advice I remember from a visit to GCHQ many years ago was that long passwords are easier to remember that short ones.
For example 'I keep my passwords in a 14 inch bucket' is somewhat easier to remember than 1KmF-Zy23

I tend to agree with you Dicky. The idea of never writing down passwords as a rule is ridiculous, given the fact that exact zero bad actors/hackers will ever be in my home, but 10's of 1000's of them are out there on the internet trying to figure out a way to crach my password manager or my computer....etc. etc. In this day and age you may have to use the old pen and paper and it may not be the worst idea, either.

It's different of course in a corporate cubicle environment; there, the rule holds a bit more true.

 

[The_Doc_Man]

The U.S. Navy's solution was sometimes the "protected enclave" approach, other times letting Access be the FE to a far more secure (and securable) BE.

In the protected enclave approach, the Access DBs were behind isolating firewalls because they were on the "in-house" network and if you had access, it was through your actual user ID or your membership in a group. The domain was pretty well locked down, well enough that we could trust it - in the specific sense that Trust Center does trusts. Therefore, you would log in to the domain and I would look you up based on your verified domain ID. That in-house domain had no direct exposure to the Internet, was a Gigabit LAN, and had automated backup setup for every server based on times the server admins would determine as optimum. Therefore, if we had issues, they were with people in a known sub-domain of the Navy's NMCI network. We didn't have a database password because we trusted the domain's security. The domain DID have a password and it was enforced regarding size and complexity. Plus it required a smart-card to access it.

The Access/external-engine approach has been discussed many times here by many people so I won't bother going into that in detail. But it was secure enough that the U.S. Navy supported it and allowed it for PII data sets for a scholarship program for Navy physicians. But the app wasn't password protected. The DB behind it WAS protected by a smart-card+password combination, so pretty tight there.

 

[FuzMic]

gasman
another mbd to open vba, please

Even i think i write down the vba password, msaccess can foul it up so this is another one of those to crack

 

[gemma-the-husky]

Note the test

• Recovers either the first 3 letters of passwords or passwords containing no more than 3 characters
  Perhaps that is enough to remind you what it was?

Actually three characters was enough to remind me of the password I had used a long while ago. It was after that experience I stopped using passwords.

 

[Gasman]

Actually three characters was enough to remind me of the password I had used a long while ago. It was after that experience I stopped using passwords.

Well I posted a pic of the trial of that program and it did not show even the first 3 characters.
See post #39

 

[FuzMic]

Gasman
This time your passware changed R14a1PAY.mbd i downloaded cannot be opened with your usual PM password. ??? Did i get it wrong. Thank you for your help all the way.

 

[Gasman]

I did not touch R14aPay, that must have been @arnelgp ?

 

[arnelgp]

the password is FuzMic

 

[Gasman]

gasman
another mbd to open vba, please

Even i think i write down the vba password, msaccess can foul it up so this is another one of those to crack

Same password.

 

[FuzMic]

Gasman & arnelgp
Now can open with usual password ... thanks