• 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.

S

Steevo

Guest
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.
No, another logged on user needs admin rights to read your appdata directory.

There is also a reason why you shouldn't store passwords using a function that shouldn't be used for storing passwords.
 

GMWolf

aka fel666
No, another logged on user needs admin rights to read your appdata directory.

There is also a reason why you shouldn't store passwords using a function that shouldn't be used for storing passwords also.
The manual suggest using it to store passwords.
So at this point it doesn't matter what the Dev did.
YYG needs to deal with the fact that's there are most certainly people out there using that function to store passwords, and other sensitive information.

@Nocturne just to make clear, I'm not blaming you. Or anyone, really. I just think this is an issue that requires attention.
 
S

Steevo

Guest
The manual suggest using it to store passwords.
So at this point it doesn't matter what the Dev did.
YYG needs to deal with the fact that's there are most certainly people out there using that function to store passwords, and other sensitive information.
Ah, fair enough. I missed that part in the manual. Yes, that's a problem then.
 
S

Steevo

Guest
Dude, I have been quoting the manual all over this topic ^^
And I have been quoting YYG's responses that it is not meant to be secure all over this topic.

Nevertheless the manual does say it will save the file to a 'secure location' on your device. Which it does,

Your personal device security is on you.

It's not the big epidemic you are making out. Someone needs to physically gain access you your device to get this file.
 

zbox

Member
GMC Elder
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.
I do agree.

Any developer who uses this function, or any function (read: ANY at all), to store passwords on the local device - is doing the wrong thing. Any dev worth their salt knows that the password should not be stored on a client, ever no matter what.

The extent of the issue is this: Someone needs to update the help file. There's nothing else to it, all this hysteria is crazy...
 
S

Steevo

Guest
Any dev worth their salt knows that the password should not be stored on a client, ever no matter what.
100% this. And what does the manual say? It stores the file locally...

So it comes back to the developer of the application using the wrong function for the purpose.

As for applications being written to scrub data and read the files from the device, that's called a 'Trojan' and is an every day risk of owning a computer.

Comes back to how well you maintain your own system.
 

Evanski

Raccoon Lord
Forum Staff
Moderator
I think we have all learned a very important word here to day, Clarification
 
N

NeonBits

Guest
Oh, please, they're working on a solution since four years; you have to keep the faith.
 

rmanthorp

GameMaker Staff
Admin
GameMaker Dev.
Thanks for bringing this to our attention. You’re correct that the manual doesn’t accurately describe the extent of the security provided by the “secure save” function, and that it overstates the protection afforded. While there is a limited degree of security provided, it’s not sufficient to protect sensitive or personal data. We have previously been clear about this when asked, or when responding to queries, but we have overlooked this in the manual, for which we apologise. We are currently making corrections to the manual and expect these changes to be reflected when 2.2.1 exits beta, which is currently scheduled for the end of November.

Cheers.
 

GMWolf

aka fel666
Thanks for bringing this to our attention. You’re correct that the manual doesn’t accurately describe the extent of the security provided by the “secure save” function, and that it overstates the protection afforded. While there is a limited degree of security provided, it’s not sufficient to protect sensitive or personal data. We have previously been clear about this when asked, or when responding to queries, but we have overlooked this in the manual, for which we apologise. We are currently making corrections to the manual and expect these changes to be reflected when 2.2.1 exits beta, which is currently scheduled for the end of November.

Cheers.
What about all projects currently using the function?
I think it would be worth publishing something to make sure people do not use the function.
 

FrostyCat

Redemption Seeker
In my honest opinion, this is a case of the left hand not doing what the right hand is doing, and more is liable to happen if engine-level developers continue to be excluded from writing the Manual.

Steevo's observation is consistent with the characteristic of a digital signature --- plaintext content accompanied by a seemingly random fragment. Now remember that ds_map_secure_save() was introduced as a response to unauthorized edits to IAP data. The point is NOT secrecy, users have nothing to gain from reading a list of what they have already purchased. The point is non-transferability and non-repudiability, neither of which anyone around here has submitted or claimed proof of an exploit.

But when people saw the term "secure", they immediately thought of a reversible cipher, which completely missed the mark. Not only is this miscommunication evident among people involved in writing the Manual, it is also evident among people on this topic. Either the developer who added ds_map_secure() didn't advise Nocturne on what kind of cryptography was employed, or Nocturne didn't understand the technical improprieties of trying to protect a password with a digital signature or a keyless reversible cipher.

While I am OK with Nocturne writing documentation for things that may show up in a tutorial for beginners and intermediates, I have doubts about Nocturne covering functionalities that are implementation-sensitive or involve non-general experience. This is where I think the developers implementing the function calls should write the documentation, or at least communicate the implementation more explicitly before letting Nocturne write it down.
 

JeffJ

Member
While I am OK with Nocturne writing documentation for things that may show up in a tutorial for beginners and intermediates, I have doubts about Nocturne covering functionalities that are implementation-sensitive or involve non-general experience. This is where I think the developers implementing the function calls should write the documentation, or at least communicate the implementation more explicitly before letting Nocturne write it down.
While I think Nocturne does a very good at writing good examples and understandable documentation, I have felt for a long time that there seems to be too much of a lack of communication between GMS developers and him. That gap would definitely benefit from being closed as much as possible.

Also, while not directly on the topic, it also doesn't help console documentation that the one person who's responsibility it is to write it doesn't even have access to the respective technologies. Just another example of the distance there is between those who develop the tech and those who documents it. It will inevitably lead to these kinds of issues (as has been the case many times in the past). I truly wish for closer contact in this regard between these two parties. Nocturne will only be able to write documentation as good as the tools, information and general circumstances he's given.
 

GMWolf

aka fel666
The point is NOT secrecy, users have nothing to gain from reading a list of what they have already purchased. The point is non-transferability and non-repudiability, neither of which anyone around here has submitted or claimed proof of an exploit.
Actually, I have. I have said that from the start in my original post.
You can EASILY change the content of the file. Even without knowing what hash algorithm is used, or what they are hashing.
 

FrostyCat

Redemption Seeker
Actually, I have. I have said that from the start in my original post.
You can EASILY change the content of the file. Even without knowing what hash algorithm is used, or what they are hashing.
But did you change the content of the file AND fool ds_map_secure_load() into buying it wholesale?
 

rmanthorp

GameMaker Staff
Admin
GameMaker Dev.
I just want to state that it's not at all fair to blame Nocture/Mark for this or question his ability to communicate with our developers. He is constantly a part of the process and when there is a failing in the documentation then more often than not it in multiple stages and does not fall on him. I'm very proud of our documentation and having it be largely down to one person is a feat.
 

DukeSoft

Member
Honestly, if people use that method and not check the actual contents of the file and just assume something is secure, I still wouldn't blame the devs that hard. If someone tells you MD5 is a secure encryption method, would you believe them and use it? Or check what it does and find that its merely a hashing algorithm?

I've seen the "_secure" features, tested them out, noticed they weren't as secure as one might think, and decided not to use it for that kind of data.. Even if you would store some data encrypted on someones machine / phone, if there's no password / authentication involved its still as secure as plain text (given the fact your decryption logic is inside your application, as is the decryption key - as YAL stated as well).

Some application getting access to your stored files for your game would also require another hack to get out of the application's sandboxing on phones. On PC's it might be a bit different, but hey, thats basically called malware. So I dont think the problem is _that_ big.

But, agreed, it is a security issue and the docs should be updated :+)
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
While I am OK with Nocturne writing documentation for things that may show up in a tutorial for beginners and intermediates, I have doubts about Nocturne covering functionalities that are implementation-sensitive or involve non-general experience. This is where I think the developers implementing the function calls should write the documentation, or at least communicate the implementation more explicitly before letting Nocturne write it down.
While I think Nocturne does a very good at writing good examples and understandable documentation, I have felt for a long time that there seems to be too much of a lack of communication between GMS developers and him. That gap would definitely benefit from being closed as much as possible.
While these concerns are valid, and there have been times in the past when poor communication or my lack of knowledge on a subject has been an issue, that is no longer the case. Since the start of GMS2 development the way things are communicated and the way the documentation is prepared has been changed and greatly improved.
 
Top