Solved Password Table

Hecronis

Registered User.
Local time
Today, 10:03
Joined
Apr 26, 2016
Messages
60
I have a database where I created a log in form for the users where they select their name and enter a case sensitive password. We have just figured out that when we record a new password on the password table it is automatically capitalizing the first letter of the password. I don't want it to do this. Any ideas on how to fix this? I have tried editing a password though a linked form, using and update query, and going directly to the table itself but I still get the same result. It only just started doing this. I'm assuming it has to do with the table since I even entered a new password on there and it did the same thing, but I'm not sure to be quite honest. all of the passwords that were created initially were all lower case it's only the ones that have been changed.
 
Is this happening on all text fields or just the password one?
 
Is this happening on all text fields or just the password one?
Just the the ones in the password table. I just recently activated the case sensitive part of the log in but I wouldn't think that would affect the way the password is stored.
 
Just the the ones in the password table. I just recently activated the case sensitive part of the log in but I wouldn't think that would affect the way the password is stored.
So, if other tables are not affected, it means it's not a system setting. Sounds like it could be your code. However, you did say you tried to manually update the table directly and got the same problem, right? I tried it on a test table, and it didn't capitalize the first letter I entered in the field.
 
So, if other tables are not affected, it means it's not a system setting. Sounds like it could be your code. However, you did say you tried to manually update the table directly and got the same problem, right? I tried it on a test table, and it didn't capitalize the first letter I entered in the field.
I have an input mask on the passwords in the table to be hipaa compliant so I have been using this code to check cases on the Login Screen.

Code:
StrComp(Me.Password, DLookup("Password", "Tbl_Private", "ID_Navigator =" & Me.Navigator), 0)

This is my first time trying something like this or using the code. There is definitely a chance of me not using this code correctly.
 
Rather than the mask you are using, use the default Password mask. Your mask is probably causing the problem.

Just FYI, Access is natively agnostic regarding upper/lower case. A=a as far as Access is concerned and it takes a lot of effort to change that. That is not true for other RDBMS' though so you should probably fix the problem.
 
As well as the advice you have received, it isn't sufficient to 'mask' the password to comply with data protection requirements
In the UK we have GDPR rather than HIPAA but I'm fairly sure both are similarly stringent.
It would probably take no more than a couple of seconds for any competent Access developer to view the underlying passwords for all your users.

If you really MUST store passwords in your database, make sure they are strongly encrypted using 128-bit encryption and also hashed.
Better still don't store password data. Instead use Active Directory to do the hard work for you
 
Last edited:
In the UK we have GDPR rather than HIPAA but I'm fairly sure both are similarly stringent.
HIPAA compliance is a different kind of beast than GDPR. HIPAA is about sensitive health related data.

@Hecronis, I suggest you discuss the level of protection required for the data with the responsible people and then reevaluate if an Access database is the right tool for keeping this data.
 
Hi Philipp
Good point re HIPAA but my comments about security are still just as relevant
 
@Hecronis - I'm going to second the suggestion to check with your login requirements. Two ideas have been suggested here.

1. Use the domain-level login to identify your user thus "trusting" your domain. Since you don't store a password on your system at all with this approach, there is no password to steal.

2. Store a hashed version of the passwords and then, when validating logins, compare the hash of the currently entered password to the stored hash of the correct password. Since you don't have a cleartext password to steal, and since hashes aren't easily (or at all) reversible, hackers won't be able to get past your login so easily.

For what it's worth, the U.S. Navy approved both of these methods for different systems at the Navy Enterprise Data Center New Orleans (from which I retired some years ago). And you can image how security-conscious the U.S. Navy has to be.
 
Personally. I tend to not bother about passwords being case sensitive for access purposes, but I don't store plain text passwords. You can do something simple like xor each character with each character of a standard encryption string. It would be quite tricky for a user to work out the plain text from the encrypted value, especially if it's quite hard even for them to see the encrypted text.

Clearly there are other methods - eg The example just posted by @The_Doc_Man . If it's good enough for the US Navy ....
 
I think I accidentally figured out what was going on. I changed
Code:
If StrComp(Me.Password, DLookup("Password", "Tbl_Private", "ID_Navigator =" & Me.Navigator), 0) Then
to
Code:
If StrComp(Me.Password, DLookup("Password", "Tbl_Private", "ID_Navigator =" & Me.Navigator), 0) = 0 Then
and now it seems to work properly, but I am interested in the different ways to secure this.

As I mentioned before I am new to this kind of security. None of the other databases I've made have had multiple users/front ends much less requiring that each have a log in. What do you mean by domain-level security? Are you referring to their computer log in? If so this DB is stored on a secure network through the organization that only these individuals and myself have access to and only on our VPN.
 

Users who are viewing this thread

Back
Top Bottom