So, the situation is that my customer has some Projects in their database they want to be archived over night. We scheduled a process to execute at a specific time, which executes a batch file. The batch file opens DOORS with username and password and runs a DXL program that goes through the Database and archives the Projects. Is there a way to do something like this without the user name and password being so blatantly obvious? The batch file needs to get stored on a server. So, any old Joe can come along, open the batch file, and get the password for a user that has some pretty important privileges. I considered encrypting the batch file, but I'm pretty sure it would have to be decrypted before it could be executed. I also considered writing a C program to do the same thing and only delivering the .exe. But, even that could be read without much effort. Any ideas? Thanks
woodpryan woodpryan - Thu Mar 19 17:56:02 EDT 2015 |
Re: Batch file DXL execution without password visible The batch file is started as a scheduled task. You can use a specific Windows account that starts the job. Now you only have to change the access rights of the batch file (or of a configuration file that contains the username/password) so that nobody except this account has any access rights. This way, not any old Joe can read the password, only an Admin Joe, but to do this, the Admin would have to take ownership of the file to see its contents. This is logged in the Windows security log --> fire the Admin Joe for stealing the password.
HTH, Mike
|
Re: Batch file DXL execution without password visible I am not convinced. Whenever DOORS security is involved you need to weigh the efforts against the benefits. One thing you need to be aware, whenever you think about securing DOORS: DOORS has only client side security, therefore you cannot secure DOORS. Period. An attacker with enough evil energy will get around any security that you can come up with and modify any data on the database (even the data that is not supposed to be modifiable!) (without even having a DOORS account). This being said you should know the following about batch file security: - Securing the Batch file by access rights is not enough. Anyone being able to list processes on the computer can find the plaintext password on the commandline of the running process inside the taskmgr. - Anyone with write access to the DOORS client can of course replace doors.exe to grab the password from the batch file. - whenever you execute a batch job you will need to pass the password in plain text over the commandline. From there any malicious DXL script can read that plaintext password by doing: string sPass = getenv "DOORSPASSWORD" and store that password somewhere or send it by email. Therefore when you execute any scheduled DOORS batch job, you would need to make sure, that no untrusted DXL code is invoked (e.g. attribute DXL / triggers, etc.). For me the only valid way to get around this problem would be to automatically change the password of the DOORS user inside the DOORS batch script immediately at the start of each run. The new password would need to be handed to the DXL script in a secure way. In any case the batch job must be executed on a secured server. Still I think that the effort for solutions like that are always a waste of energy if you take into account how easy it is to break the DOORS security. Regards, Mathias
|
Re: Batch file DXL execution without password visible Mathias Mamsch - Fri Mar 20 10:44:24 EDT 2015 I am not convinced. Whenever DOORS security is involved you need to weigh the efforts against the benefits. One thing you need to be aware, whenever you think about securing DOORS: DOORS has only client side security, therefore you cannot secure DOORS. Period. An attacker with enough evil energy will get around any security that you can come up with and modify any data on the database (even the data that is not supposed to be modifiable!) (without even having a DOORS account). This being said you should know the following about batch file security: - Securing the Batch file by access rights is not enough. Anyone being able to list processes on the computer can find the plaintext password on the commandline of the running process inside the taskmgr. - Anyone with write access to the DOORS client can of course replace doors.exe to grab the password from the batch file. - whenever you execute a batch job you will need to pass the password in plain text over the commandline. From there any malicious DXL script can read that plaintext password by doing: string sPass = getenv "DOORSPASSWORD" and store that password somewhere or send it by email. Therefore when you execute any scheduled DOORS batch job, you would need to make sure, that no untrusted DXL code is invoked (e.g. attribute DXL / triggers, etc.). For me the only valid way to get around this problem would be to automatically change the password of the DOORS user inside the DOORS batch script immediately at the start of each run. The new password would need to be handed to the DXL script in a secure way. In any case the batch job must be executed on a secured server. Still I think that the effort for solutions like that are always a waste of energy if you take into account how easy it is to break the DOORS security. Regards, Mathias
Mathias, I think that is a fantastic idea. Thank you so much for that answer. |
Re: Batch file DXL execution without password visible You could write a script that cleverly puts itself to sleep for a specific amount of time; lets say 7 hours and 1 minute; and then proceeds to archive. Run this scrpt at 5pm and you end up archiving just after midnight. The verbose version of such a function follows:
Problem with this is losing connectivity during the evening. -Louie Complicating things in the manner customary for me, I have an additional "Defer" dialog that inputs the time of day desired to wake up and "delays" that many seconds. Actually, this very old function keeps waking itself up and checking the time to see if it is in a window, but I think that was unnecissay. |
Re: Batch file DXL execution without password visible Hi There exits a standard script system - autoit (https://www.autoitscript.com/site/autoit/) - and here you can do the following.
Actually the it script has to handle the password, but the script can be compiled and then you get an exe file. Here the pw is not visibile. Best regards Wolfgang |
Re: Batch file DXL execution without password visible Wolfgang Uhr - Tue Mar 24 03:27:44 EDT 2015 Hi There exits a standard script system - autoit (https://www.autoitscript.com/site/autoit/) - and here you can do the following.
Actually the it script has to handle the password, but the script can be compiled and then you get an exe file. Here the pw is not visibile. Best regards Wolfgang This is another viable option, which also has a problem. The problem here is that someone with a hex editor can view the .exe file, and get the password. I considered writing a C program to execute the DXL code, but discounted it for the same reason. Thank you for your response, though. |
Re: Batch file DXL execution without password visible llandale - Mon Mar 23 18:56:02 EDT 2015 You could write a script that cleverly puts itself to sleep for a specific amount of time; lets say 7 hours and 1 minute; and then proceeds to archive. Run this scrpt at 5pm and you end up archiving just after midnight. The verbose version of such a function follows:
Problem with this is losing connectivity during the evening. -Louie Complicating things in the manner customary for me, I have an additional "Defer" dialog that inputs the time of day desired to wake up and "delays" that many seconds. Actually, this very old function keeps waking itself up and checking the time to see if it is in a window, but I think that was unnecissay. Something similar to this is yet another viable option I have considered. The problem with this one is the human involved. The customer wants this to be automatic. This solution requires someone to actually execute this script before they leave for the day. |