The other issue is that people are used to considering the risks in downloading and running a complete game, but not necessarily used to considering a save file as dangerous.
There are a lot of places that distribute, say, 100%CG-unlock saves for games, or saves with boosted stats in RPGs, and people don't generally consider them as dangerous in the same way they would a random exe. Neither would many anti-virus programs, I don't think.
[Cancelled]Dropbox Integration for Save File Synchronization
- jack_norton
- Lemma-Class Veteran
- Posts: 4084
- Joined: Mon Jul 21, 2008 5:41 pm
- Completed: Too many! See my homepage
- Projects: A lot! See www.winterwolves.com
- Tumblr: winterwolvesgames
- Contact:
Re: [Cancelled]Dropbox Integration for Save File Synchroniza
Yes after reading Spiky post I agree (I didn't think about it before).
Better play safe - those great antivirus program already flag many games .exe as virus when is totally false, imagine if someone spread a virus through Ren'Py, it would be a disaster
Better play safe - those great antivirus program already flag many games .exe as virus when is totally false, imagine if someone spread a virus through Ren'Py, it would be a disaster
- PyTom
- Ren'Py Creator
- Posts: 16093
- Joined: Mon Feb 02, 2004 10:58 am
- Completed: Moonlight Walks
- Projects: Ren'Py
- IRC Nick: renpytom
- Github: renpytom
- itch: renpytom
- Location: Kings Park, NY
- Contact:
Re: [Cancelled]Dropbox Integration for Save File Synchroniza
I've been thinking this over, trying to see if save synchronization could be made secure enough to be acceptable.
I think it should be possible to secure the save files against a malicious server operator. The way to do this would be to sign each savefile with information the server does not know, and hence can't forge.
I'm wondering if a warning - perhaps each time you load a synchronized file - would be enough to deal with the security problem. I think it would be possible to place an identifier in each save file, which we can check to see if the file was created locally. If it wasn't, we could issue the warning: "This save was not created locally. If the person or computer creating this save file is malicious, it could damage your computer. Are you sure you want to proceed?"
How is this handled for Magical Diary (and soon LLTQ)? Do those games not use Steam Cloud?
I think it should be possible to secure the save files against a malicious server operator. The way to do this would be to sign each savefile with information the server does not know, and hence can't forge.
I'm wondering if a warning - perhaps each time you load a synchronized file - would be enough to deal with the security problem. I think it would be possible to place an identifier in each save file, which we can check to see if the file was created locally. If it wasn't, we could issue the warning: "This save was not created locally. If the person or computer creating this save file is malicious, it could damage your computer. Are you sure you want to proceed?"
How is this handled for Magical Diary (and soon LLTQ)? Do those games not use Steam Cloud?
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom(When was the last time you backed up your game?)
Software > Drama • https://www.patreon.com/renpytom
Re: [Cancelled]Dropbox Integration for Save File Synchroniza
Ah I see. When I made the point about how people should already take precaution when playing a Ren'Py game, what I meant is that they would do some standard precautionary measure such as scanning for possible infection, playing only a new account with restricted access and no administrative privileges, pull off the Internet cable before starting the game, and do not store any personal information on the computer/phone. So no matter what the game does, either by itself or by loading a malicious save file, it could not possible cause any problems.
From the replies, seems like they are not as standard as I thought.
As for issue with file tampering on a server, how about you make it so that Ren'Py game will come with a new persistent variable or something. Whenever the player install a new game on multiple device, they need to input some sort of encryption key, which is stored into that persistent variable; and the player is supposed to enter the same key on all their copy of the game. When a game is saved, it automatically encrypt with that key. Then when the file is synchronized, the updated file is stored in a new location first. When the game attempt to load the save file, it check to see if a new version is available, then attempt to decrypt it, and load it. If the decryption and loading is successful, it is assumed that the file have not been tampered with (it game will probably crash if the file were tampered with, since after decryption most likely it will be full of nonsense data), in which case the game overwrite the old version.
From the replies, seems like they are not as standard as I thought.
As for issue with file tampering on a server, how about you make it so that Ren'Py game will come with a new persistent variable or something. Whenever the player install a new game on multiple device, they need to input some sort of encryption key, which is stored into that persistent variable; and the player is supposed to enter the same key on all their copy of the game. When a game is saved, it automatically encrypt with that key. Then when the file is synchronized, the updated file is stored in a new location first. When the game attempt to load the save file, it check to see if a new version is available, then attempt to decrypt it, and load it. If the decryption and loading is successful, it is assumed that the file have not been tampered with (it game will probably crash if the file were tampered with, since after decryption most likely it will be full of nonsense data), in which case the game overwrite the old version.
- papillon
- Arbiter of the Internets
- Posts: 4107
- Joined: Tue Aug 26, 2003 4:37 am
- Completed: lots; see website!
- Projects: something mysterious involving yuri, usually
- Organization: Hanako Games
- Tumblr: hanakogames
- Contact:
Re: [Cancelled]Dropbox Integration for Save File Synchroniza
We haven't actually touched the Steam Cloud, no. The only feature we've used is the achievements.If it wasn't, we could issue the warning: "This save was not created locally. If the person or computer creating this save file is malicious, it could damage your computer. Are you sure you want to proceed?"
How is this handled for Magical Diary (and soon LLTQ)? Do those games not use Steam Cloud?
I'd probably consider a warning to be sufficient but Spiky cares more about this stuff than I do and was in the middle of doing a security audit on savegames for his own reasons before stumbling over this thread, so I'll wait for him to comment.
If you play all your games on individually shielded computers that can't contact the internet, save cloud storage would be utterly useless to begin with.pull off the Internet cable before starting the game
-
- Veteran
- Posts: 253
- Joined: Fri Nov 14, 2008 7:59 pm
- Completed: Lots.
- Projects: Black Closet
- Organization: Slipshod
- Location: Behind you.
- Contact:
Re: [Cancelled]Dropbox Integration for Save File Synchroniza
Cryptographic signing would be an option, with the (big!) advantage of sticking the sanitization code in a single auditable place. The downside is that it introduces key generation/management problems, and, while it protects against a malicious server, it doesn't protect against the case where one of a player's computers has been compromised and the others are clean.PyTom wrote:I think it should be possible to secure the save files against a malicious server operator. The way to do this would be to sign each savefile with information the server does not know, and hence can't forge.
A warning every single time you load a remote-created file isn't useful for save-sync systems, because then the normal user behaviour is going to be to click the big red PROCEED button for both saves produced on their other computers and saves injected by hostile third parties. You'd want each save to come with a public key and to cache the keys, SSH-style, so the scary warning only shows when trusting a new computer. This still leaves MITM vulnerability the FIRST time you trust each computer, but that can be alleviated with out-of-band key validation.PyTom wrote:I'm wondering if a warning - perhaps each time you load a synchronized file - would be enough to deal with the security problem. I think it would be possible to place an identifier in each save file, which we can check to see if the file was created locally. If it wasn't, we could issue the warning: "This save was not created locally. If the person or computer creating this save file is malicious, it could damage your computer. Are you sure you want to proceed?"
Some of us do, but an awful lot of players play with the same account they used to buy the game and most UIs in common use are oriented towards the assumption that all your programs have access to everything on your user account. For example, Steam launches all games in the same account (and, on Linux, assumes users are willing to grant root privileges to that account), and so many Windows programs assume that all files are writable by everyone that Microsoft decided kludging per-user filesystem views into the OS was a better idea than returning 'permission denied' errors when a process tries to write something it shouldn't.Elmiwisa wrote:playing only a new account with restricted access and no administrative privileges
I like the notion of encrypting any save going over the network, but secure key generation and exchange is hard (in the sense of being a pain for players) - and, again, doesn't protect against the case where one of the computers producing saves is compromised.Elmiwisa wrote:Whenever the player install a new game on multiple device, they need to input some sort of encryption key, which is stored into that persistent variable; and the player is supposed to enter the same key on all their copy of the game. When a game is saved, it automatically encrypt with that key. Then when the file is synchronized, the updated file is stored in a new location first. When the game attempt to load the save file, it check to see if a new version is available, then attempt to decrypt it, and load it. If the decryption and loading is successful, it is assumed that the file have not been tampered with (it game will probably crash if the file were tampered with, since after decryption most likely it will be full of nonsense data), in which case the game overwrite the old version.
Saves on the local machine probably should not be encrypted - I don't like the notion of losing my saves because I forgot my encryption key, that would suck.
I'm also not sure what legal restrictions would apply to distributing open-source encryption modules in conjunction with a closed source game from our respective countries. Anything we distribute has to be export-legal from both .us and .uk.
Nom nom nom nom nom LEAVES.
Who is online
Users browsing this forum: Majestic-12 [Bot]