User Information Security.

[K]

When you have a robust Plugin API that is able to completely control all aspects of your bot (in this cass class/object), is there a real danger that a malicious user might use it to steal CD Keys or account passwords?  I was just thinking about this the other day and added some security checks to prevent this from happening.  Anyone else have any thoughts on the subject?

Basically, I'm encrypting password/cdkey information when it's written to the settings file, and I added a check in the Bot.Password and Bot.CDKeys accessors that checks to make sure the calling assembly is the same as the executing assembly (ie, only objects inside the BattleNet.Binary.dll can retrieve password/cd key information); otherwise I throw a SecurityAccessViolation containing the file name of the offending assembly.

Am I being paranoid?

[LivedKrad]

Do you hallucinate evil men with camoflauge uniforms, large automatic guns, and tanks? If so, I'd say you're paranoid.

[iago]

If people want to submit plugins for my bot, my condition is that they are opensource, and that I have the right to inspect and, if I decide to, reject them.

If people want to trade them amongst themselves, then that's their risk.

Actually, I'm going to write a filter that makes sure that cdkey and password can never be sent out to battle.net in plaintext.

[Kp]

If people want to submit plugins for my bot, my condition is that they are opensource, and that I have the right to respect and, if I decide to, reject them.

and if people don't agree to let you respect their code, what option do you leave them?

[iago]

If people want to submit plugins for my bot, my condition is that they are opensource, and that I have the right to respect and, if I decide to, reject them.

and if people don't agree to let you respect their code, what option do you leave them?

Typo, respect should have been inspect

*fixes*

[Skywing]

When you have a robust Plugin API that is able to completely control all aspects of your bot (in this cass class/object), is there a real danger that a malicious user might use it to steal CD Keys or account passwords?  I was just thinking about this the other day and added some security checks to prevent this from happening.  Anyone else have any thoughts on the subject?

Basically, I'm encrypting password/cdkey information when it's written to the settings file, and I added a check in the Bot.Password and Bot.CDKeys accessors that checks to make sure the calling assembly is the same as the executing assembly (ie, only objects inside the BattleNet.Binary.dll can retrieve password/cd key information); otherwise I throw a SecurityAccessViolation containing the file name of the offending assembly.

Am I being paranoid?

There is always that danger if you are loading untrusted code into a program.  With a native program, the most sensible idea is to not to do it.  I'm not familiar with how all the .NET access controls work, so you might be able to do something secure there with only granting certain permissions to verified, untrusted assemblies.  I think you will have to do some very careful reading of the .NET documentation to get it really secure, though, as it only takes one slipup to break security.

If people want to submit plugins for my bot, my condition is that they are opensource, and that I have the right to inspect and, if I decide to, reject them.

If people want to trade them amongst themselves, then that's their risk.

Actually, I'm going to write a filter that makes sure that cdkey and password can never be sent out to battle.net in plaintext.

I think you are fighting a losing battle.  What if the malicious code encrypts or otherwise obfuscates the CD-Key/password somehow?  What if it usurps the socket from your code entirely? etc...

[iago]

Well, my way would make it hard to accidently do it.

For a period, there was a .get command which returned variable, like ".get homeChannel", etc.  Whoever wrote it probably didn't realize the potential problems caused by .get cdkey.  

My first solution is the main one, to be able to look at the code.  The second is just for accidental leakage, more.  I think both should be necessary.

[MyndFyre]

One of the ways I plan on restricting certain methods and properties in the final version is using the .NET security StrongNameIdentityPermissionAttribute attribute (does Kp still think that Microsoft makes ungodly-long identifiers?).

Since my settings classes have instances provided to plugins, I'll need to keep my key pairs separate, since the public key will be part of my code.

But anyway, that's what I will be doing.  I haven't done anything like that yet, but this attribute is probably what I need to use.

[iago]

I implemented it:

[20:21:54.942] <From: te(sting> homeChannel = op e1-
[20:21:54.946] <From: iago[e65536]@Lordaeron> homeChannel = op e1-
[20:22:02.170] <iago[e1]> %getvar password
[20:22:02.617] <From: iago[e65536]@Lordaeron> password = [password removed]
[20:22:02.642] <From: te(sting> password = [password removed]
[20:22:06.312] <iago[e1]> %getvar cdkey
[20:22:06.670] <From: te(sting> cdkey = [cdkey removed]
[20:22:06.753] <From: iago[e65536]@Lordaeron> cdkey = [cdkey removed]

[K]

 

[Kp]

I implemented it:

[20:21:54.942] <From: te(sting> homeChannel = op e1-
[20:21:54.946] <From: iago[e65536]@Lordaeron> homeChannel = op e1-
[20:22:02.170] <iago[e1]> %getvar password
[20:22:02.617] <From: iago[e65536]@Lordaeron> password = [password removed]
[20:22:02.642] <From: te(sting> password = [password removed]
[20:22:06.312] <iago[e1]> %getvar cdkey
[20:22:06.670] <From: te(sting> cdkey = [cdkey removed]
[20:22:06.753] <From: iago[e65536]@Lordaeron> cdkey = [cdkey removed]

Wouldn't it be better to instead have the bot refuse to return the information at all, rather than trying to return it and having it filter its own answer?  That is, have the response be something like "Cannot query that variable over battle.net".

[MyndFyre]

Kp raises a good point.  How does your filter work?

What if someone says, .say <insert-password-here>.  Does your bot respond, "So-and-so says: [password removed]" ?

[iago]

Yes, it would say that.

When a SID_CHATCOMMAND is sent out, it is checked and, if necessary, filtered.

The thought I was having is that it depends on a well chosen password to be effective, and many probably don't have a well chosen password.  Maybe I'll make this optional, off by default, and just leave the cdkey one.

[Soul Taker]

Yes, it would say that.

When a SID_CHATCOMMAND is sent out, it is checked and, if necessary, filtered.

The thought I was having is that it depends on a well chosen password to be effective, and many probably don't have a well chosen password.  Maybe I'll make this optional, off by default, and just leave the cdkey one.

Why not just restrict those two variables to only be used internally, and not be allowed to be called by any commands/plug-ins/etc?

[Grok]

Oh the irony.  Blizzard goes to significant lengths to make sure you bot makers cannot make bots, and you defeat the mechanisms.  Now you want to protect your code from hackers