User Information Security.

[iago]

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

They do?  I hadn't noticed.  The war3 hashing was changed to SRP which is significantly more secure (unless you're sending plaintext passwords to bnls, but that's another story), but they're basically using an open protocol to do it.  Maybe at one time they tried to do that, but I find it unlikely that they do anymore.  Also, my code is pure opensource, so I don't protect it from anybody.  In fact, I have no idea who/what you're talking about -- have you actually read the topic? :-P

The problem with your (Soul's) suggestion is that there isn't an easy way to make those variables special.  Maybe I'll build in a special way, that it would be really roundabout and yucky to do, and break a lot of OOP-ness, and I don't like it :-/

[Skywing]

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

They do?  I hadn't noticed.  The war3 hashing was changed to SRP which is significantly more secure (unless you're sending plaintext passwords to bnls, but that's another story), but they're basically using an open protocol to do it.  Maybe at one time they tried to do that, but I find it unlikely that they do anymore.  Also, my code is pure opensource, so I don't protect it from anybody.  In fact, I have no idea who/what you're talking about -- have you actually read the topic? :-P

The problem with your (Soul's) suggestion is that there isn't an easy way to make those variables special.  Maybe I'll build in a special way, that it would be really roundabout and yucky to do, and break a lot of OOP-ness, and I don't like it :-/

Actually, as you should know, their implementation has several notable flaws that likely have a negative impact on how secure it is.

[MyndFyre]

How'd you do that in code, K?

[iago]

How'd you do that in code, K?

That wouldn't work too well on a console bot

[K]

[snip img]

How'd you do that in code, K?

I've played with multiple methods.  What I ended up doing was comparing Assembly.GetExecutingAssembly() with Assembly.GetCallingAssembly(), and throwing an exception if they were different - ie, only the assembly containing the class can read from it, but any one can write to it.

Another option is to not have the password / cdkeys be a property, but to have set_/get_ functions and mark the get_ function internal.

Yet another option is to insantate a System.Diagnostics.StackTrace and see where the call is coming from.

[MyndFyre]

I've played with multiple methods.  What I ended up doing was comparing Assembly.GetExecutingAssembly() with Assembly.GetCallingAssembly(), and throwing an exception if they were different - ie, only the assembly containing the class can read from it, but any one can write to it.

Another option is to not have the password / cdkeys be a property, but to have set_/get_ functions and mark the get_ function internal.

Yet another option is to insantate a System.Diagnostics.StackTrace and see where the call is coming from.

As I understand it, the get_ part of a property must be as-or-more-accessible than the set_ part.  That might have been changed though.

Using the above-given attribute class, I tested it out to work as expected using the SecurityAction.LinkDemand value.  If the calling method isn't in an assembly with a specified key pair, then an exception is thrown.

[K]

I've played with multiple methods.  What I ended up doing was comparing Assembly.GetExecutingAssembly() with Assembly.GetCallingAssembly(), and throwing an exception if they were different - ie, only the assembly containing the class can read from it, but any one can write to it.

Another option is to not have the password / cdkeys be a property, but to have set_/get_ functions and mark the get_ function internal.

Yet another option is to insantate a System.Diagnostics.StackTrace and see where the call is coming from.

As I understand it, the get_ part of a property must be as-or-more-accessible than the set_ part.  That might have been changed though.

Using the above-given attribute class, I tested it out to work as expected using the SecurityAction.LinkDemand value.  If the calling method isn't in an assembly with a specified key pair, then an exception is thrown.

not properties

[Adron]

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.

Yes, with a badly chosen password and some auto-replies it might become highly ineffective at protecting the password.

Example:

User uses a word found in a dictionary as the password for the account.

Op bot with a public command such as ".msg" for leaving a message for a particular registered user.

Bot replies with "Error: User 'username' doesn't exist!" when given the command ".msg username yo, sup?" if username doesn't exist.



Do you see the danger?

[tA-Kane]

People should use either 'e' or ' ' for their passwords. It's short, simple, and easy to make bots mistakenly filter it.

Blizzard goes to significant lengths to make sure you bot makers cannot make bots, and you defeat the mechanisms.

They do? I would be more worried about cheating instead of programs that monitor (even abuse, in the cases of spammers and flooders) a proprietary chat system.