They will do nothing like always until the issue is getting a real problem for everyone.
This is not the first time. And it end up always that anyone released the exploit. Sorry for my bad english this time!
[QUOTE=Night-Eagle;24476235]Perhaps if we call it "password_key_do_not_share" instead of "key", we could avoid the first problem. About the arbitrary file reading/writing exploits: Valve can fix those once they catch them, right? Valve can't really fix this problem with instant/offline identification. Also, is it not possible for a program to open a particular file for exclusive read access while it is running? Finally, the identities that we are creating with public/private keys are disposable assuming that Steam's backend doesn't report wrong information - it just needs to report correct information, or no information at all.[/QUOTE]
People can barely heed warnings in giant, flashing, red font. In my opinion this solution is really just two-factor authentication but with a password that's essentially automatically entered. The price of this convenience is that the second factor becomes easier to compromise.
A better solution (but still impractical, in my opinion) would be for each server to prove its identity to the client, at which point the client would enter in a password that they choose for a specific server.
EDIT: Another problem comes when a server is connected to for the first time with a spoofed id. Then the identity established on the server is that of the attacker's.
The best overkill solution is to use the steamcommunity openid provider. Absolutely secure, no messing around with keypairs, it's relatively idiot friendly, and the validation is straight from valve itself. Offline/instant validation is a lost cause.
[QUOTE=Night-Eagle;24476272]...that was basically what I said when I replied to you.[/QUOTE]
Actually, it's not. As far as I can tell, you're still going on about your new function names being used (with optional not using it [???]), which as I've said before, is a stupid and pointless move.
[QUOTE=q3k;24476174]You are absolutely right. But wouldn't it be better if the exploit was available to everyone, and not just a couple of skiddies who paid for it?[/QUOTE]
When you release it people may actually will make a real fix for this problem.
The downside would be a giant shitstorm.
It will be released anyway... if now or later.
And better release and we get a fix instead of having 20 kids running arround with that thingy.
Perhaps we could agree on a (at least mostly) effective method of blocking the worst effects of this before throwing it into the wild?
[editline]12:56AM[/editline]
To put it another way:
If you've got a shitstorm in a bottle, find an umbrella before pulling out the cork.
[QUOTE=Lexic;24476577]Perhaps we could agree on a (at least mostly) effective method of blocking the worst effects of this before throwing it into the wild?[/QUOTE]
Use the fix posted in the OP, only allow IsAdmin/IsSuperAdmin to return true when an approval callback has been issued.
If you want to stop faulty approval callbacks (keep in mind, this is an edge case and generally requires the attacker to act within seconds of getting the id), don't allow IsAdmin/IsSuperAdmin to return true unless an approval callback has been issued AND the client has used the openid provider to verify their identity [b]with the ip[/b] that they are connecting with.
EDIT: And to add to this, I think we should wait for everybody else to have an umbrella as well. It's important to give valve a chance to respond before doing anything.
[QUOTE=ComWalk;24476431]People can barely heed warnings in giant, flashing, red font. In my opinion this solution is really just two-factor authentication but with a password that's essentially automatically entered. The price of this convenience is that the second factor becomes easier to compromise.[/QUOTE]
I think a good percentage of people that, when asked for a file named "password_key_do_not_share.txt", will be hesitant.
[QUOTE=ComWalk;24476431]A better solution (but still impractical, in my opinion) would be for each server to prove its identity to the client, at which point the client would enter in a password that they choose for a specific server.[/QUOTE]
That solution is prone to file reading/writing exploits as well, but it doesn't address the issue of supporting legacy code. The solution I provided allows for authentication before the first IsAdmin() call.
[QUOTE=ComWalk;24476431]EDIT: Another problem comes when a server is connected to for the first time with a spoofed id. Then the identity established on the server is that of the attacker's.[/QUOTE]
This is resolved when Steam's backend kicks in and sees that the SteamIDs do not match. Also, data for unverified users is not saved under the user's SteamID. It is saved under the users SteamID with a number unique to that SteamID concatenated to it, which is checked against the attacker's key - they would not be able to access it without the correct key.
In addtion, when the actual owner of the SteamID is on that server, they will have option to delete the data saved for them rather than load it.
The key file is shit.
Before a admins steamid can be used the admin must join a 'infected' / fake server. So... they can read from that file too.
[QUOTE=Lexic;24476460]Actually, it's not. As far as I can tell, you're still going on about your new function names being used (with optional not using it [???]), which as I've said before, is a stupid and pointless move.[/QUOTE]
I provided the reason why I laid it out like I did, dismissed it, then said I agreed with you. Generally, that counts as agreeing with you.
[editline]05:06PM[/editline]
[QUOTE=Ideal-Hosting;24476834]So... they can read from that file too.[/QUOTE]
If the file is opened with exclusive read/write access in a separate thread, can it be read from the engine exploits you refer to?
Could we store the key in the Windows registry?
[QUOTE=Night-Eagle;24476777]I think a good percentage of people that, when asked for a file named "password_key_do_not_share.txt", will be hesitant.[/QUOTE]
You have more faith in people than I do, then.
[QUOTE=Night-Eagle;24476777]That solution is prone to file reading/writing exploits as well, but it doesn't address the issue of supporting legacy code. The solution I provided allows for authentication before the first IsAdmin() call.[/QUOTE]
Which lends itself to the general insecurity of the idea as a whole. It's more of a speedbump than anything. Concerning legacy code: scripts should already be using PlayerAuthed. If they aren't, it's their own damned fault when everything breaks. We shouldn't be making sweeping changes to authentication to save the special snowflakes who we shouldn't have burdened with PlayerAuthed from themselves.
[QUOTE=Night-Eagle;24476777]This is resolved when Steam's backend kicks in and sees that the SteamIDs do not match. Also, data for unverified users is not saved under the user's SteamID. It is saved under the users SteamID with a number unique to that SteamID concatenated to it, which is checked against the attacker's key - they would not be able to access it without the correct key.
In addtion, when the actual owner of the SteamID is on that server, they will have option to delete the data saved for them rather than load it.[/QUOTE]
Alright, fine, but is it [i]really[/i] worth all the trouble to save scripts that don't properly use PlayerAuthed?
[QUOTE=Ideal-Hosting;24476834]The key file is shit.
Before a admins steamid can be used the admin must join a 'infected' / fake server. So... they can read from that file too.[/QUOTE]
Er, you don't quite understand how public key authentication works.
[QUOTE=Night-Eagle;24476859]I provided the reason why I laid it out like I did, dismissed it, then said I agreed with you. Generally, that counts as agreeing with you.
[editline]05:06PM[/editline]
If the file is opened with exclusive read/write access in a separate thread, can it be read from the engine exploits you refer to?
Could we store the key in the Windows registry?[/QUOTE]
Garry would have to bypass IFileSystem to do this as it doesn't support exclusive read access, and while the registry would work, I think there are better ways. (Delay PlayerAuthed!!)
Got it now. Sorry. Didn't read the thing. (just from the quote half thingy)
[QUOTE=ComWalk;24476926]Alright, fine, but is it [i]really[/i] worth all the trouble to save scripts that don't properly use PlayerAuthed?[/QUOTE]
I'm going to assume that PlayerAuthed works (but not Steam's backend).
This isn't to save the scripts that don't properly use PlayerAuthed.
What if the Steam backend server doesn't respond? That's the problem with the fix posted in OP, right? So, if we have a gamemode that properly uses PlayerAuthed and has persistent player data, and the Steam backend doesn't respond, you'll essentially be locked out of the game until you reconnect. Say the game starts half-a-minute after all the players from the last map connect. It takes one minute to connect. You have to reconnect before you can play. The game starts without you. You cannot spawn until the next round. The game changes map every two rounds. You're locked out of the game every other round because users decided to use an anti-piracy system for identification.
Why doesn't Valve bar a player from playing until their SteamID is verified? Perhaps they didn't want the system to be [b][i]intrusive[/i][/b]. If we limit ourselves to using Valve's backend, we will be doing everything Valve tried to avoid.
If Steam's backend works 100%, though, and with minimal delay, then there is no problem. I think UbiSoft has some software you will like, too.
[QUOTE=Night-Eagle;24477203]I'm going to assume that PlayerAuthed works (but not Steam's backend).
This isn't to save the scripts that don't properly use PlayerAuthed.
What if the Steam backend server doesn't respond? That's the problem with the fix posted in OP, right? So, if we have a gamemode that properly uses PlayerAuthed, and the Steam backend doesn't respond, you'll essentially be locked out of the game until you reconnect. Say the game starts half-a-minute after all the players from the last map connect. It takes one minute to connect. You have to reconnect before you can play. The game starts without you. You cannot spawn until the next round. The game changes map every two rounds. You're locked out of the game every other round because users decided to use an anti-piracy system for identification.
Why doesn't Valve bar a player from playing until their SteamID is verified? Perhaps they didn't want the system to be [b][i]intrusive[/i][/b]. If we limit ourselves to using Valve's backend, we will be doing everything Valve tried to avoid.
If Steam's backend works 100%, though, and with minimal delay, than there is no problem. I think UbiSoft has some software you will like, too.[/QUOTE]
This is how it worked before, and it wasn't intrusive and painful before. You can play with STEAM_ID_PENDING, you just won't have access to anything tied to your own user. A huge deal? No.
This wouldn't even happen until valve fixed the backend. The callback is always received provided the game server is connected to the steam backend. They could easily ensure that an approval always comes down even when the server is disconnected by adding a ticket to a queue to be processed as soon as the connection is re-established. This rarely takes more than 30 seconds. Deny callbacks would presumably also be issued much more rapidly (they aren't issued until the validation stalls as-is).
Your scenario involving level changes isn't relevant; authentication only happens on initial connect. Clients don't reconnect when the level changes.
STEAM_ID_PENDING isn't some disfigured, disease-ridden monstrosity to be feared; it's exactly what we need now and what we had in the past. It wasn't intrusive then and it won't be intrusive now. The very worst case is indeed that you have to reconnect.
Do you really think some huge offline authentication system is worth preventing that?
[QUOTE=ComWalk;24477473]Do you really think some huge offline authentication system is worth preventing that?[/QUOTE]
I wasn't being sarcastic. If Steam's backend works 100%, though, and with minimal delay, then there is no problem. I think UbiSoft has some software you will like, too.
Well, Avaster just hopped on a zs server I was playing, got banned, rejoined, got banned, rejoined, and so on.
Then he DDOS'd the server and left. As fucking hilarious as it was, I'm pretty sure he's found the perfect way to hack.
Or, we can always make it so any admins that connect with their steam ID, must be on the whitelist of IPs :D
Thus, it sucks if you have a dynamic IP though :/
Alternatively, find and get Avaster arrested
for? Breaking Valve TOS?
You guys still think Avaster made Serenity?
[QUOTE=Night-Eagle;24477619]I wasn't being sarcastic. If Steam's backend works 100%, though, and with minimal delay, then there is no problem. I think UbiSoft has some software you will like, too.[/QUOTE]
Something I forgot to mention the first time around: [b]The problem with our posted solution is that it doesn't know if we have an active connection to steam, so it will start the approval requirement countdown even if there is no way for it to be completed. Valve would not have this issue.[/b]
You missed an important part of my reply:
[b]Your scenario involving level changes isn't relevant; authentication only happens on initial connect. Clients don't reconnect when the level changes.[/b]
[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. 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.
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!
[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.
Your solution, at best, can only verify that a client is the same client that has joined in the past. 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.
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=Gbps;24480273]You guys still think Avaster made Serenity?[/QUOTE]
He hired a coder to do it.
[QUOTE=Ideal-Hosting;24480567]He hired a coder to do it.[/QUOTE]
No what are you talking about avaster would never need to do that he coded serenity and baconbot himself.
[editline]03:30AM[/editline]
[url]http://dl.dropbox.com/u/5604666/AvasterGreenDay.mp3[/url]
[editline]03:31AM[/editline]
isn't this the voice of a professional coder
[QUOTE=CombineGuru;24480590]No what are you talking about avaster would never need to do that he coded serenity and baconbot himself.
[editline]03:30AM[/editline]
[url]http://dl.dropbox.com/u/5604666/AvasterGreenDay.mp3[/url]
[editline]03:31AM[/editline]
isn't this the voice of a professional coder[/QUOTE]
Oh dear God make it stop.
Would an old copy of serenity help anyone?
[QUOTE=nicatronTg;24481382]Would an old copy of serenity help anyone?[/QUOTE]
No. It uses the old protocol and a v15 proof of concept was sent to valve months ago complete with source code.
:/
[QUOTE=grea$emonkey;24480680]Oh dear God make it stop.[/QUOTE]
You know you love it :p
It doesn't matter, he updates it daily.
I really wish there was a way to help people and gain from it.... Sadly it seems impossible to profit from helping others....
Sorry, you need to Log In to post a reply to this thread.
