New Functionality Neccassary- STOP SPOT STEALERS
Moderator: Moderators
New Functionality Neccassary- STOP SPOT STEALERS
Due to a large amount of script changing(allows you to joinbattle as anyone else as long as you set it up, this is trivial and takes a few lines of code.) , We need to add a security parameter to the game. Unfortunately this takes a bit of effort, as it is fairly complex.
What i am proposing is that prior to the autohost launching spring, it sends a PM to your client(any flavor, would require cooperation between devs) with a unique ID. Then this unique ID is included in your start script, which in turn is sent to the the server hosting the battle(who sent you the code originally).
This would add an appropriate amount of security to solve this issue.
It would require all lobby devs to add a command to parse out and not show the user, something like #$#125235155#$# as a private PM, but not shown in the actual client.
It would also require a modification to all hosting abilities, so that the uniqueIDs where ALL included when you hosted, so that when passed to spring they can be verified, which brings us to:
It would require a modification of the spring application itself, to accept unique numbers associated with users.
None of this is that complicated and would improve gameplay around here alot. The other day someone was spot stealing for hours on many servers and it was quite irritating.
What i am proposing is that prior to the autohost launching spring, it sends a PM to your client(any flavor, would require cooperation between devs) with a unique ID. Then this unique ID is included in your start script, which in turn is sent to the the server hosting the battle(who sent you the code originally).
This would add an appropriate amount of security to solve this issue.
It would require all lobby devs to add a command to parse out and not show the user, something like #$#125235155#$# as a private PM, but not shown in the actual client.
It would also require a modification to all hosting abilities, so that the uniqueIDs where ALL included when you hosted, so that when passed to spring they can be verified, which brings us to:
It would require a modification of the spring application itself, to accept unique numbers associated with users.
None of this is that complicated and would improve gameplay around here alot. The other day someone was spot stealing for hours on many servers and it was quite irritating.
-
- Posts: 834
- Joined: 19 May 2009, 21:10
Re: New Functionality Neccassary- STOP SPOT STEALERS
http://springrts.com/phpbb/viewtopic.php?f=2&t=19823
http://springrts.com/phpbb/viewtopic.php?f=11&t=19867allow password-protecting client slots to prevent name spoofing (needs lobby support)
- TheFatController
- Balanced Annihilation Developer
- Posts: 1177
- Joined: 10 Dec 2006, 18:46
Re: New Functionality Neccassary- STOP SPOT STEALERS
Funny I thought you were talking about this :)
(from my 'spring crap' folder, not written for anything in particular)
Code: Select all
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
function gadget:GetInfo()
return {
name = "NoStartPointStealing",
desc = "Prevents start point spam / stealing",
author = "TheFatController",
date = "Jan 18, 2009",
license = "GNU GPL, v2 or later",
layer = 0,
enabled = true -- loaded by default?
}
end
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
if (not gadgetHandler:IsSyncedCode()) then
local startPoints = {}
local BLOCK_TIME = 2.5
local BLOCK_RANGE = 430
local function getDistance(x1,z1,x2,z2)
local dx,dz = x1-x2,z1-z2
return math.sqrt((dx*dx)+(dz*dz))
end
function gadget:GameStart()
gadgetHandler:RemoveGadget()
return
end
function gadget:MapDrawCmd(playerID, cmdType, px, py, pz, label)
if (cmdType ~= "point") then return end
startPoints[playerID] = {time = Spring.GetTimer(), x=px, z=pz}
end
function gadget:MousePress(x, y, button)
if button==1 then
local _,coords = Spring.TraceScreenRay(x,y,true,true)
local dx,dz = coords[1],coords[3]
if dx and dz then
for playerID,defs in pairs(startPoints) do
if (Spring.DiffTimers(Spring.GetTimer(), defs.time) > BLOCK_TIME) then
startPoints[playerID] = nil
elseif (getDistance(dx,dz,defs.x,defs.z) < BLOCK_RANGE) then
return true
end
end
end
end
return false
end
function gadget:MouseRelease(x, y, button)
return false
end
end
Re: New Functionality Neccassary- STOP SPOT STEALERS
"someone"? Is the autohost/host being goofy and not tracking the IPs?
-
- Spring Developer
- Posts: 1254
- Joined: 24 Jun 2007, 08:34
Re: New Functionality Neccassary- STOP SPOT STEALERS
It would be so much more usefull if the IPs where printed in the infolog...lurker wrote:"someone"? Is the autohost/host being goofy and not tracking the IPs?
Re: New Functionality Neccassary- STOP SPOT STEALERS
packet spoofing could override the IP address issue. More imprtantlyit would require that the protocol be changed. Its safer to use uniqueIDs.
Re: New Functionality Neccassary- STOP SPOT STEALERS
uh sef, those are implemented in spring... and you can only guarantee *sending* of spoofed packets... you can't necessarily expect to get anything back.
-
- Posts: 933
- Joined: 27 Feb 2006, 02:04
Re: New Functionality Neccassary- STOP SPOT STEALERS
There's no way to spoof active IP connections, since traffic has to return to the "right" address.Sefidel wrote:packet spoofing could override the IP address issue.
Can someone define "Spot stealing" exactly? It seems like people attempting to spawn on top of each other could be solved by a Lua gadget that establishes a minimum distance to the nearest other player. Then, you could just wait until all players are in game and given them a random order to chose start spots.
Another option would be a new gametype of "Choose pre-selected spots in game" where the only valid spots would be start positions included with the map in the host's startbox.
Re: New Functionality Neccassary- STOP SPOT STEALERS
Spot stealing is where you forge script.txt and connect as a different player. This lets you play when you were just a spec (or even not), kicking someone else out of the game. It has nothing to do with start positionsel_matarife wrote:There's no way to spoof active IP connections, since traffic has to return to the "right" address.Sefidel wrote:packet spoofing could override the IP address issue.
Can someone define "Spot stealing" exactly? It seems like people attempting to spawn on top of each other could be solved by a Lua gadget that establishes a minimum distance to the nearest other player. Then, you could just wait until all players are in game and given them a random order to chose start spots.
Another option would be a new gametype of "Choose pre-selected spots in game" where the only valid spots would be start positions included with the map in the host's startbox.
Re: New Functionality Neccassary- STOP SPOT STEALERS
So the information in your script.txt telling your client which team number etc you are is changed to that of somebody elses, coupled with connecting and loading before they do means when they do finally connect their slot is already full and the server boots them?
hmm is all this data not available to the lobby running on the hosts machine? Hence meaning that all the data needed to double check the client is present on the host already?
hmm is all this data not available to the lobby running on the hosts machine? Hence meaning that all the data needed to double check the client is present on the host already?
-
- Posts: 933
- Joined: 27 Feb 2006, 02:04
Re: New Functionality Neccassary- STOP SPOT STEALERS
The lobby server should pass the IP / names of the clients to the host so it can automatically assign people to slots as they connect. Why bother with something complex like unique IDs when IP addresses will work and be "unhackable"?
-
- Posts: 834
- Joined: 19 May 2009, 21:10
Re: New Functionality Neccassary- STOP SPOT STEALERS
Yes.AF wrote:So the information in your script.txt telling your client which team number etc you are is changed to that of somebody elses, coupled with connecting and loading before they do means when they do finally connect their slot is already full and the server boots them?
By default the client sends only public data. Double checking that is useless if no authentication is used.hmm is all this data not available to the lobby running on the hosts machine? Hence meaning that all the data needed to double check the client is present on the host already?
Re: New Functionality Neccassary- STOP SPOT STEALERS
The host should be handed IPs of all conencting clients then
Re: New Functionality Neccassary- STOP SPOT STEALERS
+1.The host should be handed IPs of all connecting clients then
I mean, it's not like would-be hackers aren't 100% able to get those IPs from the start, so it's not about security or privacy. If people are that paranoid about people having their IPs, they can use a proxy.
Re: New Functionality Neccassary- STOP SPOT STEALERS
Passing IPs is just as difficult as passing a unique/secure token. The token seems like it might be more robust (eg 2 players behind a nat having same ip, or situations where spring connects differently than the lobby client)Argh wrote:+1.The host should be handed IPs of all connecting clients then
I mean, it's not like would-be hackers aren't 100% able to get those IPs from the start, so it's not about security or privacy. If people are that paranoid about people having their IPs, they can use a proxy.
-
- Posts: 834
- Joined: 19 May 2009, 21:10
Re: New Functionality Neccassary- STOP SPOT STEALERS
Using a proxy for lobby breaks this, if the springs connects directly (host sees different IPs). Using a proxy for spring will increase latency - no one wants this.Argh wrote:+1.The host should be handed IPs of all connecting clients then
I mean, it's not like would-be hackers aren't 100% able to get those IPs from the start, so it's not about security or privacy. If people are that paranoid about people having their IPs, they can use a proxy.
For authentication you better use something you don't reveal by connecting to the lobby.
Checking IPs is afaik not yet implemented, a password check is.
-
- Posts: 933
- Joined: 27 Feb 2006, 02:04
Re: New Functionality Neccassary- STOP SPOT STEALERS
Also I think the IP and MAC address of players should be recorded in replays, probably as some sort of hash combining both. This would let the moderators easily track said users and ban them from the lobby.
-
- Spring Developer
- Posts: 1254
- Joined: 24 Jun 2007, 08:34
Re: New Functionality Neccassary- STOP SPOT STEALERS
I wanted to add the IPs (MAC is useless) to the infolog, but was defeated by bawwwing of random people concerned about "security".el_matarife wrote:Also I think the IP and MAC address of players should be recorded in replays, probably as some sort of hash combining both. This would let the moderators easily track said users and ban them from the lobby.
Re: New Functionality Neccassary- STOP SPOT STEALERS
Infolog for host only seems reasonable, they can easily get the IPs anyways.
Re: New Functionality Neccassary- STOP SPOT STEALERS
that is no valid argument for security concerns. it is like saying ISPs should store/give out info about their clients (eg IPs) however they want, cause they can get that info.det wrote:Infolog for host only seems reasonable, they can easily get the IPs anyways.