Oops you’re right, I misread the warning. In the end though the use of passwords still seems a little bit questionable, you could just as easily have users select who they share their resources with (like the whitelist many games use, except a little bit more permanent). That way players can still work together and share with UserId authentication rather than passwords.
Good idea. With the thought of this, I could add a 2-step verification type of thing by using User ID authentication so whomever is logging onto the account has to verify using it. It’s better so if the databases get leaked people need to identify.
I’m not sure what you mean by having UserId as 2-step verification. What I’m trying to say is that there’s no need for Username/Password combos for your game, users can simply type in the username/UserId of others they want to share their resources with. When users join your game, they’ve already authenticated themselves by joining on that account. Using that account’s UserId is the only authentication you need.
Sorry that I’m really bad at explaining this, I’m not really sure how to put it in easy terms.
Fun fact: This game is based off of VRChat.
I’d like to use a username and password system because of it fitting how the real game goes.
Understanding what you have said, I still think using 2-step verification with the User ID is a good idea to prevent people who have database access to log in. Your ideas are good, but I’m trying to fit the game better. That is all I mean.
Not to be rude, but this REALLY isn’t a good idea.
Storing passwords as just text is possibly the worst way to store them.
Take a look:
If you are dead set on having passwords in your game, PLEASE PLEASE PLEASE atleast look up ways to secure them properly.
Seeing as you may have not read the previous replies, I am adding a new datastore which has userids for the people whom have registered accounts. Thanks for your suggestion and concern, though.
Fun fact: There are about 6 different datastores for each type. Not just one datastore holding everything.
This is really not a good idea. This will be incredibly slow and incredibly resource intensive - and I don’t see how it addresses the issue?
It somehow worked for me. I use like 6 databases in my game so I don’t think it’s gonna be that slow. Game probably won’t be that popular, anyway.
I would strongly advise against this. Aside from the reasons mentioned above, it violates Roblox’s community rules.
Community Rules. Section I, 10: Since your game asks for a username and password, it may be viewed as one of the following.
Dangerous, unethical and illegal activities. Not only do we not allow these activities, we do not allow anyone discussing them or encouraging others to discuss (or take) such actions, including:
- Hacking, phishing, flaming, exploits, cheating, spam, deceptive practices, scams;
- Misleading, sexual or racy thumbnails or other images, videos or text;
- Gambling with Robux or real money;
- Terrorism, Nazism or Neo Nazism, organized criminal activity, gangs and gang violence;
- Instructions for engaging in violent activities, including bomb- or weapon-making
- Criminal activity;
- Illegal drugs or prescription drugs without a prescription;
- The use or sale of drugs, alcohol, or tobacco by minors; and
- Blackmail or extortion.
Community Rules. Section II, 1: You are not allowed to request personally identifiable information.
- Do not ask for or collect (or allow the transfer between players in your game) any personally identifiable information (PII) . For example, you should not ask for a player’s first and last name, age, home or physical address, something that contains a person’s image or voice (such as a photograph, video or audio file), social security number, passport number (or national identity number), phone number or email address (or other forms of online contact information).
Furthermore, you should never store a password in plaintext. Instead, you should use a strong hashing algorithm and save the hash. This means that even users with access to your datastore can’t view anybodies passwords.
I think you’re using the wrong terminology.
DataStore: The database system that Roblox uses
Key: The “key” or descriptor of the data you use to access the value i.e in this case the Username
Value: What is stored associated with the key
In their defence, they do make it clear not to enter your account password - it would however be wiser to provide the user with their own password (or maybe just provide no password? I don’t understand a context where you’d need one on Roblox as the game ensures the user is authenticated)
Warning on the right of the screenshot I sent (see above.) tells you not to enter your actual roblox password or username. This is NOT a scam game if you thought that.
I think woot3 is perfectly aware of that - the problem here is that asking for any password is PII (because you don’t know if that’s their Roblox password). It’s similar to asking for an email or phone number - passwords are legally protected under data protection and specifically COPPA.
Edit: It’s 3 AM and I’m really tired, so any question I have or anything I say may be stupid.
I have implemented a hashing system so people’s passwords or usernames don’t get leaked, so now I don’t think I’m breaking that rule seeing as it is hashed in a secure way and it stores the text password inside of the hashed password name. Probably doesn’t make sense because I’m dummy tired.
Players of your game already have accounts - their Roblox accounts. As has been pointed out above, there is absolutely no need to add an extra layer of accounts on top of this. You can identify an account by the UserId of the player.
Making it “fit the real game” is an extremely strange reason to:
- Waste time and resources trying to implement a system that is redundant;
- Waste time and resources making a system that datastores are fundamentally not suited for;
- Risk users ignoring your warnings and exposing their account information (no, your hashing system is not a guarantee of security)
I encourage you to unmark the post you have marked as the solution because it offers bad advice.
This is a very bad idea… even with 2FA, or hashing, it’s still a really bad idea… someone could probably very easily break your hashing script, and since Roblox’s userbase is quite young, they would probably either forget the password, or use their real one instead. Please don’t do this, just use their Roblox account as the account, and save all data to that.
Don’t use a username and password system.
- Your playerbase consists of children. The below warning will not deter a huge number of people who play your game.
- You are on the very edge of the ToS and your game will very likely be brought down for appearing as a scam.
- You are exposing potentially valid and widely used usernames and passwords stored in your datastore to anyone with datastore access, doubly so because you’ve implemented security concepts completely incorrectly if I’m understanding you, and being able to implement a cryptographically secure algorithm without years of education is highly unlikely.
Do not attempt to mirror the account process for another game if it introduces incredible risks such as those explained to you multiple times here. That’s not being “authentic”, that’s being stupid. Users should not need access to other users’ accounts.
This won’t stop anybody:
Closing the thread because this discussion is turning circular and is veering off of the original support request.
As others have said, it is (at least) breaching the rules on handling PII and it is unwise to request and save credentials from users in this situation, since you don’t actually need this – they already have their Roblox account and you can identify users by their ID. Asking for a username + password purely for the sake of simulating the login screen of an existing game is probably not a good idea. Keep in mind that you are dealing with a relatively young audience who are likely to make the mistake of filling out their actual account details.
Please also make sure that you follow the guidelines for Scripting Support in the future as can be read here: