making a 2d rpg. when game starts player is prompted to enter username and password.
i’m trying to figure out the best way to store this data. I could use a text file but i was wondering would it be better to use playerprefs? and if so how would i go about doing that?
i’ve watched a few video tutorials on playerprefs. I see how to get and set variables with it just not sure how i would do it.
im also going to me making a bunch of 100x100 grid maps that im going to have to store location as well. and whats in each of those. so once again not sure the best way.
a text file would be ok for the login stuff but i know it will be too long for the map database.
thanks for your help!
I know this is old, but the accepted answer is rather dangerous (and it’s ranked highly in Google search results).
First, encrypting passwords with some_hash(“password+salt”) isn’t a secure method of hashing passwords (especially when you consider some tools are actually built to handle similar setups already). There are established functions for combining a password and a salt along with key stretching in a secure manner like Pbkdf2 that you can use.
Second, MD5 hasn’t been a particularly great choice for hashing passwords in years (well before this answer was written). MD5 checksums can be cracked incredibly fast with modern consumer hardware. Use something like Pbkdf2 with SHA-2.
Thirdly, it doesn’t mention the fact that your salt should come from truly random source (and Unity’s Random won’t cut it). Always assume that the person trying to get the password can get the source code (because in reality even obfuscation tools can’t stop someone from de-compiling your source), and don’t use a salt that is either directly mentioned in the code (even indirectly, like a timestamp or a username). Use something like System.Security.Cryptography (which also has implementations for things I mentioned above like Rfc2898DeriveBytes).
This is really a lot of work, and the honest answer is at the end of the day, you actually shouldn’t store the password. There are OS-specific APIs to store passwords that non-Unity applications are able to store passwords. You shouldn’t try to store passwords in Unity because even with all the aforementioned precautions, there’s also always a chance that on a certain platform one of the tools you’re using won’t work well enough (these are functions far removed from the “normal” realm of Unity). Even though your specific game uses the passwords locally (and even if it didn’t), expect that the passwords used are going to be the same passwords players use elsewhere, and protect them as such.
And for people working on games that are networked, consider a much secure system based on something like a “Remember Me On This Computer” function, where the server generates a “cookie” in the form of a secure random hash that the client can save. When the user logs in, the client gets and stores a cookie if they checked remember me. The next time they try to log on, instead of sending a password, they send the special cookie, and the server checks if the cookie matches the stored one. You’d change the cookie each time the user logged in, delete the cookie if the user logged in with a password, and delete the cookie after a certain time period if it hasn’t been used. Even if someone gets the cookie, the users password is secure (as long as you haven’t allowed the password to be viewable, and you shouldn’t be able to because you shouldn’t store the unhashed password on your server)
if you are just checking the password then DONT store it in plain text.
No no no bad bad bad.
Instead, you should store a hash value made from the user name, the password and a salt value.
Then when doing the login check, you do the same hash again and compare hashes.
This is why God created MD5
Done this way the following things are true:
(1) If someone gets hold of your password file, its useless as they cannot back-calculate the password from the hash without the salt.
(2) if someone gets hold of your password file AND your salt, its still a significant computational exercise to back-calculate the password.