Urgent security notice for all FARR plugin writers

[electronixtar]

If you are going to publish you FARR MOD or plugin package on Web please double check every plugin folder  for "options.xml" where your Gmail account & password may be leaked through distribution. Especially "Google Calendar Quick Add" or any other account related plug-ins.

options.xml looks like this

Code

<options>
	<username label="Email :" value="xxx@gmail.com"/>
	<password label="Password :" value="xxx"/>
</options>

One of the DC member already made a terrible mistake. I can't image how many ppl have donwloaded that plugin package.

Also, are there any ready-to-use solutions for credentials storage?

Saving plain passwords in XML is not a good idea. I am currently trying to write a twitter plugin for FARR, but where to save the passwords? The web-based auth_token hacking is complex & unstable

[sri]

Thanks for bringing it to my notice.

22 have downloaded my zip file. I've now made this file private and changed my Gmail password.

[Perry Mowbray]

Also, are there any ready-to-use solutions for credentials storage?

Maybe it's best for FARR to handle this internally?

[Josh]

I blame mouser for this security hole! But again, even if it weren't his fault, I would blame him as well ;-)

[mouser]

I could add a FARR feature to help plugins figure out where to store data,
but let me clarify a little what this security hole is all about for people reading this and nervous.

There is a FARR plugin called "Google Calendar Quick Add", and with this plugin you have to configure your login info.

Sri decided to make a package of his pre-configured aliases and plugins and upload them for others.  He made a slight mistake and included the options file for this plugin, which has his gmail login info in it.

So this is not something any normal FARR user needs to be concerned with -- but it is a reminder for plugin writers and others who might zip up and share their FARR plugin configuration directories, to make sure you dont upload any configuration files that might have sensitive data inside them.

Like I said, I could add a feature into FARR which a plugin could call to get a MyDocuments folder suitable for storing options files, so that they arent in the normal FARR directories, but then again it would be just as easy for a plugin to do that.

[electronixtar]

I could add a FARR feature to help plugins figure out where to store data,
but let me clarify a little what this security hole is all about for people reading this and nervous.

There is a FARR plugin called "Google Calendar Quick Add", and with this plugin you have to configure your login info.

Sri decided to make a package of his pre-configured aliases and plugins and upload them for others.  He made a slight mistake and included the options file for this plugin, which has his gmail login info in it.

So this is not something any normal FARR user needs to be concerned with -- but it is a reminder for plugin writers and others who might zip up and share their FARR plugin configuration directories, to make sure you dont upload any configuration files that might have sensitive data inside them.

Like I said, I could add a feature into FARR which a plugin could call to get a MyDocuments folder suitable for storing options files, so that they arent in the normal FARR directories, but then again it would be just as easy for a plugin to do that.

Centralized storage would be cool.

ps another question: If 3 plugin use 3 FScript.dll, then there's 3 copy of FScript.dll in memory?

[mouser]

ps another question: If 3 plugin use 3 FScript.dll, then there's 3 copy of FScript.dll in memory?

i believe that is right.. until and unless ecaradec (the brilliant fscript author) decides to make a multi-script fscript version.  that's probably best discussed on the fscript thread though.

[rjbull]

double check every plugin folder  for "options.xml"
[...]

One of the DC member already made a terrible mistake. I can't image how many ppl have donwloaded that plugin package.

I was one of them.  I've now found and deleted all "options.xml" files in my FARR subdirectories; there were only two, both sri-related.  As an afterthought, I emptied the Recycle Bin as well.  Hope that leaves me returned to a state of innocence?

[f0dder]

ps another question: If 3 plugin use 3 FScript.dll, then there's 3 copy of FScript.dll in memory?

i believe that is right.. until and unless ecaradec (the brilliant fscript author) decides to make a multi-script fscript version.  that's probably best discussed on the fscript thread though.

Should only have one instance of script.dll in memory, unless one of the plugins decide to create a new process that then in turn uses fscript.dll. And even then, windows does copy-on-write sharing of DLLs system-wide.

[Perry Mowbray]

Centralized storage would be cool.

Let me clarify, often people like their passwords encrypted, and I wondered if many plug-ins were needing log-ins and passwords then if FARR handled that and the encryption then it's centralized and carries the FARR seal of quality.

[f0dder]

Centralized storage would be cool.

Let me clarify, often people like their passwords encrypted, and I wondered if many plug-ins were needing log-ins and passwords then if FARR handled that and the encryption then it's centralized and carries the FARR seal of quality.

Probably wouldn't be a bad idea to add this to the FARR core - and with an option of having the passwords stored either in a file (with some basic encryption, no need to go overboard with AES etc. since it's going to be reversible anyway, just make that perfectly clear to the users), or in the windows "secure storage" thing (protected & encrypted part of the registry, iirc).

[ecaradec]

I'll add a note in the FScript documentation about the login information issue. I must confess that I did it too, while developping the delicious plugin.