So what happens with your hash function if someone replaces the executable with one that emails them the password, and possibly chains to your original executable, then returns the expected result? I don't think this is as secure as it is represented to be. Please correct me if I'm missing something.
That is a great question. Your example requires that someone other than the user has access to the computer and user's session and can install and run exe or scripts how they please. If that is the case, the computer is already compromised and you have far BIGGER problems. They could install a keylogger to capture passwords for any program they like! You can mitigate this with a password manager but for all intents and purposes that computer needs to be wiped. I have mentioned a few times between this video and the preceding video ua-cam.com/video/k0yYVgTH-JA/v-deo.html that these utilities add security for the case when the Access data file is stolen, or, depending on how you deploy the keys, accessed (see many deployment examples at the end of one of the two videos). The encrypted data or passwords cannot or have an extremely low probability of being retrieved. If your context is serious enough that you are wondering if these steps will be sufficient to secure your MS Access data, then your solution is ready to "level up" and use MS Access' preferred backend database that handles security in a more robust way. It is SQL Server, in the form of SQL Express (free, local computer), Azure SQL (pay, local), or SQL Server (pay, local). The steps for users are the generally the same for each as you can see here: ua-cam.com/video/6xotpT7Vhso/v-deo.html The most secure solution for Access will use some flavor of SQL Server (or other enterprise db) as a backend, with your Access app running on the front-end. Access is designed to interop with SQL Server in amazing ways. You won't use MS Access as a database backend for situations that have a high security requirement, unless it is in tightly controlled single-user databases or something like that. Access is awesome but it just doesn't have that kind of mustard.
You can drop the files in the same folder as your MS Access front-end for each user. Starting at about the 25 minute mark in the previous video ua-cam.com/video/k0yYVgTH-JA/v-deo.html , you can see different deployment types. REMEMBER to delete the EncryptConnectStrings file after you run it to encrypt that section of their config. For your situation, you'll probably manage the application secret/passphrase to be the same for all. See the options - if you have questions, just ask!
@@seanmackenziedataengineering Thank you! I have already made a script that copies all files from a network drive folder to the user's computer when they open the database. I figure I can just drop them on there
🎓🎓🎓🎓 Very useful one Just inquisitive > password entered is case sensitive? Deleting password = reset password? How to protect config file? You do it like very simple but there are lots to digest I like to validate login username is in the table else close app 👍 u r the MAN
Thanks! Yes, passwords are case sensitive. The string is encrypted with 3DES, maintaining case, then hashed using SHA256. You can store the hashed value in your table as demonstrated. I show how the config file is automagically protected using some nice windows features at 10:25 where I use another little utility in the zip called EncryptConnectStrings. *Make sure to delete the EncryptConnectStrings exe file after you protect the config file each time!!* Store it somewhere else where only administrators can go. You can decrypt the config file using the same utility, if you need to make changes. In this video at about the 25 minute mark ua-cam.com/video/k0yYVgTH-JA/v-deo.html you can see different deployment options. You're absolutely right, there are many IF cases in deployment so make sure to ask questions. Do you think it is worth a video, just for deployment? Or a video for each deployment type :-p
Great , thank you so much but there are 2 problem i detected 1)If you click on the encrypt button it will encrypt the password but if you click it 3 to 4 times then it will repeat itself the password will be encrypted again and again and now you have lost your password. So I think there should text added in the encrypted like "ABCD" if the ABCD is found that means it is encrypted so no need to encrypt it again and on the other hand if i click decrypt then if ABCD is already in the text that means it need to be decrypted and if a ABCD is not present then no need to decrypt again. there is "=" in every encrypted text but this is common , so "ABCD" should be unique. 2) and another problem is if there is an error when the error occur the "error" text word is written on the field record because of this original data is deleted and thats problem the solution like error show using message box. instead of writing on record i am trying to make form on opening it decrypt the multiple filed so data on backend is encrypted and when I opened the form the data will be decrypted and on close event it will encrypted again. so my data will be safe . (please if possible try this form decrypt and encrypt on close experiment by your self ) please find solution of this both problem. thank you again. so much
This is a great point; the purpose of this video is only to take you so far as "the password is hashed", or "the password attempt was Pass or Fail". 1. It will be up to you guys to integrate the coding into your logins because these will be different for almost everyone (and could be a whole video in itself). So, you will need to add some VBA to prevent hashing multiple times, perhaps add your own password complexity requirements, and other things. I think your idea is a good one, to use a tag to denote a hashed value! Some of you might use a y/n field or something like that as well. 2. You can also capture the error in your code. For example you could say if the return value is "Error" then don't write, otherwise write over the value. As I mentioned, each of you have different applications and will use these differently. Great point - I think people need to be aware of this. For your "on open decrypt then on close encrypt" scenario, you could accomplish this by using an "Unbound forms" style of development. When the form opens, it is blank until the user enters or maybe uses a field selector to get a full record from the database. Say, a drop-down menu selects an employee from a list of Employee ID numbers. After you select, your procedure will select from the employee table where id = 123. 1 record with 10 encrypted fields in it. This loads into a recordset, then loads 10 fields on the form, but as it puts the value in each one, it decrypts it first. After loading all fields, the recordset is closed and the backend data is still encrypted while the user works on it in the form, then they click Save. Another procedure opens the recordset again for employee 123 and then encrypts, then updates each field value.
hi sir! how are you? sir please make a video on how to not allow duplicate dates for the same id, I have created an attendance system if I will add duplicate date for the same id it will create issues for me, and thanks for your instructions, soon I am going to upload a demo video of my whole Employee management system which I create by following you and 1,2 other instructors I will definitely mention their names.
Hey, that's pretty cool that you made a system! Interesting project. To address the problem you're having, you can create one index on ID and Date fields, and set the index to Allow Duplicates = No. This will give an error if someone tries to enter the same date on the same ID ua-cam.com/video/A8-9erFqfkI/v-deo.html
exactly what i was searching for... Thank You👍😊
Glad I could help! Cheers
Excellent video Sean, thank you!
Glad you liked it!
So what happens with your hash function if someone replaces the executable with one that emails them the password, and possibly chains to your original executable, then returns the expected result? I don't think this is as secure as it is represented to be. Please correct me if I'm missing something.
That is a great question. Your example requires that someone other than the user has access to the computer and user's session and can install and run exe or scripts how they please. If that is the case, the computer is already compromised and you have far BIGGER problems. They could install a keylogger to capture passwords for any program they like! You can mitigate this with a password manager but for all intents and purposes that computer needs to be wiped.
I have mentioned a few times between this video and the preceding video ua-cam.com/video/k0yYVgTH-JA/v-deo.html that these utilities add security for the case when the Access data file is stolen, or, depending on how you deploy the keys, accessed (see many deployment examples at the end of one of the two videos). The encrypted data or passwords cannot or have an extremely low probability of being retrieved.
If your context is serious enough that you are wondering if these steps will be sufficient to secure your MS Access data, then your solution is ready to "level up" and use MS Access' preferred backend database that handles security in a more robust way. It is SQL Server, in the form of SQL Express (free, local computer), Azure SQL (pay, local), or SQL Server (pay, local). The steps for users are the generally the same for each as you can see here: ua-cam.com/video/6xotpT7Vhso/v-deo.html
The most secure solution for Access will use some flavor of SQL Server (or other enterprise db) as a backend, with your Access app running on the front-end. Access is designed to interop with SQL Server in amazing ways. You won't use MS Access as a database backend for situations that have a high security requirement, unless it is in tightly controlled single-user databases or something like that. Access is awesome but it just doesn't have that kind of mustard.
nice
can you provide this practical file ?
You can get it at mackenziemackenzie.com/downloads
Awesome, appreciate the hard work! What would you say is the easiest way to deploy this in a distributed front-end environment?
You can drop the files in the same folder as your MS Access front-end for each user. Starting at about the 25 minute mark in the previous video ua-cam.com/video/k0yYVgTH-JA/v-deo.html , you can see different deployment types. REMEMBER to delete the EncryptConnectStrings file after you run it to encrypt that section of their config. For your situation, you'll probably manage the application secret/passphrase to be the same for all. See the options - if you have questions, just ask!
@@seanmackenziedataengineering Thank you! I have already made a script that copies all files from a network drive folder to the user's computer when they open the database. I figure I can just drop them on there
Thanks
No problem!
🎓🎓🎓🎓
Very useful one
Just inquisitive >
password entered is case sensitive?
Deleting password = reset password?
How to protect config file?
You do it like very simple but there are lots to digest
I like to validate login username is in the table else close app
👍 u r the MAN
Thanks! Yes, passwords are case sensitive. The string is encrypted with 3DES, maintaining case, then hashed using SHA256. You can store the hashed value in your table as demonstrated. I show how the config file is automagically protected using some nice windows features at 10:25 where I use another little utility in the zip called EncryptConnectStrings. *Make sure to delete the EncryptConnectStrings exe file after you protect the config file each time!!* Store it somewhere else where only administrators can go. You can decrypt the config file using the same utility, if you need to make changes. In this video at about the 25 minute mark ua-cam.com/video/k0yYVgTH-JA/v-deo.html you can see different deployment options. You're absolutely right, there are many IF cases in deployment so make sure to ask questions. Do you think it is worth a video, just for deployment? Or a video for each deployment type :-p
Absolutely Well worth for both
For rookie like me it is a long haul
Sharing yr knowledge is greatly appreciated 🙏🏽👏
Great , thank you so much but there are 2 problem i detected
1)If you click on the encrypt button it will encrypt the password but if you click it 3 to 4 times then it will repeat itself the password will be encrypted again and again and now you have lost your password. So I think there should text added in the encrypted like "ABCD" if the ABCD is found that means it is encrypted so no need to encrypt it again and on the other hand if i click decrypt then if ABCD is already in the text that means it need to be decrypted and if a ABCD is not present then no need to decrypt again. there is "=" in every encrypted text but this is common , so "ABCD" should be unique.
2) and another problem is if there is an error when the error occur the "error" text word is written on the field record because of this original data is deleted and thats problem the solution like error show using message box. instead of writing on record
i am trying to make form on opening it decrypt the multiple filed so data on backend is encrypted and when I opened the form the data will be decrypted and on close event it will encrypted again. so my data will be safe . (please if possible try this form decrypt and encrypt on close experiment by your self )
please find solution of this both problem.
thank you again. so much
This is a great point; the purpose of this video is only to take you so far as "the password is hashed", or "the password attempt was Pass or Fail".
1. It will be up to you guys to integrate the coding into your logins because these will be different for almost everyone (and could be a whole video in itself). So, you will need to add some VBA to prevent hashing multiple times, perhaps add your own password complexity requirements, and other things. I think your idea is a good one, to use a tag to denote a hashed value! Some of you might use a y/n field or something like that as well.
2. You can also capture the error in your code. For example you could say if the return value is "Error" then don't write, otherwise write over the value. As I mentioned, each of you have different applications and will use these differently. Great point - I think people need to be aware of this.
For your "on open decrypt then on close encrypt" scenario, you could accomplish this by using an "Unbound forms" style of development. When the form opens, it is blank until the user enters or maybe uses a field selector to get a full record from the database. Say, a drop-down menu selects an employee from a list of Employee ID numbers. After you select, your procedure will select from the employee table where id = 123. 1 record with 10 encrypted fields in it. This loads into a recordset, then loads 10 fields on the form, but as it puts the value in each one, it decrypts it first. After loading all fields, the recordset is closed and the backend data is still encrypted while the user works on it in the form, then they click Save. Another procedure opens the recordset again for employee 123 and then encrypts, then updates each field value.
Great
Thanks!
hi sir! how are you?
sir please make a video on how to not allow duplicate dates for the same id, I have created an attendance system if I will add duplicate date for the same id it will create issues for me,
and thanks for your instructions, soon I am going to upload a demo video of my whole Employee management system which I create by following you and 1,2 other instructors I will definitely mention their names.
Hey, that's pretty cool that you made a system! Interesting project. To address the problem you're having, you can create one index on ID and Date fields, and set the index to Allow Duplicates = No. This will give an error if someone tries to enter the same date on the same ID ua-cam.com/video/A8-9erFqfkI/v-deo.html
¡Gracias!
Wow, thanks for the Super Thanks!!
I wish i could give more, your work has changed my trajectory!
@@miles6875 I’m humbled and glad that you have benefited like this! Thanks again
Thanks
Much appreciated!! Morning latte achieved 👍