Hello, I am Minesap. And I have an idea, a cloud idea. And this is no different than other ideas, except for… alot.
So, I was thinking about usernames and passwords, and putting them on projects. And I thought to myself…
"Well, cloud lists aren't a thing. So I'll have to use cloud variables, but cloud variables only use numbers, not letters. Hmm…"
And, I came up with my idea. Enjoy.

My Big Idea:
Let's talk numbers, specifically converting characters into a string of numbers. If you don't know, each character is made up of a string of numbers, like binary, dec, and oct. So let's do the same! You convert every letter to a 2-digit number string, each character is converted into a different set of numbers, even numbers are converted into numbers. Then the numbers are posted on the cloud, and when you are logging in, it looks for a password that fits your username.


So let's all be buddies and congratulate each other's work.
If like it, say *SUPPORT* and why.
If you are so-so, say *NEUTRAL* and why.
If you don't like it, say *OPPOSE* and why.

A couple of problems:
1) Cloud numbers can only hold up to a certain number.
2) Cloud variables are public.

I *think* that they might be solved by making new cloud variables at runtime, and hashing.

This isn't really a new idea…encoding has been around for a long time, even in Scratch. It is already used by lots of cloud projects projects to store strings(including usernames) in cloud variables. Storing and looking up passwords it is pretty much the same thing as storing and looking up save data.

109Celsius wrote:

A couple of problems:
1) Cloud numbers can only hold up to a certain number.
2) Cloud variables are public.
I *think* that they might be solved by making new cloud variables at runtime, and hashing.

As for number one, you can use @TheLogFather's workaround that tricks the servers in allowing you to save infinite digits.

Number two is where this topic gets interesting, and advanced. Cloud variables are indeed public, and there is even a nice little log of who set cloud variables to what, keeping track of every change, so saving passwords to the cloud isn't secure at all. Finding a way to keep passwords secure in cloud variables is an interesting topic.

I am thinking about encryption along with @109Celsius. Encrypting passwords in the projects isn't very secure though. It can be easily cracked, especially since the key will have to be included somewhere in the project in order to do encryption and decryption. People's passwords should act as the key, because it won't be saved anywhere on the project.

Maybe when a user makes an account, instead of storing their password on the cloud, you instead store a message encrypted using their password as the key, because, if you have good encryption, figuring out the key(their password), should be very difficult. The message can be hardcoded into the project and used with every password. When a user makes an account, encrypt the message using their password as the key, and store that in the cloud variable. When a user tries to login, encrypt the message with the password they entered again, and look for a matching encrypted message in the cloud variable. If one is found, then they are indeed trying to login to an existing account with the correct password.

I think it could be even more secure if you could keep the message secret as well, which is generally situations encryption is designed to be secure in. You are encrypting the message to keep it secret in the first place, so if you give it away, it might be easier to find the key(their password). Since keeping it secret in the project isn't very secure at all(the most I see being done is obfuscation, which should not be considered secure), users could also be prompted to enter a message to encrypt. This also comes with the benefit that the sam message isn't being emcrypted over and over, but asking users to remember two things is probably not the best thing to do. Maybe use half of their password as the message and the other half as the key? I'm not sure if that is a smart idea though. You could use their username as the message, but that is no more secure than a hardcoded message because the cloud log makes it rather obvious what usernames were encrypted.

Of course, it requires a user to login to a Scratch account with the correct password in the first place, so providing a way to log into a project isn't necessary. Just store their username in the cloud variable, and use it to find their user data in other cloud variables. If you want to encrypt their user data too keep it “secure” from other people, then you would need to ask them to enter a password to decrypt and re-encrypt their user data, and check if their password is correct. You could check if it is correct by storing their encrypted username in their user data, and when you decrypt their user data, check if the decrypted username from their user data matches their actual username. This is where everything discussed above becomes relevant again.

Also, the reason I put quotes around “secure” is because encrypting the data only keeps other people from reading it. Scratch already prevents people from writing to cloud data without the project doing it. If a user manipulates network traffic or cracks the cloud data servers in order to be able to change cloud data however they like, then you can't do anything from there, since you aren't in charge of the server's security. The user will be able to change their own data to do stuff like give themselves 9001 points, but ththe encryption will still have a small benefit. Since they can't decrypt ofther people's data, all they will be able to do is screw it up. That is, if they don't also crack your project's encryption.

Znapi wrote:

This isn't really a new idea…encoding has been around for a long time, even in Scratch. It is already used by lots of cloud projects projects to store strings(including usernames) in cloud variables. Storing and looking up passwords it is pretty much the same thing as storing and looking up save data.

109Celsius wrote:

A couple of problems:
1) Cloud numbers can only hold up to a certain number.
2) Cloud variables are public.
I *think* that they might be solved by making new cloud variables at runtime, and hashing.

As for number one, you can use @TheLogFather's workaround that tricks the servers in allowing you to save infinite digits.

Number two is where this topic gets interesting, and advanced. Cloud variables are indeed public, and there is even a nice little log of who set cloud variables to what, keeping track of every change, so saving passwords to the cloud isn't secure at all. Finding a way to keep passwords secure in cloud variables is an interesting topic.

I am thinking about encryption along with @109Celsius. Encrypting passwords in the projects isn't very secure though. It can be easily cracked, especially since the key will have to be included somewhere in the project in order to do encryption and decryption. People's passwords should act as the key, because it won't be saved anywhere on the project.

Maybe when a user makes an account, instead of storing their password on the cloud, you instead store a message encrypted using their password as the key, because, if you have good encryption, figuring out the key(their password), should be very difficult. The message can be hardcoded into the project and used with every password. When a user makes an account, encrypt the message using their password as the key, and store that in the cloud variable. When a user tries to login, encrypt the message with the password they entered again, and look for a matching encrypted message in the cloud variable. If one is found, then they are indeed trying to login to an existing account with the correct password.

I think it could be even more secure if you could keep the message secret as well, which is generally situations encryption is designed to be secure in. You are encrypting the message to keep it secret in the first place, so if you give it away, it might be easier to find the key(their password). Since keeping it secret in the project isn't very secure at all(the most I see being done is obfuscation, which should not be considered secure), users could also be prompted to enter a message to encrypt. This also comes with the benefit that the sam message isn't being emcrypted over and over, but asking users to remember two things is probably not the best thing to do. Maybe use half of their password as the message and the other half as the key? I'm not sure if that is a smart idea though. You could use their username as the message, but that is no more secure than a hardcoded message because the cloud log makes it rather obvious what usernames were encrypted.

Of course, it requires a user to login to a Scratch account with the correct password in the first place, so providing a way to log into a project isn't necessary. Just store their username in the cloud variable, and use it to find their user data in other cloud variables. If you want to encrypt their user data too keep it “secure” from other people, then you would need to ask them to enter a password to decrypt and re-encrypt their user data, and check if their password is correct. You could check if it is correct by storing their encrypted username in their user data, and when you decrypt their user data, check if the decrypted username from their user data matches their actual username. This is where everything discussed above becomes relevant again.

Also, the reason I put quotes around “secure” is because encrypting the data only keeps other people from reading it. Scratch already prevents people from writing to cloud data without the project doing it. If a user manipulates network traffic or cracks the cloud data servers in order to be able to change cloud data however they like, then you can't do anything from there, since you aren't in charge of the server's security. The user will be able to change their own data to do stuff like give themselves 9001 points, but ththe encryption will still have a small benefit. Since they can't decrypt ofther people's data, all they will be able to do is screw it up. That is, if they don't also crack your project's encryption.

Ok Znapi, but I never seen someone do that is Usernames/Passwords before. Or chat rooms. Lel

Anyone who manages to implement cryptographically secure public-key encryption in Scratch cloud variables wins a cookie (I don't believe it's possible to do correctly at the moment, however)

bobbybee wrote:

Anyone who manages to implement cryptographically secure public-key encryption in Scratch cloud variables wins a cookie (I don't believe it's possible to do correctly at the moment, however)

You could encrypt a list of bad words. With the encryption, not many people could decode them by themselves.

bobbybee wrote:

Anyone who manages to implement cryptographically secure public-key encryption in Scratch cloud variables wins a cookie (I don't believe it's possible to do correctly at the moment, however)

I forgot about public key encryption. It would definitely be cool to see attempts. I don't really see where it would become necessary to keep a user's data private though, so maybe that is why no one has tried.

Well, I'm not a scratcher. Soo yeah.

I'm kinda thinking about using DealthEmito's decoder. It works with every character on a reqular keyboard.

It's a bit tricky to do, but it's not really very hard.

I made a cloud-based encrypted account+password project nearly a couple of years ago now - you could type an account name and password, and it would look to see if such an account already existed under your Scratch username. If not, it would ask if you wanted to create a new one.

Once you had an account, you could save whatever data you wanted into it - it was very basic, in that it just used ask-and-wait to get a string of data to encrypt, and added that into a linked-list-type data structure in the cloud variables.

Everything was encrypted - even the account names and associated Scratch username (actually, it used a combination of the password plus Scratch username as a key for the encryption, so you could only get at the account from the same user - and different users could potentially choose the same account names).

I didn't share it at the time, since I wasn't that happy about providing such a thing publicly - the ability to let people put encrypted data into a cloudvar could be used to transfer data privately between users, which seemed a bit dodgy to me - potentially something the ST would prefer to avoid…

TheLogFather wrote:

I didn't share it at the time, since I wasn't that happy about providing such a thing publicly - the ability to let people put encrypted data into a cloudvar could be used to transfer data privately between users, which seemed a bit dodgy to me - potentially something the ST would prefer to avoid…

I didn't think about that. Still a fun project nonetheless, even if it isn't shared. I am thinking about giving it a try.

Well, I'll have to wait another long, long week in order to test the idea.
Or I could use my old account, Gamer1991.