• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Discussion "Secure" save. considered harmful.

GMWolf

aka fel666

Do NOT use ds_*_secure_* functions.


The manual claims that the functions 'encrypt' your data, however this is simply not true...
After about ten minutes of playing around with the data, as was able to 'decrypt' the data and retrieve the information rather easily.

The Manual said:
In this way you can store sensitive information, like in-app purchase details or passwords, locally in a secure way.
Please do not use these functions for that purpose.
Sensitive information can be easily retrieved from those files. Even modified to store any information.

I will be in contact with YoYoGames to see if they can remedy the situation, or at least call the functions something else, change the manual description, as well as issue a PSA to inform people not to use them.

[edit]
The files can also be modified to store any information, making they rather ill suited for IAP, and other such usages.
 
Last edited:
S

Steevo

Guest
If you show what you did to open up the stored information, this will force YYG to have to act sooner to provide a fix.

While it's not common knowledge, there is no real urgency to fix it.
 

GMWolf

aka fel666
If you show what you did to open up the stored information, this will force YYG to have to act sooner to provide a fix.

While it's not common knowledge, there is no real urgency to fix it.
I have told YYG how i did it. But i will hold off disclosing the info as this is a serious matter. Passwords could be stored that way, or worse.
 
S

Steevo

Guest
Fair enough. I guess if nothing comes of it the 'hammer' approach can be used later.
 
H

Homunculus

Guest
The real problem imho is the manual entry suggesting storing sensitive data in there. I never considered how secure this method for storing data was but to me it’s quite clear that no matter how much it gets patched up, you shouldn’t trust it for sensitive data. It is pretty neat to have though if you just want to make it difficult users to manually edit the game data.
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
The function takes no parameters thus cannot be "secure", by definition. The manual would have been best to note that it's "secure" enough for save files, not for actual secrets, but there are many things that need better writing in it.
 

Appsurd

Member
It is clear the function makes it hard but not impossible to change the user data. However, just 10 minutes of decryption time is really terrifying, for most users IAP saving should be done differently. Does anyone have a safer but not too difficult alternative in GM? I guess YoYo is not going to update the function to make it safer...
 

GMWolf

aka fel666
It is clear the function makes it hard but not impossible to change the user data. However, just 10 minutes of decryption time is really terrifying, for most users IAP saving should be done differently. Does anyone have a safer but not too difficult alternative in GM? I guess YoYo is not going to update the function to make it safer...
I should add that once the method was found, the 'decryption' time is basically instant.

I have been thinking of making a tutorial on how to improve the security of saved files.
Unfortunately, as long as you operate entirely on the users machine, it is near impossible to have a file truly secured from the machines owner.
 

Zhanghua

Member
So this function is related to the device information, one file generated by this device should not decrypt on other device.
 

GMWolf

aka fel666
So this function is related to the device information, one file generated by this device should not decrypt on other device.
so the manual claims. And its kinda true.
but its possible to tamper with the file so it will open on another device. You can also edit the contents to hold whatever data you like.
if you are using it for IAP, the user could edit the file to give themselves infinite currency.
if you are using them for sensitive information, the user could still open the file and view it.
 

TsukaYuriko

☄️
Forum Staff
Moderator
This has already been discussed in the past, and the official statement was that these functions are secure in terms of not allowing easy transfer of, for example, IAP information between different devices. They were never meant to be secure in terms of encryption and the manual does not state that data is encrypted.
 

GMWolf

aka fel666
This has already been discussed in the past, and the official statement was that these functions are secure in terms of not allowing easy transfer of, for example, IAP information between different devices.
That is the issue. The data can EASILY be transferred between devices. It can even be tampered to store ANY information. The format used has absolutely no integrity.
They were never meant to be secure in terms of encryption and the manual does not state that data is encrypted.
Oh but it does!
The file itself can have almost any extension (for example, *.dat, *.json, *.bin, etc...) and will be encrypted and stored to a safe location on the target platform.
please do not try to defend YYG on this, its a serious matter. security flaws are not to be ignored.
 

zbox

Member
GMC Elder
I think you've misunderstood the purpose of them though - any client side storage is unsafe, no matter what. YYG are absolutely completely aware of this. The type of people to break these functions are the type that can break it regardless of what you do. That's the purpose they serve.
 

GMWolf

aka fel666
I think you've misunderstood the purpose of them though - any client side storage is unsafe, no matter what. YYG are absolutely completely aware of this. The type of people to break these functions are the type that can break it regardless of what you do. That's the purpose they serve.
from the manual:
In this way you can store sensitive information, like in-app purchase details or passwords, locally in a secure way.

The type of people to break these functions are the type that can break it regardless of what you do.
Not this one, that's why i'm so concerned.

YYG are absolutely completely aware of this.
Given how this system works, I'm not sure they were fully away of how you are supposed to sign data...

Sure you can never have a truly secure system, but the least you can do is raise the bar. The current security of the system is laughable. A first year student wouldn't do it that way!
 

sylvain_l

Member
any client side storage is unsafe
like cloud is ?!? I don't feel secured by how often GAFA and co get hacked and data leaks neither. :D

honestly even if I agree with GMWolf that the wording could be better.

What are we talking about here ?

honestly, if a player is already tempering his data to get IAP without paying, not like the game creator is losing revenue, because seams that wasn't the intend of the player to buy anything from start. (but you'll have to be cautious of the risk of tempering and detect it to avoid rewarding in leaderboard, etc... those / also the risk of 3rd party selling tools to get reward in your game, etc... which sounds too easy with GM as there is even no seeds or things like that so any GM app can just decrypt the data directly)

if a 3rd party manage to steal that save file... yeh, I agree, not cool if they can access too easly some sensible player data. But honestly not sure that the right concern IAP or password for a game of the player thats the most valuable you are sure?! (hope nobody is stupidely asking player their credit card info and storing those with that^^'); because if someone manage to get that file, means player data and privacy is already 💩💩💩💩ed !
 

GMWolf

aka fel666
But honestly not sure that the right concern IAP or password for a game of the player thats the most valuable you are sure?!
people resuse passwords.
I could write an app to scrub up all the data that is 'securely' saved using GM, and probably find usernames and passwords i could use to log into emails, etc.
 

matharoo

manualman
GameMaker Dev.
The way it's explained in the manuals vs. the way it actually is, seems to be the biggest issue.
I definitely thought this would be something more secure, but it's really unclear now that wolf has cracked it in 10 minutes.

They could change the manual entry, at least.

So, if no client-side data is safe, is it better to store such info on the cloud, like on a secure database (FireBase/Mongo/etc.)?

Just asking as a novice in these matters; I've never worked with anything that requires storing sensitive and encrypted data.
 

Evanski

Raccoon Lord
Forum Staff
Moderator
I think the major flaw is the manual needs a look over and to be rewritten to make its self more clearly understood

Thatandmaybethecodeneedsworkedon :I
 

GMWolf

aka fel666
The way it's explained in the manuals vs. the way it actually is, seems to be the biggest issue.
I definitely thought this would be something more secure, but it's really unclear now that wolf has cracked it in 10 minutes.

They could change the manual entry, at least.

So, if no client-side data is safe, is it better to store such info on the cloud, like on a secure database (FireBase/Mongo/etc.)?

Just asking as a novice in these matters; I've never worked with anything that requires storing sensitive and encrypted data.
nothing is ever truly secure, but you can raise the bar.


Lets say you want to make something tamper proof:
just hash the data along with a secret key. Not if the data is changed, the hash wont match.
of course, the attacker could data mine your application, find the key, and hash things themselves. Not super secure, but already better than what we have now.

If you want to make it unreadable, encrypt it with a secret key. again, the attacker could get that key from the binaries.

Most OSes have a key store system that only allow admins to view them, so you could use that to store the key if you want to protect your application data from hackers, but not from the admin (good for things like passwords).


When it comes right down to it, nothing that happens on a users machine is safe from the user. that is because the user will always be able to see what is going on.
However, we can make things safe from other applications.

A i already mentioned, with the current secure save system, I could write an app to read all the 'secure save' files on a users machine, and find passwords, and other sensitive information, without admin privileges. (well, on desktop platforms, i think mobile, the OS will get in the way)
 
I

icuurd12b42

Guest
This has been talked about a lot, I guess it all came to light 2-3 years ago, I know it's around the time I'd been on the receiving end of a lot of flak when I added my secure ini asset which uses this...

I trusted the wording in the help...

And yes they are completely aware of it. but I am surprised the text in the help does not reflect that.

secure save is only good for one thing, prevent kids from passing along a file...

there are assets on the site that do proper encryption, made by people who figured out how bad it was....
 

Mert

Member
There are encryption functions out there that can be converted to GM really really easily since they all do the same work : mixing up things. You'll need to search this on GitHub.
Also, if you're looking for something professional, you must cowork with an external server to confirm IAPs as it is easy to process cracked purchases. There are lots of cracked apk websites out there.
 
N

NeonBits

Guest
Well, I'm far from there, but if it's as this important and it's been there since years, and the manual says this:
ds_map_secure_save
This function will save the contents of the given ds_map to a file. The file itself can have almost any extension (for example, *.dat, *.json, *.bin, etc...) and will be encrypted and stored to a safe location on the target platform. In this way you can store sensitive information, like in app purchase details or passwords, locally in a secure way. you can then re-load the ds_map using the function ds_map_secure_load().
If it can create many problems, and you have an offer that goes up to $1500 for a 12-month licence, I think a small adjustment in the manual would be the least?
 
S

Steevo

Guest
They were never meant to be secure in terms of encryption and the manual does not state that data is encrypted.
Yeah it does....

The file itself can have almost any extension (for example, *.dat, *.json, *.bin, etc...) and will be encrypted and stored to a safe location on the target platform.

[edit]
Just had a crack at it to see how hard it was to crack.

This is the result I got with decoding a single key value I just made in a new project as a test.

t}9wfowwͼko|szkw~N}]uvq{^{ "testkey": "somevalue" }
Some gibberish, followed by the key and its value. The gibberish is probably my systems GUID, but couldn't be bothered investigating as I have all of the 'encrypted' data anyway.

Yeah, pretty easy. Took about 5 mins to work out in the end.
 
Last edited by a moderator:

TsukaYuriko

☄️
Forum Staff
Moderator
Yeah it does....
The file itself can have almost any extension (for example, *.dat, *.json, *.bin, etc...) and will be encrypted and stored to a safe location on the target platform.
... I'm unsure how I missed that when I was checking the manual, but yeah, it's there. My bad.

Consider me confused why there still isn't any clarification regarding this on the manual page. Even game_save has a clear warning that the function is limited in functionality and that manual implementations should be used in favor of the default, and that's not implied to be anywhere near as secure as these functions.
 

FrostyCat

Redemption Seeker
In my opinion, this incident is partly my fault for opening an old wound. Now that it has already happened and is starting to spiral, I genuinely hope that the rest of you take NPT's caution to heart.
NPT said:
In one corner we have YYGs supplying a function that is claimed to be secure, and it was trivial for me to circumvent. Therefore GMC users should know.

In the other corner, we have individuals who do use it and it's not my place to release the technique into the wild and it's definitely not my place to jeopardise their data.
ds_map_save_secure() is a function that has been widely deployed in GMS commercial projects. While a nuclear option may look appealing, this would immediately jeopardize the code of those who implement it, and on a wider level, lead to data loss for the users of their products. Publicizing exploit info without a transitional "gag order" period is also a serious breach of protocol when it comes to security vulnerabilities.

I have reported this topic asking for moderator advice for whether to proceed in private and how. Until then, please re-read NPT's post and refrain from further destabilizing action.
 
S

Steevo

Guest
Publicizing exploit info without a transitional "gag order" period is also a serious breach of protocol when it comes to security vulnerabilities.
Four years isn't enough?


Even Nocturne states that it isn't a secure save.

It is not so much a secure save as a UNIQUE save that cannot be transferred between devices...
Given this information, it should be of no concern how the data is encoded. It is just a way of stopping people from swapping IAP's etc... between devices.

Obviously this should not be used as a way of storing personal or sensitive information, which YYG made clear in 2014 given the link FrostyCat provided.

I don't see it as an issue that people are made aware of how the data is encrypted. It is a good thing they know, they will use the function as it is intended then.

How many insecure PHP based websites do we see out there that leak personal information, because people aren't aware of how to properly use the PHP functions?
 
Last edited by a moderator:
S

Steevo

Guest
My post was edited by a moderator. Can I please enquire as to why discussing the method of obfuscation is not allowed? It has been established by two YYG employees that the functions 'weren't meant to be a generalised security measure'. Yet Moderators are trying to do some sort of a cover up.

If people are basing the security of their applications on these functions, then they are using poor coding practises and it should be demonstrated what a mistake they are making.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
My post was edited by a moderator. Can I please enquire as to why discussing the method of obfuscation is not allowed? It has been established by two YYG employees that the functions 'weren't meant to be a generalised security measure'. Yet Moderators are trying to do some sort of a cover up.
No "cover up" at all. I refer you to @FrostyCat's post above. Until there has been an official response from YYG about the function and it's use, etc... I'd rather err on the side of caution, especially given that this function is quite widely used. I'd rather not harm the majority for the gratification of the few, if you get my meaning.
 
S

Steevo

Guest
No "cover up" at all. I refer you to @FrostyCat's post above. Until there has been an official response from YYG about the function and it's use, etc... I'd rather err on the side of caution, especially given that this function is quite widely used. I'd rather not harm the majority for the gratification of the few, if you get my meaning.
I wasn't aware that @FrostyCat was a moderator or YYG representative. Perhaps their badge should be updated to reflect this. :)


However, there was an official response from YYG staff in 2014.

They were never meant to be impressively secure and they weren't meant to be a generalised security measure, just a way of preventing simple transferral of IAP state between devices and it was always my intention that they'd be a starting point to encourage people to think about security measures.

I guess their naming was too generalised and has led people to believe they're more useful/powerful than they were ever intended to be
http://gmc.yoyogames.com/index.php?s=e2ac0a8eed80ad242a02bca8289428a1&showtopic=579075#entry4635414

What other 'official' response do we need?
 

zbox

Member
GMC Elder
I think you guys are unfortunately making a bigger deal out of this than it actually is... this isn't some major exploit with a CVE number assigned - it's a poorly (or more so, not-thought-out) named and documented function that actually does serve its intended purpose - obfuscation from script kiddies.
 
S

Steevo

Guest
I think you guys are unfortunately making a bigger deal out of this than it actually is... this isn't some major exploit with a CVE number assigned - it's a poorly (or more so, not-thought-out) named and documented function that actually does serve its intended purpose - obfuscation from script kiddies.
Exactly.

So why the Mod edits removing the obfuscation technique used? IMO it is better for people to know how it works and then it is on them as to what 'secret data' they put in there, encouraging better programming practises.

With the cover up it puts the onus on YYG.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
With the cover up it puts the onus on YYG.
Would you shut up with the cover-up stuff please? There is NO cover up, and your sarcastic comments aren't really necessary. First, I was referring to @FrostyCat's post simply because it explained perfectly why your post was edited by me, which is easier than simply repeating their point, which I'll do anyway, for clarity:
ds_map_save_secure() is a function that has been widely deployed in GMS commercial projects. While a nuclear option may look appealing, this would immediately jeopardize the code of those who implement it, and on a wider level, lead to data loss for the users of their products. Publicizing exploit info without a transitional "gag order" period is also a serious breach of protocol when it comes to security vulnerabilities.
This in no way means they have moderator status, and simply means that I personally agree with this sentiment.

As for the YYG response, while, yes, this topic has been brought up before, there does seem to be a slightly misleading entry in the manual, and there also seems to be a bit of alarm over the issue (given the number of posts in this topic over such a short time). Therefor I feel it is safer to err on the side of caution (am I repeating myself here?) and before we start posting things that could affect a lot of users negatively, see what YYG have to say and give them a chance to fix the issue (if required).
 
S

Steevo

Guest
As for the YYG response, while, yes, this topic has been brought up before, there does seem to be a slightly misleading entry in the manual, and there also seems to be a bit of alarm over the issue (given the number of posts in this topic over such a short time). Therefor I feel it is safer to err on the side of caution (am I repeating myself here?) and before we start posting things that could affect a lot of users negatively, see what YYG have to say and give them a chance to fix the issue (if required).
The official response was that "[the functions] weren't meant to be a generalised security measure" (am I repeating myself here?).

there does seem to be a slightly misleading entry in the manual
Who's job is that then? You said you were going to adjust that in 2014. ;)

I would also like to note that much of this is due to my own misunderstanding of the exact nature of the function when documenting it and the docs shall be updated to reflect better the nature of the function.
2014
 

GMWolf

aka fel666
I think you guys are unfortunately making a bigger deal out of this than it actually is... this isn't some major exploit with a CVE number assigned - it's a poorly (or more so, not-thought-out) named and documented function that actually does serve its intended purpose - obfuscation from script kiddies.
This is a huge issue.
No doubt people are storing passwords that way.
As I mentioned several times already, an app could easily be written to scrub that days from game maker games and collect info like passwords.
Leaking passwords is bad, I hope you can agree.
 
S

Steevo

Guest
This is a huge issue.
No doubt people are storing passwords that way.
As I mentioned several times already, an app could easily be written to scrub that days from game maker games and collect info like passwords.
Leaking passwords is bad, I hope you can agree.
Then they are using the provided functions for the incorrect purpose.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Who's job is that then? You said you were going to adjust that in 2014. ;)
Yep, you're right! This one's on me. I obviously overlooked adding this to my task list, and for that I apologise to everybody. But now that it's been brought up again, I'll take this opportunity to check and make sure that my (and everybody else's) understanding of the function is correct by asking YYG. Then I'll update the manual and inform everybody here. :)
 
S

Steevo

Guest
Yep, you're right! This one's on me. I obviously overlooked adding this to my task list, and for that I apologise to everybody. But now that it's been brought up again, I'll take this opportunity to check and make sure that my (and everybody else's) understanding of the function is correct by asking YYG. Then I'll update the manual and inform everybody here. :)
Fairer than that, you can not be :)
 

GMWolf

aka fel666
I would really like to see the function renamed.

For two reasons:

  1. To avoid misunderstanding what the function is, and what it shod be used for.
  2. So that current projects using the function need to be edited. The developer would either need to rename their function call, making it clear to them it isn't secure, or implement a secure version.
I know YYG like to keep their versions backwards compatible. But with the jncreasinc number of GM games coming out, I think they need to consider the potential threat this vulnerability in GM games presents.
 
S

Steevo

Guest
I would really like to see the function renamed.

For two reasons:

  1. To avoid misunderstanding what the function is, and what it shod be used for.
  2. So that current projects using the function need to be edited. The developer would either need to rename their function call, making it clear to them it isn't secure, or implement a secure version.
I know YYG like to keep their versions backwards compatible. But with the jncreasinc number of GM games coming out, I think they need to consider the potential threat this vulnerability in GM games presents.
Keep in mind though that this file is local to the device. If random people have access to the local storage on your device, then decrypting a game file is the least of your worries.
 

GMWolf

aka fel666
Keep in mind though that this file is local to the device. If random people have access to the local storage on your device, then decrypting a game file is the least of your worries.
On the desktop platforms, any app, even without admin privileges, could look at those files.
I suspect that mobile devices will be fine because they do have safe storage.
 
S

Steevo

Guest
On the desktop platforms, any app, even without admin privileges, could look at those files.
I suspect that mobile devices will be fine because they do have safe storage.
Again, if you have malware pulling files from your HDD, you have a problem. And said malware would have to be running from your own logged in user profile.

Any other user would have to be running the malware with administrative privileges to gain access to your appdata directory.
 

GMWolf

aka fel666
Hmm really? I didn't know you needed admin rights to read from app data.

Regardless. It is still an issue. There is a reason why we shouldn't store passwords in plain text.
 
Top