Thinking outside the box...

[»CypherJF]

What are some things that you like, or dislike about the SSC or Catid's biller software/features...

 

What do you think should be expanded upon, or changed?

[»freakmonger]

not sure about non ssc biller features but more squad functions. Like having a Co Captain of a squad beable to do everything the owner can do except dissovle the squad.

 

I also like "owning" a ?chat channel and having mods being able to kick ppl off of the channel.

[Hakaku]

Yeah, I basically had the same idea as Freakmonger and Smong. To possibly be able to own secured chats (maybe prefix them, so not to conflict with normal chats used in SSC zones). And the other one would be to be able to create a friends list, and perhaps be notified when they're online.

 

Other than that, not much else I can think of.

[»freakmonger]

I like the friends list idea.

 

How about a ?sysops:message ?upperstaff ?staff command. Basically leaves the respective staff positions the message. So all players on sysop.txt get the message, Upperstaff could be upperstaff.txt or all players on smod+sysop.txt gets the message, etc etc

[»CypherJF]

How about a ?sysops:message ?upperstaff ?staff command. Basically leaves the respective staff positions the message. So all players on sysop.txt get the message, Upperstaff could be upperstaff.txt or all players on smod+sysop.txt gets the message, etc etc

 

The biller isn't aware of who is a mod, smod, sysop. So I don't think this would work unless it's connected to BanG somehow.

[»freakmonger]

yea I thought about that after I posted it but then said what the !@#$%^&*, you might be able to figure something out

[aquarius]

The server can recognise the files sysophelp.txt, upperstaff.txt, moderation.txt. It doesn't need to verify that they are staff. This even gives subgame the right to give players ?help power and nothing else.

[JoWie]

It would be alot easier if that was an ASSS module, shouldn't be hard to make.

 

You could also make copies of the motd module for each staff level. http://forums.minegoboom.com/viewtopic.php?t=7757

Edited January 5, 2008 by JoWie

[Bak]

I don't like how in order to authenticate into a biller you send them your password. Any zone owner can then take your password and use it as they please. A much better system would be to only have the password be sent to the biller when it's !@#$%^&*igned or changed (maybe directly or through some sort of web interface; not through the server). Then, to authenticate a player, the biller sends(through the server) some random bytes, which get appended to the player's name which gets appended to the player's password, and then a one-way hash is taken of that and the hash is what gets sent back to the biller (through the server). Now the server can't figure out your password, since it's a one-way hash, and they can't reuse the hash since the next time you log in the biller will send a different set of random bytes.

 

Something to think about anyway... maybe for Discretion

[Bak]

(4) Where can I get a copy of the biller?

 

> This will not be available to the general public for some time.

 

[»doc flabby]

I don't like how in order to authenticate into a biller you send them your password. Any zone owner can then take your password and use it as they please. A much better system would be to only have the password be sent to the biller when it's !@#$%^&*igned or changed (maybe directly or through some sort of web interface; not through the server). Then, to authenticate a player, the biller sends(through the server) some random bytes, which get appended to the player's name which gets appended to the player's password, and then a one-way hash is taken of that and the hash is what gets sent back to the biller (through the server).

Now the server can't figure out your password, since it's a one-way hash, and they can't reuse the hash since the next time you log in the biller will send a different set of random bytes.

Whats to stop a rouge server faking the biller sending its own "special" bytes to the client.

Biller: 1234

RougeServer: BillerBytes:0000

Client: hash(UserP!@#$%^&*0000)

RougeServer: Accepts HASH login.

 

Where is the danger you might ask? Well, if you have a short password its simple to bruteforce it. a 4 letter password only has 456976 combinations (!@#$%^&*uming a-z).

However more worryingly the server could send specially crafted bytes to the client that maximize weaknesses of the hashing algo.

Another issue is the server could save hashes and use them later, if and when the biller provides the same random bytes.

These attacks are pretty theoritical,

 

The biggest problem is it exposes the biller to direct DOS attacks and will use alot of bandwidth for the person running it.

 

You might want to have a look at the UserDB service for STF. Its a more secure version of what you have described. In the design I have used, the user database is separated from all other billing functions. In order to authenticate a user the billing server passes on an RSA encrypted password to the zone. This is then forwarded to the biller which checks it agaisnt the userDB. This means anyone can run a billing network wilst still using a central userdb

 

It uses RSA encryption, which is designed to never produces the same sting of bytes, even when the same password is encrypted.

 

This means the only way a password can be stolen is by editiing the code of the USERDB to save unencrypted passwords to the database (it uses sha-512 as standard)

Edited March 28, 2008 by doc flabby

[Sass]

Could you please include some type of Current Time command that the players can use to tell them the current time. Often times when I go back thru my logs there is no way to tell what time certain actions happened. Perhaps you can tackle this with the biller by giving players a ?currtime or ?mytime or ?clock command so we can push that into the logs as needed. Maybe you could have the biller display the current time (*according to the player's timezone) on login.

[»CypherJF]

Could you please include some type of Current Time command that the players can use to tell them the current time. Often times when I go back thru my logs there is no way to tell what time certain actions happened. Perhaps you can tackle this with the biller by giving players a ?currtime or ?mytime or ?clock command so we can push that into the logs as needed. Maybe you could have the biller display the current time (*according to the player's timezone) on login.

 

I'd have to argue this to be on the client.

 

Wouldn't be too hard to add, I think.

[»D1st0rt]

Hyperspace has ?localtime that tells you the current time in the server's timezone

[Sass]

Yeah, it could go on the client or like HS, on the server - but why not have it on the biller? Perhaps it could be useful as a code function for tracking usages etc.

[L.C.]

?top10 and ?coin are a nice feature, but should be optional (by that meaning that these commands can be enabled/disabled).

 

The ?c- commands are ugly, so I renamed them all to ?chat. Actually, you should probably take a look at http://www.hlrse.net/Qwerty/.ssb2-112/command.h to see how I would have done the commands.

 

Otherwise I would much prefer that Accede be kept simple, professional, and VIE-like.

 

How about a ?sysops:message ?upperstaff ?staff command. Basically leaves the respective staff positions the message. So all players on sysop.txt get the message, Upperstaff could be upperstaff.txt or all players on smod+sysop.txt gets the message, etc etc

Although nice features, I would completely disagree with them being part of a biller because VIE wouldn't do it; the design (aka the idea, the way it is written) isn't professional. It should be an ASSS module or bot function.

[»CypherJF]

The biggest issue I face is the incompatibilities between the 2 billing protocols. One set allows scores to be saved, the other does not. The other allow remote zones to be recycled, while the other does not. One also allows malicious log events to be notified on the biller server for admin's to look into, the other does not.

 

The struggle is to balance these things out and find a way to make them compatible without changing the way everyone is used to - trying to keep to the SSC look and feel as much as I can and improving wherever.

[»doc flabby]

The biggest issue I face is the incompatibilities between the 2 billing protocols. One set allows scores to be saved, the other does not. The other allow remote zones to be recycled, while the other does not. One also allows malicious log events to be notified on the biller server for admin's to look into, the other does not.

Whats to stop you developing the TCP billing protocol further, so it is more inline with the UDP with your own modifications?

[»CypherJF]

Firstly, I'm not a C developer; secondly, I'm focused on getting the basic functionality and stability built up first. It's not out of the world to think someday I or someone else will come up w/ add-on's to either protocol.