How safe is using scripts / batch files / Macros that involve password form filling?

[connect4]

For example, theres a program called Roboform that has a password filling feature that is supposed to be safer than manually typing in your password for websites.

http://www.roboform.com/anti-keylogger.html

 

"..Quick Typing. Roboform enters password quickly and it presses Submit button quickly, so many keyloggers will not be fast enough to get web page password from the page..."

 

 

What about using Batch files or ME Macros?

 

I mean would it be safer or more vulnerable to use a batch file or a macro to input your password into a program, for example TrueCrypt password prompt.

 

For example: If I were to mount a TrueCrypt container, it would pop up a password promt in which I would have to manually enter in my password.

 

Now, would it make it any more or less safe using a macro or batch file to mount my TrueCrypt container?

Example: Create a batch file that uses TrueCrypt command line feature to mount my container.

 

Note:

This is assuming that no malware or user can access your batch files or macros that would contain your password/s. I want to find out if there are any vulnerabilities to using batch files or macros while they are running. (Hypothetical example: using bat files=> copies ur password somewhere that is insecure that manually typing doesn't do.)

(Also: I use Windows XP)

[Cory]

This is all complete speculation so take this with a grain of salt. I was talking with a programmer friend about form filling applications and how they managed to be so efficient. IE I know the difficulties with doing them in MEP with mouse moves and so on. At the time I was working on a macro that was entering data thousands of times into Java web forms and it was taking a really long time due to all the checking and rechecking. I was hoping to find some programmatic way to enter the data and he showed me. The web page is an object and all of the buttons, links, form fields, and anything that can be interacted with can be accessed programmatically. Using a simple quick program he wrote he demonstrated it for me and sent text to a form field much like we send text to a control. IE it was not ‘typing’ or using the clipboard. Needless to say my next big project like this probably will not use MEP!

 

Going back to your question I believe that if a keystroke logger was only listening to what was being typed it would see what you type and what MEP ‘typed’ the same way and therefore no more secure. However I believe form filling programs are working on another level and would be more secure. That being said I think that it’s likely that these loggers could be more sophisticated and see the information exchange between the browser and form filling application and effectively snoop that. The upshot is I think it would require a relatively unsophisticated logger to see everything that goes to your web browser regardless of the tactics they employ.

 

IMHO too much time is wasted defeating detection by loggers and other such things. Instead that energy should be redirected to ensuring no loggers get on your system to begin with. In a battle with limited resources (and which one isn’t) it’s best to concentrate your resources at the front. Hitler held his Panzers in reserve on D-Day and see how well that worked for him. I can’t tell you how many times a user has demonstrated all these convoluted, time consuming, and oft ineffective measures to combat invisible threats and yet they run AVG Free with 20 day old DATs. Pfft.

[connect4]

...Going back to your question I believe that if a keystroke logger was only listening to what was being typed it would see what you type and what MEP ‘typed’ the same way and therefore no more secure. However I believe form filling programs are working on another level and would be more secure. That being said I think that it’s likely that these loggers could be more sophisticated and see the information exchange between the browser and form filling application and effectively snoop that. The upshot is I think it would require a relatively unsophisticated logger to see everything that goes to your web browser regardless of the tactics they employ.

 

IMHO too much time is wasted defeating detection by loggers and other such things. Instead that energy should be redirected to ensuring no loggers get on your system to begin with. In a battle with limited resources (and which one isn’t) it’s best to concentrate your resources at the front. Hitler held his Panzers in reserve on D-Day and see how well that worked for him. I can’t tell you how many times a user has demonstrated all these convoluted, time consuming, and oft ineffective measures to combat invisible threats and yet they run AVG Free with 20 day old DATs. Pfft.

 

 

Hi Cory, Thank you for your response.

 

First I want to say that I agree with you that the best form of anti malware / spyware is prevention and I believe that I use very safe practices to minimize threats.

 

At the same time, I still would like to utilize the most secure methods of password inputting if possible.

 

 

...However I believe form filling programs are working on another level and would be more secure.

 

 

This leads me to wonder if there is any way to integrate these "spyware defeating methods" used by those filling programs into Macro Express 3. I just think that would be a great additional security feature.

[paul]

This leads me to wonder if there is any way to integrate these "spyware defeating methods" used by those filling programs into Macro Express 3. I just think that would be a great additional security feature.

I use Roboform and have integrated it into MEP as follows (which assumes that the Roboform icon is always visible in the tray):

- Let's say I have a macro that wants to open my xyz bank account with Roboform looking after the xyz account details

- The macro initializes a specific variable called, say, %tRoboform% with xyz and calls a macro called Passcards

- Passcards right-clicks on the Roboform tray icon and logs me off (this is essential because it allows me to autoload a separate macro when the master password is requested); it then runs Roboform's Passcards.exe and passes in the relevant passcard file (derived from %tRoboform%)

- The first thing Passcards will do is request the master password because I'm now logged off

- This causes a separate macro to autoload when the Roboform window appears asking for the master password, which types in the master password, then takes customized action depending on the value in %tRoboform% (e.g. some logins require no additional action, others require clicks in certain places, and/or closing the original tab, etc.)

 

This approach also works with ME3 because there is no need to have 2 macros running simultaneously.