Time to update David's "PasswordLogin.mdb" ?

MarcusGR

New member
Local time
Today, 21:48
Joined
Nov 1, 2018
Messages
8
I need to provide a DB of mine with user-level passwords complete with expiry-dates, and a log of past and current users. I found several example-dbs in the net, but nothing compares to David Crake's beautiful "Passwordlogin.mdb" (whose link on access programmers, 193131 I am not allowed to post here). It is just PERFECT. But using it through Access 2010 (and Windows 10) some of its functions seem not to work as designed (PW management, for instance).
I suspect this has to do with OS and/or mdb/accdb issues ..? APIs-related , perhaphs ? In any case, a lot more than I can chew.
Is there anybody around who could do that ? It is such a pity - besides - that, due to ... environmental changes - such a gift (and inheritance) from David should no longer perform as I presume it did just a few years ago.
 
Last edited:
I've just had a look at this in 32-bit Access 2010 and it works fine.
There are a couple of API declarations that need updating for use in 64-bit Access and a couple of references to update but it shouldn't take long to do.

What version of Access are you using and is it 64-bit?

Whilst I can see it works well, what is special about that compared to the myriad of other similar utilities?

For the benefit of others the link is https://www.access-programmers.co.uk/forums/showthread.php?t=193131

For info, I updated another similar utility by David Crake last year.
You can find it at https://www.access-programmers.co.uk/forums/showthread.php?t=295174. Does that cover your needs?
 
Whilst waiting for your reply, I thought i'd update this anyway.
See https://www.access-programmers.co.uk/forums/showthread.php?p=1598686#post1598686

I've converted it to ACCDB & modified the code so it will now work in both 32-bit & 64-bit Access

Please note the comments in that post about the very weak password encoding which I personally don't feel is strong enough for purpose
 
THANK YOU very much indeed, Isla. I haven't tried your updated file yet, but I'm sure it will work fine. And if it appeared to me not to do so, this time I will have no doubt the problem doesn't stand in the software, being rather sited ... between my ears :-) ). Anyway, I will report back after using your updated file through Access 2010 (both 32bit and 64 bit versions). Regarding the "myriad examples" available around, all those I had found (except David's) were very basic, offering just some of the functions provided by the file you just updated. So I'm sure your job will be quite useful to many. Thank you again !!
 
Last edited:
You're more than welcome.
As I wrote in the other thread, I didn't check the password expiry code so if you use that let me know whether it works or not.

Although i agree that its a very good utility, I wasn't happy with relying on the use of the XOR function for encoding the password.
In my view passwords shouldn't be stored in your databases, but if it must be done, strong encryption should be used. I may do a modified version using RC4 encryption in the next few days.
 
I will be using that soon as I get to my security systems upgrade thank you


A question if you don't mind does the user name check for Case as about to update that, at present the user can enter any case they like which i need to correct.


hope it's not a sily question but only had a chance for a quick look due to work.
 
A question if you don't mind does the user name check for Case as about to update that, at present the user can enter any case they like which i need to correct.

At the moment the user name is a combo box but that could obviously be changed to a textbox if preferred
By default, Access doesn't distinguish between upper/lower case and you would need to add additional code to make it do so

Also, as written, the RC4 code doesn't check the case (although the XOR code does). Arguably it could be said that the RC4 encryption is strong enough for that not to be a concern in this context???

Anyway, I like to leave a little something for others to work on .... :)
 
I am thinking of starting with the chr() and looping through the username checking each letter i have a function for that I use for file work.


I'll post back is i sort it thanks


P.S.I have seen a database with this think it was an access 97 one
 
Last edited:
I wouldn't recommend doing it one character at a time if you can avoid it but that could be tricky
This is the method I use to check if a string is all upper case
Code:
If StrComp(UCase(strText), strText, vbBinaryCompare)=0 Then

Counter intuitively if the values of strText & UCase(strText) are identical the output is zero
 
Hi, Isla.
I'm afraid I (as most non-prefessional Access users) would need some more help here ...
In David's orginal version, I could add new users working all right. Problem was I couldn't manage to make their PWs expire at some time.
In your versions (both, and using both 32b and 64b MsAccess 2010) I cannot even manage to add a working user (they behave differently, but my end-result was the same: no way to add a new user working).
Of course I gave a good look at the VBA code - for as much I can understand of it. But that was not sufficient to improve the situation ....
P.S.: don't be afraid to compromise security by divulging a little more about this: we average users get awful head-aches far before we might get any dangerous ... :-)
 
Last edited:
Hi Marcus
Sorry that was an unintended consequence of another change I made.:eek:
I wasn't trying to add security in that sense :rolleyes:

I'm busy for the next few hours but will fix both versions later today.

However, for security, just like David's original version, new users will NOT be able to add themselves to the list via the login form combo.
It will need to be done by admins from the table(s) ... but I think those can be merged into one table.

Will post later once update(s) are done
 
Hi, Isla. Thanks !
I'm comforted to read I was not that dumb, after all.
Regarding adding new users, that is clear: in David's version, too, one had to add a new user both in the Users table and in the Permission one. And then, of course, make sure to distribute an .accde where tables were not accessible. But that's easy enough for non-professionals too. Dealing with REAL security issues, instead, is on a totally different level ... Waiting for your intervention, then. No hurry: provided it works: please, don't forget that if you just get one dot wrong in the VBA, we miserable "amateurs" will never be able to settle it by ourselves ....
 
LOL ;)
I think I was the dumb one in preventing new users being added!

I've almost finished updating the RC4 version
I've made lots of changes to simplify the code
e.g. tblPermissions & tblUsers merged into one table / replaced all recordset code with SQL statements etc

I will test the password expiry part as well before uploading - hopefully later today

I'll also update the original XOR version as well
 
I have done a significant rewrite of the utility to sort out various issues including
- adding new users
- password expiry dates
- checking for users logged in on another computer

The updated version (Rc4 encryption) is now available at https://www.access-programmers.co.uk/forums/showpost.php?p=1598987&postcount=4

I believe I've checked all possible permutations of code but would be grateful if others would check it thoroughly

Let me know whether it works correctly or if there are any further issues

I haven't updated the XOR version. The code is still present but disabled if anyone wants to revert to that
 
...
.... "Let me know whether it works correctly or if there are any further issues"

YES, Isla THANK YOU ! It DOES work great !
And it is exactly what I needed.
Just one tiny detail: some users might remain puzzled by the Login
button staying "dead" even after entering one's username and password.
Of course, it will turn "live" as soon as they press "enter",
but in most applications login appears live all the time,
though it will only work after entering one's login data.
To make sure some users won't remain bewildered (or, worse, start fiddling
with their password) I will make sure that the caption opening the Login form
instructs them on this point too..
Thank you again: I think you produced a fantastic tool !
 
Hi Marcus
Glad you like it

I've used my own login forms for over 15 years and all require the user to click enter before the login appears.
This is because the code used to check the password need to run in the after update event rather than the on change event,
Nobody has ever said it was an issue.

However you could do one of the following:
a) Change the scrolling text caption to:
..........Please enter your user name and password below then press ENTER
Use spaces at the start (instead of ....). These are important to separate each scrolling iteration

b) Just replace the scrolling text with static text but no leading spaces

To disable the scrolling, set the timer interval to 0.
To remove it completely also remove the Form_Timer event code

HTH
 
Fantastic support from you, Isla.
I have now translated into Italian the Login form and the VBA sentences relevant for the end-user (msg boxes pertaining to the login form). A very simple task, nonethelss if you like to have it ready-available, I will email it to you.
Kind Regards, Marco
 
Last edited:
Hi Marcus
Thanks for doing 'The Italian Job' on the app...
It wouldn't be easy for me to translate other than letting Google mangle it.
So yes please to your offer.
 

Users who are viewing this thread

Back
Top Bottom