[QUOTE=Avaster;24481705]I really wish there was a way to help people and gain from it.... Sadly it seems impossible to profit from helping others....[/QUOTE]
If you jumped off a tall cliff it would profit both you and us.
Wouldn't you just love that :p sadly it wont ever happen hahah
[QUOTE=ZestyLemons;24478166]I'm pretty sure [b]he's[/b] found the perfect way to hack.[/QUOTE]
I put the flaw in bold
[QUOTE=ZestyLemons;24480050]Alternatively, find and get Avaster arrested[/QUOTE]
Good luck with that "Project" lol how bout you just send some more Mormons to my house like last time lol that was the only thing from the internet attacks that seemed to work haha
someonme give me avasters address
[QUOTE=CombineGuru;24482394]someonme give me avasters address[/QUOTE]
Doooooo itt I had so much fun with those Mormons trying to put me in the Perl white van so we could go study the bible xD
praise jesus
God grant me the serenity to accept the things I cannot change;
courage to change the things I can; and wisdom to know the difference.
Living one day at a time;
Enjoying one moment at a time;
Accepting hardships as the pathway to peace;
Taking, as He did, this sinful world as it is, not as I would have it;
Trusting that He will make all things right if I surrender to His Will;
That I may be reasonably happy in this life and supremely happy with Him
Forever in the next. Amen.
[QUOTE=CombineGuru;24482495]praise jesus
God grant me the serenity to accept the things I cannot change;
courage to change the things I can; and wisdom to know the difference.
Living one day at a time;
Enjoying one moment at a time;
Accepting hardships as the pathway to peace;
Taking, as He did, this sinful world as it is, not as I would have it;
Trusting that He will make all things right if I surrender to His Will;
That I may be reasonably happy in this life and supremely happy with Him
Forever in the next. Amen.[/QUOTE]
Okay that post wasn't "Creepy" at all.......
[QUOTE=ComWalk;24480412][b]Your scenario involving level changes isn't relevant; authentication only happens on initial connect. Clients don't reconnect when the level changes.[/b] ... A client connects and is immediately assigned STEAM_ID_PENDING and the engine then allows up to 20 seconds (or some other reasonable time) for the callback to be received, before defaulting to the steamid provided in the signed ticket.[/QUOTE]
This is what I don't understand - how often is it going to take >20 seconds to call back? Again, we want a unique identifier for the player that can be used to match them to previous sessions - do we use their IP address to save their data? What if multiple players use the same IP address?
[QUOTE]You really could have done without the ubisoft comment. It doesn't advance your position at all and only attempts to marginalize my argument by drawing a false parallel between an actually-intrusive DRM scheme and only allowing a clients identity to be verified by the only party that has the capability to do so without error.[/QUOTE]
The UbiSoft remark relates to the above: how often is it going to take >20 seconds to callback? Someone remarked: let's just make the player play without any persistent data if they don't authenticate in time. The player made progress, and all their progress was thrown out the window. Now they have to spend a length of time to get back to that position. Sounds like something UbiSoft would do. Still, if there is only a fuckknowsit% chance of losing game progress in an UbiSoft game, why do people have a problem with their DRM? Still, if there is only a fuckknowsit% chance of a player losing their persistent server data in a multiplayer game, why do I have a problem with the authentication scheme? I don't see a "false" parallel.
[QUOTE=ComWalk;24480412]
[b]A decent compromise:[/b]
A client connects and is immediately assigned STEAM_ID_PENDING and the engine then allows up to 20 seconds (or some other reasonable time) for the callback to be received, before defaulting to the steamid provided in the signed ticket.[/QUOTE]
This compromises security. Additionally, you might as well just use UniqueID() since STEAM_ID_PENDING is not a useful identifier for players.
[QUOTE=ComWalk;24480412]If it ends up having to default due to a dead connection, it can always verify the ticket when the connection is re-established. This limits the length of time that any client is assigned STEAM_ID_PENDING to something pretty reasonable in the absolute worst case scenario, but does leave servers vulnerable to steamid spoofing in the event of an extended backend outage. It seems fairly acceptable, since this same outage also allows VAC banned players to play on secure servers and administrative solutions ought to be using two-factor authentication anyways.[/QUOTE]
In the period of time that player has a spoofed SteamID, they have access to other players' data from legacy scripts. It could also be a pitfall for new scripts. It would be better to just use UniqueID(), as a scripter wouldn't fall victim to accidentally use an unverified SteamID() in serialized data. I'm assuming that this method relies on the scripter checking if the SteamID has been verified - so they'd have to make three function calls to identify a player...if verified, use SteamID, else, use UniqueID and don't save their data.
[QUOTE=ComWalk;24480412]
Using your scenario given, with that compromise, you lose no gameplay. Even with my initial solution, only [i]one[/i] round of gameplay would have been lost and that's assuming that the client joins around the time that a round is about to start anyways. And that round was only lost because the gamemode had poor support for unverified players; it could have, at the very least, provided a default loadout or something![/QUOTE]
If you compromise security, it allows players to cheat and user other person's data. We want to establish a persistent, unique identifier for persistent data; not just get them in the game.
[QUOTE=ComWalk;24480412]
[b]Other nitpicks[/b]
The parallel that you are trying to draw does not work. You can't equate "being unable to do anything without a nearly flawless connection that isn't interrupted for any period of time" with "not making any final statements about the identity of a client until that clients identity is proven by the only authority able to do so" while being honest. You are misrepresenting what I'm advocating to make it easier to marginalize.
[/QUOTE]Seriously, with public/private keys, the client is very able to prove their identity. What you're actually talking about is the server's ability to remember a client. And what the hell are those "final statements about the identity of a client" used for, exactly? Just banning? No - sweet, succulent, persistent data. Someone is going to do it. Someone is going to restrict people from playing because they are not authenticated - they don't have any tools they can use to automatically establish confidence in a player - this is the role that SteamID has been used for, this is the role I seek to replace. Construct servers will spawn all their newly connected players in quarantine until their SteamID is verified so that they can ban them. I hate to bring this up, but RP "gamemodes" can rely heavily on persistent data as well. Sure, the player could play without any of their previous work. Sure, in an UbiSoft game, you could start from the latest checkpoint and lose all your progress up to that point. But here is the thing: You can't equate an anti-piracy system to an identity-verification system. One requires three online parties: client, server, Steam server. The other requires only two online parties: client, server. If you use the former to create the latter, you unnecessarily bring in a third party; and from what I understand from you, that third party is potentially unresponsive. You're reading my words to create a response, not to understand me. [b][i]I apologize[/i][/b] for the UBISoft remark, and I sincerely considered apologizing in advance, but sometimes you have to prod someone to get them to listen.
[QUOTE=ComWalk;24480412]Your solution, at best, can only verify that a client is the same client that has joined in the past.[/QUOTE]
I understand that you want to ban players on the instant they join, but listen to the other half of the problem. This solution can do more, my friend. Understand my reasoning: admins of a specific server are very likely to have visited that server in the past, so they get their data and administrative functions back quickly. Clients that are new to that server are very likely to have never visited that server in the past. Fortunately, for the latter case, it is very common for a client that has never been to a specific server before to not have any save data on that specific server. We do not need to verify the SteamID for just a client that just wants to play - in fact, ever. If you wanted to ban the client, sure, a verified ID could be useful, but if he/she rejoins and makes a mess, a short-term IP ban would be justifiable. Hell, if their SteamID is authenticated quickly 80% of the time, they won't have time to do damage - note that this system cuts off their ability to steal admin.
[QUOTE=ComWalk;24480412]
In the absence of a previous connection from a client, you still depend on the backend for final verification. Since the most common use of this is bypassing bans, and given also that the people using it will have a large number of stolen steamids to use, the majority of which have likely not been used on any given server, your public key solution doesn't solve the problem. Your scheme does not provide instant verification, it's an instant [i]probable[/i] verification, which isn't good enough. Either it can be trusted, or it cannot. Your idea requires a lot of work for something that still doesn't belong in the 'trusted' category.
[/QUOTE]
You've misunderstood me. The backend is not used for final verification, it is used for tying different keys together (and it can do some banning on the side). Out of politeness for your argument, I'm going to assume that many players share the sa
[QUOTE=Avaster;24481885]Wouldn't you just love that :p sadly it wont ever happen hahah[/QUOTE]
Unless someone pushes you off.
[QUOTE=Avaster;24482471]Doooooo itt I had so much fun with those Mormons trying to put me in the Perl white van so we could go study the bible xD[/QUOTE]
did you aimbot them with baconbot
[QUOTE=Lau;24483719]Unless someone pushes you off.[/QUOTE]
True :p tho there wont be any pushing if I snap your pencil neck first turtle man LOL
[QUOTE=Avaster;24483828]True :p tho there wont be any pushing if I snap your pencil neck first turtle man LOL[/QUOTE]
With the amount of time you spend authoring aimbots and bypasses, I doubt you've had any time to work on your physical prowess. Now stop derailing.
[QUOTE=RoFLWaFFLEZZ;24483808]did you aimbot them with baconbot[/QUOTE]
Yes very much so :p
[QUOTE=grea$emonkey;24483884]With the amount of time you spend authoring aimbots and bypasses, I doubt you've had any time to work on your physical prowess. Now stop derailing.[/QUOTE]
I am turtle, master weak muscles.
This thread is great, but ultimately, I'm looking for authoritative figures in Valve and such to deal with this properly.
[QUOTE=grea$emonkey;24483884]With the amount of time you spend authoring aimbots and bypasses, I doubt you've had any time to work on your physical prowess. Now stop derailing.[/QUOTE]
Considering the fact that I don't code anything nor do any work, make for lots of time spent on bypassing random server anticheats and such right?
You could implement a form of message authentication on the lua library end. A token file is stored locally on said user's computer. When a person doesn't have a token, a new one is issued. If the tokens don't match the stored tokens, you could do anything you want to them, automatically.
It won't stop them from spoofing your Steam ID, but it could stop them from accessing privileges beyond their level, auto-kick/ban, whatever. If you could trigger some sort of VAC event for them, it might get rid of them for good.
Just an idea I wanted to float out there.
[QUOTE=Avaster;24484857]Considering the fact that I don't code anything nor do any work, make for lots of time spent on bypassing random server anticheats and such right?[/QUOTE]
They didn't believe me on page #3 :(
[QUOTE=Ideal-Hosting;24485430]They didn't believe me on page #3 :([/QUOTE]
I sowwie :(
[QUOTE=Night-Eagle;24483689]Additionally, you might as well just use UniqueID() since STEAM_ID_PENDING is not a useful identifier for players.[/QUOTE]
[lua]function _R.Player:UniqueID()
return util.CRC("gm_" .. self:SteamID() .. "_gm")
end[/lua]
Jus sayin'.
Avaster, how much have you made from this? :aaa:
[QUOTE=Night-Eagle;24483689]This is what I don't understand - how often is it going to take >20 seconds to call back? Again, we want a unique identifier for the player that can be used to match them to previous sessions - do we use their IP address to save their data? What if multiple players use the same IP address?[/QUOTE]
Well, looking through somebody else's data for once, apparently enough that it might prove to be a consistent problem for some people. The record length for a legitimate approval is around 2 minutes, however there is no way to tell what conditions existed that may have influenced that (such as the backend query getting stuck in a queue due to a dead connection).
I know that I personally ran a server that over the period of a few weeks had a few thousand connect attempts all of which completed nearly instantly (before a write to a database was able to complete), save for instances which I know for certain were spoofed, but the server in question has much higher traffic than mine (which existed for the sole purpose of testing anti-tranquility stuff), and it does indicate that relying only on backend-verified SteamIDs could very well be untenable. The problems appear to follow specific users around, but I’m not certain if this happens over a period of minutes, hours, or days.
[QUOTE=Night-Eagle;24483689]The UbiSoft remark relates to the above: how often is it going to take >20 seconds to callback? Someone remarked: let's just make the player play without any persistent data if they don't authenticate in time. The player made progress, and all their progress was thrown out the window. Now they have to spend a length of time to get back to that position. Sounds like something UbiSoft would do. Still, if there is only a fuckknowsit% chance of losing game progress in an UbiSoft game, why do people have a problem with their DRM? Still, if there is only a fuckknowsit% chance of a player losing their persistent server data in a multiplayer game, why do I have a problem with the authentication scheme? I don't see a "false" parallel.[/QUOTE]
To build on what I said above: It could take longer than 20 seconds frequently enough to be a problem. It appears to be less than 1% of the time and it does seem to follow around certain users (which I find quite interesting), which does lend itself to some alternative form of loading data for a user being useful.
As for why I don’t think the ubisoft parallel works: if you have a pending SteamID, you know it. Your auth could potentially stall, but it’s not a hidden risk, and once you [i]have[/i] been approved, nothing will call your SteamID into question until you attempt to connect to a server again. Compare this to the ubisoft system which ejects you if you lose the backend connection at any point during gameplay. With ubisoft’s drm, the risk of losing progress is always there; when using the steam backend it’s only there until you get the green-light from the backend.
[QUOTE=Night-Eagle;24483689]This compromises security. Additionally, you might as well just use UniqueID() since STEAM_ID_PENDING is not a useful identifier for players.[/QUOTE]
You are correct, it does, and that’s why if it were left up to me I would like to see STEAM_ID_PENDING always used until a backend response was received, with a player being ejected if no response is ever received. This is essentially what happens right now, but with STEAM_ID_PENDING being used until some sort of callback is received. Based on the response we did get from valve, this is probably what’s going to happen (see AzuiSleet’s earlier response).
Keep in mind that UniqueID is derived from the SteamID; check the wiki article for information on how that’s handled.
[QUOTE=Night-Eagle;24483689]In the period of time that player has a spoofed SteamID, they have access to other players' data from legacy scripts. It could also be a pitfall for new scripts. It would be better to just use UniqueID(), as a scripter wouldn't fall victim to accidentally use an unverified SteamID() in serialized data. I'm assuming that this method relies on the scripter checking if the SteamID has been verified - so they'd have to make three function calls to identify a player...if verified, use SteamID, else, use UniqueID and don't save their data.[/QUOTE]
This is the other reason that I personally prefer an absolute STEAM_ID_PENDING solution with no default middle ground. Properly coded existing scripts continue to function; poorly coded legacy scripts break. The earth continues to spin.
And again, UniqueID can’t be used in the absence of SteamID, and my response to this would be “don’t save data until a player has been authenticated” which I suppose once again lends itself to an alternative method of a client identifying itself to a server being necessary.
[QUOTE=Night-Eagle;24483689]If you compromise security, it allows players to cheat and user other person's data. We want to establish a persistent, unique identifier for persistent data; not just get them in the game.[/QUOTE]
I agree here, and this post has also cleared up what role you wish for your system to fill. I was initially interpreting this as a homegrown SteamID verifier (which is a bad idea). In light of the statistics I got from a much higher traffic server, something along these lines might not be an altogether bad idea.
With that said, I still have some concerns about the implementation.
[QUOTE=Night-Eagle;24483689]Seriously, with public/private keys, the client is very able to prove their identity. What you're actually talking about is the server's ability to remember a client. And what the hell are those "final statements about the identity of a client" used for, exactly? Just banning? No - sweet, succulent, persistent data. Someone is going to do it. Someone is going to restrict people from playing because they are not authenticated - they don't have any tools they can use to automatically establish confidence in a player - this is the role that SteamID has been used for, this is the role I seek to replace. Construct servers will spawn all their newly connected players in quarantine until their SteamID is verified so that they can ban them. I hate to bring this up, but RP "gamemodes" can rely heavily on persistent data as well. Sure, the player could play without any of their previous work. Sure, in an UbiSoft game, you could start from the latest checkpoint and lose all your progress up to that point. But here is the thing: You can't equate an anti-piracy system to an identity-verification system. One requires three online parties: client, server, Steam server. The other requires only two online parties: client, server. If you use the former to create the latter, you unnecessarily bring in a third party; and from what I understand from you, that third party is potentially unresponsive. You're reading my words to create a response, not to understand me. [b][i]I apologize[/i][/b] for the UBISoft remark, and I sincerely considered apologizing in advance, but sometimes you have to prod someone to get them to listen.[/QUOTE]
When I was talking about proving their identity, I was still misinterpreting this system as being used to prove that a certain SteamID belongs to them, which can’t be done. I understand your proposal more clearly.
The backend is more than an anti-piracy mechanism, though. It [i]is[/i] meant to be a reliable identifier, and yes, provided that the backend is functioning nominally, it excels at this. Third party identification is hardly the sole realm of anti-piracy solutions. A two party solution would be vulnerable to gaming; a malicious client would be able to create as many identities as they wanted in the absence of a third party. In steam’s case, you can be reasonably certain that one SteamID belongs to one person, and that there are significant obstacles in place to arbitrarily creating new ids (in this case, spending money). Yes, there are ways to combat this without the use of a third party, but my point stands: steam is more than an anti-piracy system, and the use of Steam as a central verifying authority isn’t a bad thing.
You have, ho
[QUOTE=ComWalk;24486055]
Wow, this post ended up a lot longer than I intended.[/QUOTE]
Major understatement.
[QUOTE=tepholman;24486021]Avaster, how much have you made from this? :aaa:[/QUOTE]
Enough to buy a expensive camera ;) (Which was his goal)
[QUOTE=Avaster;24484857]Considering the fact that I don't code anything nor do any work, make for lots of time spent on bypassing random server anticheats and such right?[/QUOTE]
Got past mine or still stuck with the extreme obfuscation?
Here's what one of the Steam engineers said:
[quote]
I am not familiar with all the flavors of server plugins that people are using, but any that grant the player privileges based on the result of the SendUserConnectAndAuthenticate() call without waiting for the GSClientApprove_t callback ( and thus the NetworkIDValidated() call ) are vulnerable.
[/quote]
I responded to him about a couple of my concerns, but it looks like generally they're expecting us to only acknowledge it when it's been approved. (In which case the engine is at fault)
[url]http://www.skiddiecentral.us/[/url]
Fuck, that made my day.
[QUOTE=CombineGuru;24499262][url]http://www.skiddiecentral.us/[/url][/QUOTE]
'twas a good read. Not that I agree with all of it.
[QUOTE=CombineGuru;24499262][url]http://www.skiddiecentral.us/[/url][/QUOTE]
I enjoyed
Sorry, you need to Log In to post a reply to this thread.
