Disable Shift Key Bypass (1 Viewer)

[isladogs]

Several years ago, I submitted a number of suggestions to the Access team which would improve the security of Access databases - in particular to make ACCDE files more secure. The first of those items was to mask the BE password. See my article

Additional Security in Access Databases

This is a list of suggested changes that could help make Access databases much more secure

www.isladogs.co.uk

Coming back to user login passwords, the best approach is to make use of the robust security in Active Directory where that is available.
Doing so means no passwords need to be stored in the app itself.
Where that isn't possible, you may find it worth looking at the RC4 encryption approach I use in my example app:

Password Login

This utility has been provided to manage user passwords and also keep a user session log

www.isladogs.co.uk

 

[GPGeorge]

Thanks @theDBguy - I, like any other developer, want to protect, at least, passwords.
Access offers an input mask which masks the passwords so that they can't be read. Great.
Access allows you to remove the input mask and thereby view everyone's passwords in plain text. Not great.
Access allows you to password protect your backend databases so that no one can view the data without having the password. Great.
Access displays that password in plain text when you link the front end to the protected backend. Unbelievably dumb.
I have successfully used SHA encrypted passwords in my SQL Server databases but they are very cumbersome and complicated to administer. I would prefer not to use them. I hope to find a reasonable alternative other than writing my own encryption program. But so far this is looking like the only alternative.
I do appreciate everyone's input however,

PMFJI at a late point, but there's a key factor that you need to revisit, as theDBGuy said.

While you can do a great deal to secure an accdb, you can't get to 100% security with Access. Colin is widely recognized as an authority on Access security and has written articles that can help you get to a very good level of security. If you need more than that, then, yes, you need to consider two things:

1. How secure is secure enough for this particular database application? What are you really trying to prevent? Who are you protecting it from? Why are you worried about those people? What have your users done in the past to elicit this level of response? Are you worried about some degree of external penetration? Or is it purely the users in your organization who worry you?
2. Depending on the answers to the questions in point 1, you may or may not have to reconsider whether Access meets your security needs.

I once completed a project for a testing lab which had to certify that their test results were secure in order to pass an audit. We moved to SQL Server precisely for that reason. Not that the client was worried about co-workers, but that the client had to satisfy the certification process that the data was secure. It was painful and expensive to do, but the requirement was there.

This discussion is not about Access per se. It's about the realistic level of security you require for this database application. Saying that Access is "unbelievably dumb" is like saying a two door sports car is "unbelievably dumb" because you can't take a group of 7 people to the movies in it.

It's not built for the purpose you have in mind.

If Access cannot be made secure enough through the standard methods available, then your choices include moving to a more secure platform or implementing other security measures, which can indeed be cumbersome and complicated to administer. Still, if that's what you require, that's what you do to achieve it.

 

[TheSearcher]

How secure is secure enough for this particular database application?

In every database application the passwords should be secure. We live in an age of online banking and social media. Some people use the same password for multiple applications. Rather than go on a mission to educate the public I would prefer to secure the passwords in my applications. I will read and study Colin's suggestions. I'm sure I will benefit from them.

 

[theDBguy]

In every database application the passwords should be secure. We live in an age of online banking and social media. Some people use the same password for multiple applications. Rather than go on a mission to educate the public I would prefer to secure the passwords in my applications. I will read and study Colin's suggestions. I'm sure I will benefit from them.

If you're talking about user passwords, that's easy to secure. I would recommend using a hash instead of encryption to make sure it cannot be decrypted.

 

[TheSearcher]

@theDBguy - Can you please elaborate on that? What do you mean by "using a hash"? Is that available internally within Access? Can you point me in the right direction? I appreciate your help!

 

[theDBguy]

@theDBguy - Can you please elaborate on that? What do you mean by "using a hash"? Is that available internally within Access? Can you point me in the right direction? I appreciate your help!

Take a look here...

SHA256 Hashing Function

I know this is not a new topic, but I just thought I would post it here for my own future reference. I have used other SHA256 hashing funct...

thedbguy.blogspot.com

Sent from phone...

 

[TheSearcher]

Absolutely fantastic!! I can't wait to try it out! Thank you so much!!

 

[theDBguy]

Absolutely fantastic!! I can't wait to try it out! Thank you so much!!

Good luck!

 

[TheSearcher]

Almost there. Looks like I may need a specific reference but I don't see any .net references in the References section. Any ideas?

Object Required:
Set encoder = CreateObject(“System.Text.UTF8Encoding”)

 

[theDBguy]

Almost there. Looks like I may need a specific reference but I don't see any .net references in the References section. Any ideas?

Object Required:
Set encoder = CreateObject(“System.Text.UTF8Encoding”)

Not in front of a computer now, but my guess is that you may not have the .Net Framework installed or maybe it's a different version. You shouldn't need to add any references at all.

Sent from phone...

 

[TheSearcher]

see attached document I found on an AI website

 

[theDBguy]

see attached document I found on an AI website

Sorry, can't download the attachment right now, I'll try it later.

Sent from phone...

 

[GPGeorge]

In every database application the passwords should be secure. We live in an age of online banking and social media. Some people use the same password for multiple applications. Rather than go on a mission to educate the public I would prefer to secure the passwords in my applications. I will read and study Colin's suggestions. I'm sure I will benefit from them.

Against whom should it be secured? Who, exactly, are you worried about? Your users? External actors? Others in your organization?

Again, the point is that a blanket assertion does not make sense because the context determines the relative degree of security required.

If your database application is exposed to the general public, it needs to be more secure than if it's exposed to a dozen of your colleagues, unless they are all unrepentant reprobates.

 

[isladogs]

I would also recommend hashing password strings and the function provided by @the DBGuy is amazingly simple to use.

FWIW, the dbgSHA256 function runs successfully for me with just the standard 4 references added in any new database in A365
I have .NET Framwork 4.81 in case that is relevant

 

[TheSearcher]

degree of security required

@GPGeorge: The "degree of security required" is always the same when it comes to passwords. It can only differ when it concerns other data.
@isladogs - I'm not sure what .NET framework I'm working with. I'm trying to find that out now. But DBGuy's function gives me an Object Required error message at the "Set encoder = CreateObject(“System.Text.UTF8Encoding”)" line of code. Check out my pdf attachment in post #31. I question its accuracy since it seems to work for some people - but it makes some valid points.

 

[isladogs]

Yes I read that PDF. As already stated, I didn’t have any problems using that code.

I sometimes use a combination of encryption and hashing. I also encode the cipher used with a different function for additional security

 

[TheSearcher]

I verified that I do have the .NET Framework 3.5 control and the two Windows Communication Foundation sub controls selected and installed. According to the articles I've read this was supposed to solve my problem. No luck though. Thank you everyone for your input. I really appreciate it. If I solve my problem I will post the solution here.

 

[theDBguy]

I verified that I do have the .NET Framework 3.5 control and the two Windows Communication Foundation sub controls selected and installed. According to the articles I've read this was supposed to solve my problem. No luck though. Thank you everyone for your input. I really appreciate it. If I solve my problem I will post the solution here.

See if you have better luck with this one.

VBA – Get a String’s Hash | DEVelopers HUT

Just demonstrating how you can use plain VBA to get the MACTripleDES, MD5, RIPEMD160, SHA1, SHA256, SHA384 or SHA512 hash of any string.

www.devhut.net

Sent from phone...

 

[GPGeorge]

@GPGeorge: The "degree of security required" is always the same when it comes to passwords. It can only differ when it concerns other data.
@isladogs - I'm not sure what .NET framework I'm working with. I'm trying to find that out now. But DBGuy's function gives me an Object Required error message at the "Set encoder = CreateObject(“System.Text.UTF8Encoding”)" line of code. Check out my pdf attachment in post #31. I question its accuracy since it seems to work for some people - but it makes some valid points.

I guess the word "context" means nothing to you.

 

[TheSearcher]

I guess the word "context" means nothing to you.

In what context would it be acceptable for anyone to see users' passwords?