There's no reason to keep the user and password databases separate. One database should suffice, columns you would need are (feel free to change the names, e.g. password to psd, if you want):
ID: Set this to auto-increment - Int with max length 4 should suffice, it allows for 10000 users, increase the length later if necessary
User: A log-in username - Tinytext with max length 16 should be fine.
Password: The
hash of a password - Tinytext with max length 40.
Sid: A session ID relating to a user - e.g. Tinytext with max length 40.
Any other data you wish to keep can be stored as well, for example columns:
LLI: The last logged in date
Name: A user's first name
etc.
A hash function is a function which takes an input of any length, and returns a fixed-length output. Common hashes include MD5 and SHA1 (the latter is more secure). Hashes are used because they are
irreversible (easily verified with the pigeon hole theorem).
In a registration page, you should have a series of text boxes for each relevant column (i.e. username and password - plus extras you want like first name). On the page this data is submitted to, what you want to do it:
Retrieve the data using $_POST['user'], where 'password' is replaced with whatever you named it in the previous page. You need some basic checks e.g. username is between 4 and 16 characters (long usernames are annoying!), username consists only of alphanumerical characters (or something similar).
Calculate the hash of the password - e.g. $hash = sha1($_POST['password']);
INSERT INTO the SQL database the relevant data.
When you log in, (use a similar form to the registration form except only with username and password boxes), you should SELECT from the table WHERE the username and password (hash) match - if the mysql_num_rows($result) is 1 then success, else fail.
You need to set a session ID associated with the account, which will be used to authenticate the user when he visits other pages. An example could be sha1($user+date("FjYg:ia"));. You need to UPDATE the session ID value stored in the database and set the value as a cookie to the client.
When the user visits other pages, you should check whether the session ID is associated with any IDs in the database (basically logging in but checking for session ID match).
QUOTE
There's a lot of info available about creating login systems and the use of md5 in php (altough I do suggest to use javascript to use the md5-hash because this way you don't send any password in the clear).
I hope you realise how stupid this is, this less
less secure than sending passwords as plaintext. If a hacker is able to sniff the password sent, they can easily log in, yes. If it's a hash instead, they can easily spoof the request (e.g. tamper data, javascript injection, packet editor). However if there is an SQL injection vulnerability, a hacker will immediately be able to access
any account, regardless of password strength, if the hash is done locally. If the hash is done on the server, one would need to first crack the hash.
Comment/Reply (w/o sign-up)