SQL Login System
 

This is just a basic example, it may not be the most secure but it will give you an example of how to make somthing like it.
Note: Before using for the first time insert CreateTable(); directly underneath //#CLIENTSIDE and then save, once done once delete CreateTable(); from underneath //#CLIENTSIDE

Also note this does not actually do anything if you login.
But you could easily make it into a functional login.
Please bear in mind this is my first functional SQL based script, any advice/feedback is appreciated :)

Things to add:
Make it so if the account already exists it wont say "Account Created". Done!
Some sort of password encryption system. In Progress!
Make it so you cannot add two accounts by changing weather the first letter is in upper-case or not. Done!

The script is attached.

NEVER store raw passwords in databases.

Also your data isn't even escaped properly. Use format, escape, and float or int when you make queries. I.e:

temp.query = format("SELECT username FROM Users WHERE something = '%s' OR number = %s", provided_something.escape(), float(provided_number));

Passwords should be salted and hashed before inserted into the database. For that you need 3 columns:

username, password, salt

To "register" a user:
1. Generate a random salt:
temp.salt = md5(timevar2);

2. Hash the player's provided password with the salt:
temp.password = md5(salt @ provided_password @ salt);

3. Store the hashed password and salt in the database with the username.

To "login" a user:

1. Use a select statement to retrieve the username:
temp.query = format(SELECT username, password, salt
FROM Users
WHERE username = '%s', provided_username.escape());

2. Compare the hash like this:
if (user_password == md5(salt @ provided_password @ salt)) { // Success

Thanks for your feedback.
Before I release it on the server I will DEFINITELY make the passwords encrypted :)
As I said this is my first ever SQL script. sorry for the errors in it. I will post the updated version when ready.

Not encrypted, hashed. You should never be able to retrieve passwords from a database and restore them to their original form (as an interesting sidenote, Graal's support center database was leaked and resulted in 4,126 usernames, emails, and plain-text passwords being released because their passwords were recoverable (or stored as unsalted MD5 or something, not sure)).

Is it really necessary to add the salt onto the password, even when the password is hashed?

Since your storing the salt in the database anyways, if the database was compromised, they would be able to see the salt, then just take that away from the password and have the hashed password anyways.

I'm not arguing that you shouldn't use it, i'm asking why use it.

Edit: Nvm, I didn't notice you were using the salt inside the md5() hash...
However, I still dont see how this would make the login any more secure, since the salt is automatically added to the password on login attempt.
If you were trying random passwords, you would still only need to know the single password, and the salt would be added...
At least on say, a website, how would this add security? Since if a system was trying random password to break in, it wouldn't need to know the salt anyways...

Salts don't protect against brute force, they protect against rainbow tables. Salts are only useful after the database has been compromised (imagine there's a SQL injection vulnerability in your website and somebody gets a copy of your users table; even if they had the code that generated the hashes, they'd have virtually no way of recovering the passwords since rainbow tables are impractical).

Rainbow tables get very large as the length of the original phrase (salt + password + salt) increases. An MD5 rainbow table that contains all alphanumeric inputs that are 1-8 characters is 160 GB. One with inputs 1-10 alphanumeric is 396 GB; this is the largest I could easily find online. If the salt is 10 characters, and the password is 8, that's a 28 character input. That would be one huge database.

(it's worth nothing that MD5 or SHA1 and other fast algorithms aren't recommended for password storage in the real world)

in most cases within Graal, if the database is compromised than it's the fault of some staff member just looking through it.

In which case I'd be much more worried about them just intercepting the plain text of the password immediately from the client.

I've always preferred a HMAC styled approach but both have their pros/cons . In anycase, cleartext passwords are evil and even straight-hashed passwords can be reversed if it's included in a rainbow table.

Loving the fail quote.

all this nerd talk confuses me further xD

And that was a fun week.