Disable Shift Key Bypass (2 Viewers)

The context being talked about is what you are protecting and from who and how.

given the amount of successful hacking around the world the best you can do is make it as difficult as possible.

For example:

The what - all data? Specific data? The design?

The who - a world class hacker? An experienced access developer who has access to your app? An unknowledgeable user? Something in between?

The how - copying to a thumb drive? Copy paste from screen forms? Gaining access to the nav pane?

Some security can be done outside the app - such as limiting access to the app folder

Some inside - for example don’t have linked tables which in turn means no queries in the front end. Build them as required in vba and assign to the form recordset - and of course only provide a .accde so the code is compiled.

You may also want to encrypt/decrypt the sql string so it is not visible to those who know how to view the compiled code - and don’t forget to encrypt the key as well using a different method

That is still hackable to a very experienced access developer

You really aught to put a risk assessment document together to determine the what, who and how so you can then make a rational decision as to what to do about it.

A client a few years ago discovered that sales people were copying the list of customers, contacts etc to take with them to a competitor (this was not an access app). The supplier of that app couldn’t do much without a major rewrite as it was a web app. The best they could do was limit the list to 5 records per page
 
The context being talked about is what you are protecting and from who and how.

given the amount of successful hacking around the world the best you can do is make it as difficult as possible.

For example:

The what - all data? Specific data? The design?

The who - a world class hacker? An experienced access developer who has access to your app? An unknowledgeable user? Something in between?

The how - copying to a thumb drive? Copy paste from screen forms? Gaining access to the nav pane?

Some security can be done outside the app - such as limiting access to the app folder

Some inside - for example don’t have linked tables which in turn means no queries in the front end. Build them as required in vba and assign to the form recordset - and of course only provide a .accde so the code is compiled.

You may also want to encrypt/decrypt the sql string so it is not visible to those who know how to view the compiled code - and don’t forget to encrypt the key as well using a different method

That is still hackable to a very experienced access developer

You really aught to put a risk assessment document together to determine the what, who and how so you can then make a rational decision as to what to do about it.

A client a few years ago discovered that sales people were copying the list of customers, contacts etc to take with them to a competitor (this was not an access app). The supplier of that app couldn’t do much without a major rewrite as it was a web app. The best they could do was limit the list to 5 records per page
The What: User Passwords
The Who: Anyone
The How: Looking at them in a table

I'm just trying to encrypt the passwords so that they don't appear in plain text.
 
In what context would it be acceptable for anyone to see users' passwords?
I'm sorry. I am afraid you're missing the point, apparently.

To help you understand, let's take an analogy of two warehouses, each constructed of concrete walls, two feet thick. Ceiling and floor also thick concrete.

One warehouse has a single entrance. It's a door made of 3 inch steel plate.

One warehouse has an identical door. However, it has windows on both sides and the back. The windows are covered with light metal screens. There is also a rear door, made of steel.

Now, the front entrance of both buildings is locked with electronic locks. You need to enter a password to unlock the door. That password is very strong for both doors.

However, the second building has many other locked points of entry. Some, i.e. the windows covered by light metal screens, can be easily defeated with a pair of wire cutters. The rear door is also locked with a padlock that can be defeated with a pair of bolt cutters.

Both have strong, password protected entrance doors.

Which would you choose to store your collection of Rembrandt paintings? Which one would you consider adequate for temporary storage of used furniture?

The point is that regardless of the strength of the passwords, that is NOT the only weakness in the second building.

That's like Access. You can create the strongest passwords possible. There remain other security weaknesses that make those passwords less than effective in protecting your data.

You can invest hours in creating those passwords, and I'm happy that you're getting help to do so. It's worth the effort, no doubt.

Just don't forget that a knowledgeable user is not going to attack your data through the passwords.

That's the context of my questions.

Who are you trying to keep out? Art thieves or used furniture dealers?
 
The How: Looking at them in a table
I presume you are talking about user passwords to your app, not to windows and not the the BE db


I'm just trying to encrypt the passwords so that they don't appear in plain text.
So what is wrong with encrypting the password table, or better, storing the encrypted password - when a user enters their 'plaintext' password, it is encrypted and then compared with the encrypted value in the table. No use to anyone who cannot reverse engineer it.

You just need to protect against a hacker getting to know what the encryption key and type is so they can reverse engineer it

And I presume you have already protected against sql injection?
 
I presume you are talking about user passwords to your app, not to windows and not the the BE db



So what is wrong with encrypting the password table, or better, storing the encrypted password - when a user enters their 'plaintext' password, it is encrypted and then compared with the encrypted value in the table. No use to anyone who cannot reverse engineer it.

You just need to protect against a hacker getting to know what the encryption key and type is so they can reverse engineer it

And I presume you have already protected against sql injection?
Your assumption is correct. That is exactly what I'm trying to do. I just want to encrypt the password table. I've been looking for a way to accomplish that. Many people in this post have directed me to helpful examples but unfortunately none of them, so far, seem to work. I have the .NET framework that is supposed to be necessary according to some developers but still no luck. Even a relatively straightforward function as the one below gives me an "Object Required" error on the hi-lighted line. Theoretically, I would think this would be a reasonably simple thing to do. I would have also hoped that this functionality would be inherent in Access. If you have any suggestions I would greatly appreciate hearing them.

Code:
Function dbgSHA256(PlainText As String) As String

Dim encoder As Object
Dim hasher As Object
Dim textToHash() As Byte
Dim hash() As Byte
Dim cypher() As String
Dim x As Long

' Create objects for encoding and hashing
Set encoder = CreateObject(“System.Text.UTF8Encoding”)
Set hasher = CreateObject(“System.Security.Cryptography.SHA256Managed”)

' Convert the input string to bytes
textToHash = encoder.GetBytes_4(PlainText)

' Compute the hash
hash = hasher.ComputeHash_2(textToHash)

' Convert the hash to a hexadecimal string
ReDim cypher(UBound(hash))
For x = 0 To UBound(hash)
    cypher(x) = Hex$(hash(x))
Next

' Return the result
dbgSHA256 = Join(cypher, “”)

' Clean up objects
Set hasher = Nothing
Set encoder = Nothing

End Function
 
@GPGeorge - I appreciate the time you've taken on this. We're not communicating effectively and it certainly may be my fault.
I'm not trying to protect anything in my application. That would be a completely different conversation. My problem is far simpler than your analogy suggests. I simply want to encrypt passwords in the login table of my MS Access application. It's interesting and a bit confusing why someone would ask why - or request that I explain the context.
 
So did you look at the Password Login example app that I mentioned in post #21?
That uses RC4 encryption and it definitely works. In fact I used something very similar for many years in my commercial apps for schools.
The approach could easily be adapted for other encryption methods.
 
@isladogs - I created myself as a new user but the login button is disabled so after I create my password I'm stuck. What am I doing wrong?
 
Impossible for me to tell. The app has been in use for well over a decade.
Did you unblock the app before use? Did you save to a trusted location or make it a trusted document?
Are there any broken references? What version/bitness of Access are you using?
 
I unblocked the app. I saved to a trusted location. I'm not getting any error messages so I don't think there are any broken references.
The version info is below:
1745613350905.png
 
I simply want to encrypt passwords in the login table of my MS Access application
You never want to store the actual passwords of your users if those passwords are only used for login.

Store a salted hash of the password only.

Then, when your user logs in, you hash the inputted password and compare that with the stored hash to see if they are allowed access.

This way, when someone hacks into your users table they can not discover the users' passwords - only a hash which is useless to them since they will be unable to know the corresponding password.
 
So did you look at the Password Login example app that I mentioned in post #21?
That uses RC4 encryption and it definitely works.
@Colin , why do you use a symmetric algorithm for protecting passwords, and also one that is no longer recommended due to its inherent weaknesses?
 
@Colin , why do you use a symmetric algorithm for protecting passwords, and also one that is no longer recommended due to its inherent weaknesses?

The example app was written around 10 years ago as a simple replacement for an old MDB example app by David Crake that just used XOR to (weakly) scramble passwords. My version works but wasn't intended as a high security app.

RC4 is indeed symmetric and therefore shouldn't be used (or at least used on its own) where strong security is required. I don't rely any single security measure on its own in my commercial apps. In general, I recommend using active directory and not store user passwords at all.
 
@isladogs - I tried it this morning with fresh eyes and it works perfectly. Thank you very much for this! I really appreciate your help. Exactly what I wanted to do.
 
You’re welcome but do take into account my previous comments about using additional security measures as appropriate to your needs.
 
Even a relatively straightforward function as the one below gives me an "Object Required" error on the hi-lighted line.
Did you copy the code in to Word before pasting in to your VBA project?

The code you showed here has 'smart quotes' instead of normal double quotes which will cause the error.
Code:
' ...
' Create objects for encoding and hashing
Set encoder = CreateObject(“System.Text.UTF8Encoding”)
'                          ^                        ^
Set hasher = CreateObject(“System.Security.Cryptography.SHA256Managed”)
'                         ^                                          ^
' ...

You need:
Code:
' ...
' Create objects for encoding and hashing
Set encoder = CreateObject("System.Text.UTF8Encoding")
Set hasher = CreateObject("System.Security.Cryptography.SHA256Managed")
' ...

It's hard to spot, but there is a difference between:
Code:
“ ... ”
" ... "
 
Also, this line will need changing too:
Code:
' ...
' Return the result
dbgSHA256 = Join(cypher, “”)
' ...
 

Users who are viewing this thread

Back
Top Bottom