Author | Message | Time |
---|---|---|
Barabajagal | I'm writing a forum system in PHP and MySQL, and I'm wondering what kind of security should be used for passwords. Currently my setup is like this: All the passwords are stored as SHA256 texts. Login cookies are "Username00PASSCRYPT" (where PASSCRYPT is an XOR encryption of the password hash using the Username as a key). The login is checked by using list($user,$passcrypt) = explode("00", $text); (to split the username and passcrypt), then loading the DB stored password hash into a variable called PassHash. The PassHash variable is then encrypted by the Username as well. If PASSCRYPT is equal to the encrypted PassHash, then the login is OK. So, an account with an ID of 3 and a password of 12345 is stored in cookie form as 300aGxsZ2dqZJSVlWNkZGRllJmWlmRrZGhsmWmWlmpnlWeZaGRklWxsa2Npl5RobJVmlpSZaJRslmRqZpaUlpmWaA%3D%3D. This sort of seems breakable to me... Anyone got suggestions? Edit: Due to my shortsightedness, I'm replacing all Username stuff with Account ID... | April 14, 2007, 4:58 PM |
rabbit | If someone makes their username "0" it'll break. | April 14, 2007, 7:18 PM |
Barabajagal | Usernames must be alphanumeric strings at least 5 characters long. Passwords must be at least 5 characters. Everything's case-sensitive. I'm also wondering on how to store what users have viewed what posts... | April 14, 2007, 7:32 PM |
rabbit | 00000 then. As for what posts a person has seen, I'd probably go about it by recording the UID of each post they've viewed in an array, and then go from there. | April 14, 2007, 9:21 PM |
Barabajagal | 00000 won't happen. Like I added to the bottom of the main post, it now uses the account ID which is automatically assigned instead of the Username, and I've switched the "00" thing to "%00". Also, I'm sort of new to Databases.. how would I store an array? A LONGTEXT with commas or something? | April 14, 2007, 9:37 PM |
rabbit | Just a TEXT. You might be tempted to do the handling in PHP, but it can be done strait in the MySQL query (ie: using CONCAT() and LOCATE()), which is a bit cleaner. | April 14, 2007, 11:13 PM |
Barabajagal | K, thanks for the info. | April 14, 2007, 11:28 PM |
Ersan | This is idiotic, XOR crypting is totally unnecessary and the routines for it are far slower than md5 or sha1, also the userid and '00' is an insufficient salt as rainbow tables are compiled with numbers as well as letters... | April 16, 2007, 10:06 PM |
Barabajagal | Passwords are stored in my DB as SHA256 hashes, and that's all. The cookies stored on computers are AccountID%00Encryption (where the encryption is the password hash XORed by the Account ID). | April 16, 2007, 10:19 PM |
Ersan | Ok so storing your passwords without a salt in the database is stupid move #1, not adequately protecting passwords stored in cookies is stupid move #2. I doubt many people will care to steal your users passwords but you should do it the right way for experience... | April 16, 2007, 10:28 PM |
Barabajagal | That's why I'm asking on here... I need suggestions on how to do this securely. | April 16, 2007, 11:21 PM |
Ersan | Make a long random salt string for each user and store it in the database, then store the password as md5($salt . $password) or sha1($salt . $password . $salt) or hash('sha256', $salt . $password . $salt . $password . $password . $salt . $password) or whatever your peace of mind permits and use sessions. | April 17, 2007, 12:26 AM |
Barabajagal | Sessions... You mean cookies? | April 17, 2007, 12:32 AM |
Ersan | No, I mean server-side sessions http://www.php.net/session | April 17, 2007, 12:37 AM |
LordVader | Another method alot of forums use is to store session info in the database and instead of storing any userdata in a cookie they simply validate the cookie session info vs what is on the database to validate and start new sessions. I would do as Ersan suggested first and get familiar with php-sessions.. then work on methods to eliminate as much user data from cookies as possible, only store an identifier to help you compare the users last session data and maybe a timestamp to validate and start new sessions etc.. using encyption in the cookie info also is a good idea. Basically using cookie to store some small identifier based off session data, which is also stored in you're database and constantly updated/changing every request (timestamps, seeds etc.)... while the user is authenticated you can just keep updating the info in the cookie and database, when the user is offsite/offline their last cookie can be checked vs database to re-validate/log them in. I would also suggest looking at the various open source "multi site" login schemes, their is a push starting in the past two years to try to cut down on usernames/passwords for every site you visit, and validating logins from a central source.. the CMS drupal, and also yahoo both use mechanisms like this. Check www.phpfreaks.com (use a popup blocker), they have alot of tutorials and example code for content management and bbs/forums etc.. also their forums are really good to ask questions in. *Edited: Mostly try to stay away from storing anything directly related to "private/important" user account info in cookies if possible.. | May 3, 2007, 12:44 AM |