I need to stop people from looking in my code as you can mess with other peoples accounts.

The only way to stop people looking at your code is to not share it. There is no other way, as Scratch is all about learning and sharing and being able to see others code helps with that. What do you mean by “mess with other peoples accounts.”?

It allows you to see usernames and passwords

Beast907 wrote:

It allows you to see usernames and passwords

But they still can't make any changes to the accounts.

powercon5 wrote:

Beast907 wrote:

It allows you to see usernames and passwords

But they still can't make any changes to the accounts.

It doesn't show them any account passwords either. -.-

awsome_guy_360 wrote:

powercon5 wrote:

Beast907 wrote:

It allows you to see usernames and passwords

But they still can't make any changes to the accounts.

It doesn't show them any account passwords either. -.-

I would assume they meant passwords and accounts within a project. You could see them.

powercon5 wrote:

awsome_guy_360 wrote:

powercon5 wrote:

Beast907 wrote:

It allows you to see usernames and passwords

But they still can't make any changes to the accounts.

It doesn't show them any account passwords either. -.-

I would assume they meant passwords and accounts within a project. You could see them.

True true. Never thought of that. XD

If you don't want anyone to see passwords in a project then the answer is to NOT put the actual password in there!

Instead, put something else that you can use to *check* if a given password is correct.


An example would be to take each character of a given password, turn it into a number (e.g. “A”→1, “B”→2, …, “Z”→26, “0”→27, “1”→28, etc.), apply some operation(s) to the letter's corresponding number (and the operation(s) could depend on the current position of the letter in the string), and combine it with the running total so far (e.g. simplest is to add it, but you could do more complex things).

Once you've gone through all the letters of the password, it will give a final number that depends upon the password. In particular the wrong password will (nearly always) give the wrong final number. That means you now only have to *store the number* that came from the user's password, and not the actual password itself, and you can just use that user's number to check if the given password is correct.

The only thing you need to do is to ensure is that it's hard to reverse the process and figure out a password (any string of letters) that matches a given number.


Here's a (slightly too) simple example…

Let's say the password can only contain letters A-Z (to keep it simple), and that A=1, B=2, …, Z=26.

Let's say the operation to do on each letter's value is to multiply the first by 3, the second by 5, the third by 7, then the fourth by 3 again, fifth by 5, sixth by 7, etc.

Let's start with the total as the number of letters in the password, i.e. 5.
The first letter is “H”, which has value 8. Multiply by 3 gives 24, add to total gives 29.
Second letter is “E”, which has value 5. Multiply by 5 gives 25, and add to total to get 54.
Third letter is “L”, which has value 12. Multiply by 7 gives 84, and add to total to get 138.
Fourth letter is also “L”. Multiply its value of 12 by 3, and add to total: 174
Final letter is “O”. Multiply its value of 15 by 5, and add to total: 249

So, for the password “HELLO” you would instead store the value 249.


As I said, this is perhaps a little *too* simple – it might not be that hard for someone clever to write a program that could find another string of letters that would match the value 249, and so use that as the password.

But you can use your imagination and make the operations a bit more complex (for example: use larger multipliers, start the letter converter counter at something like 101 instead of one [so A=101, B=102, etc.]; also use some things from the user's username [e.g. value for each letter in their username]; add the current letter position to the multiplier; use a couple more mathematical operations; don't create just one number, but create three or four, and require that they all match, etc…)

Hope that makes sense!



Addendum…

I've made a demo project that contains a simple almost one-script hashing function that you can easily import into your own projects:


https://scratch.mit.edu/projects/164028530/

everything can be reversed engineered since there *has* to be all the information present to allow the legitimate user to decode whatever is necessary (unless you have them register a password using some out of band mechanism) but it may be possible to make the process quite difficult… one sneaky trick I have not seen done here yet is to not only encrypt keys, data, etc, but also the code used to decode it! Which could be done by writing your own interpreted language in Scratch and bootstrapping a first level of encryption of the code before using the code to decode the data.

But without private keys, *anything* can eventually be cracked by someone with enough time. There is no physical mechanism in Scratch to fully hide data. You can always get both the contents of a project and the contents of cloud variables by bypassing the Scratch system, so the attacker has total information.

G

gtoal wrote:

everything can be reversed engineered since there *has* to be all the information present to allow the legitimate user to decode whatever is necessary…

I think the word “decode” here is somewhat misleading.

There is no decoding going on in the method I described above. The whole point is that it is *one-way* – it only ever encodes.

You don't take the stored number (e.g. 249 above) and decode it to get the password “HELLO”. Instead, you only ever take the supplied password attempt, and encode it into a hash value. If it matches the stored value (249) then it's pretty likely that the string was “HELLO”. (Well, in this simplistic case, it'd be fairly easy to find other strings that give 249 – but by adding some more complexity to the algorithm, and making the hash longer, then it'd become much harder.)


You spoke of encrypting the code, but I don't see how that adds much worthwhile here. If the code has to be decrypted, that implies the information is there in the project to do that decryption (how else would it get the info to be able to decrypt it?) – in which case, it's still possible for anyone to do it simply by looking in the project and running the decryption script. It's really only a form of obfuscation (though, of course, that might successfully deter someone who can't be bothered to work through and see how the code gets decrypted), so it seems to add very little to what I outlined above.

A much simpler alternative is to (ab)use race conditions in Scratch…

Since it's really easy to write a couple of scripts in Scratch that, when run concurrently, have a net UNKNOWN effect (when viewed from within the editor), it's fairly easy to write something that cannot be reverse-engineered (without downloading and examining the JSON to see the order of the scripts & sprites).

BTW, that fact should give you pause for thought when you consider that Scratch is meant to be a simple environment to help kids learn to code…

TheLogFather wrote:

gtoal wrote:

everything can be reversed engineered since there *has* to be all the information present to allow the legitimate user to decode whatever is necessary…

I think the word “decode” here is somewhat misleading.

There is no decoding going on in the method I described above. The whole point is that it is *one-way* – it only ever encodes.

I'm quite well aware of hashes and one-way functions. We're talking about different problems. I'm talking about a program writer who wants to keep the details of their program secret so that people can run it but not read it, so they can't do things like skip past some puzzle to get to a key piece of information. So the user running the program can run the algorithm somehow, but not see the code that is implementing the algorithm. They don't have any passwords or anything, they just run the program. This is the problem which I'm saying isn't truly solvable - you can make decoding the program difficult - possibly very difficult - but not impossible, since all the information that the running program needs is available by side channels so the program can be copied. The sorts of mechanisms people have suggested in the past are things like deleting data on going in to edit mode etc - things that we know can be worked around.

The problem you are talking about is a user entering data into the cloud database which only he can get out again. That is what a password does for you.

If you're just using a one-way function to check if a user is authorized to run some part of the program, then note that the user can copy the program and the cloud data into their own project and modify it to simply bypass the check. Even things like using the username as a key can be faked by modifying the Scratch interpreter.

G

gtoal wrote:

I'm quite well aware of hashes and one-way functions.

Yeah, thought you must be.

I have to admit that I'd assumed you were talking about ‘encrypting’ the code for the scrambling process I was describing above – and that seemed a little pointless.

But I see now that you're talking about writing something that runs some form of ‘internal’ coding that plays/generates the game/level/whatever, and obfuscating that internal coding in some way. (Which is certainly possible, and would make it very tedious to try to work around and find the info needed to ‘cheat’.)

gtoal wrote:

If you're just using a one-way function to check if a user is authorized to run some part of the program, then note that the user can copy the program and the cloud data into their own project and modify it to simply bypass the check. Even things like using the username as a key can be faked by modifying the Scratch interpreter.

That's certainly true, of course, but if the game stores high-score info in the cloud then they cannot (nominally) change that data from their own modified version of the project, and I guess that's what is important here (not being able to ‘cheat’ to reach a publicly-visible status – if it's not publicly visible, then who cares…?)


Speaking of cloud, one (rather tedious) solution for all of this which comes to mind is to have the data for constructing levels of a game (positions/types/movement of enemies/platforms/prizes/etc.), be delivered from an external source, i.e. a custom cloud client.

The idea would be that each particular user's current status/level/achievements is stored by that external client, and can therefore have the appropriate level/status/stage info returned when they next start playing.

Ideally, of course, all of these data transactions would be encrypted with double-key encryption, with the keys chosen randomly for each run of the project, or even for each transaction.

That would remove any need for passwords or special codes, and keep all information about the various stages/levels of the game totally secure until you actually reach it.


…well, it would until someone posts/streams a video of themselves playing it…


BTW, I guess I should add a link to this, for the benefit of anyone looking at this topic in the future:

https://scratch.mit.edu/projects/164028530/

Maybe, you could use an encoder!