Related
I've started learning PHP by myself, and in the beginning, I would often choose the simplest way to do a task instead of the best way. Now that I'm developing important websites that need to be 100% secure, I hit this dillema,
I'm using cookies on my main page, to store the login session. Basically, the username and the hashed password is stored in a cookie and is loaded and checked against the database any time the user visits a mustbeloggedin page. For my main page, I'm using md5. Not because I want to, but because I have to. I know that poses a great security risk for the user because a keylog attack can basically freely take his password.
On this new website, I'm gonna use sha256, so that shouldn't be an issue.
Here's my question: what other security issues does storing this kind of data in a cookie and not in a session pose?
Here's mine:
Anyone with physical access to the computer can get the user's hash and store it for later use, by manually setting his cookie.
Any infected computer does the same as the above
Data is loaded, parsed, checked every load (not a security issue but still optimization-wise, it's not very good, but I don't mind that)
Anything else?
Does the domain variable inside the cookie make it secure enough not to be read by any other site?
Edit:: I'm also reading about someone intercepting the data being sent from a client to the server. How are sessions different than this? If I store a session , can't the identifier cookie still be hijacked and used by someone else? Would also adding an ip address to the cookie, then when validating the cookie, also check the IP address and if it's different then print the login form again help?
It seems you are trying to make some improvements, but not enough really.
There should never be a need to store passwords in a cookie, session, array, or anything else.
The password should be in the database and not be taken out to chance further access to it, or manipulation of the data holder in some way.
Otherwise, your highly secured database with hashes and salts on passwords, is only as secure as the framework/scripts and variable or cookie you store the password in (which is less secure than the aforementioned DB setup)!
From your comment:
Your question and statement makes no sense, you're describing a login
page and I'm describing about how the website knows you're logged in.
The cookie has the username and the hashed password, not plain text
password
So you store Bob's password in a cookie, with hash etc.
I steal Bob's password cookie. It's hashed, so safe right?
Ok, so I (James) use it on your site. How does you site know I am James, not Bob? It cannot.
It checks the cookie I stole, and password hash/salt/whatever you do match in your checks (otherwise it wouldn't for Bob either so would be useless).
It thinks I am Bob.
So now you start to check other things, if I have another cookie, perhaps username.
I have already stolen that.
So now your site looks at my cookies, sees a username and password, checks them, and says "welcome Bob, here's your personal/sensitive details, do as you wish...".
Passwords stay in the database!
You could try checking user agent, IP, and a load of other arguably less than useful/sometimes useful things etc, but these are things you can do "as well" as password+has+salt, and at the same time not store passwords in cookies or Sessions.
If your only methods to stop a hacker from using that stolen golden password cookie (hashed or not) is to check user agent, IP, and something else that can easily be faked, then your site is not secure.
Also, anytime the user needs to do something like change their password or email address, or check their whatever sensitive data on your site, you ask them to re-type their password.
Possibly resetting their cookies/hash/hash+salt stored in the DB, but depends on scenario really.
EDIT {
Use a cookie to store the Session reference, and any sensitive data in the Session.
Again, what you should store in the session depends on what data it is, if you run your own server, or shared, etc. Shared hosting can have bad config, opening up other security issues, even extending Session security issues.
(Info is in the links below - as said in comments, reading is your friend ATM - and then some evaluating and considerations of your specific needs)
}
Here is some serious reading for you:
First, your MD5 and even SHA256 are not secure:
http://php.net/manual/en/faq.passwords.php#faq.passwords.fasthash
Hashing algorithms such as MD5, SHA1 and SHA256 are designed to be
very fast and efficient. With modern techniques and computer
equipment, it has become trivial to "brute force" the output of these
algorithms, in order to determine the original input.
Because of how quickly a modern computer can "reverse" these hashing
algorithms, many security professionals strongly suggest against their
use for password hashing.
Also read the link for that quote - the bit about how you should hash, and the bit about salts.
Also, importantly, read about how to correctly store salts and hashes. There is a LOT of BAD advice out there which is misleading to the point you end up with barely any more security than if you just used MD5.
Storing the salt in the DB with the hashed password is fine, just also use unique salts etc (it's all there in the link, about mcrypt/blowfish etc)
A must read, even if you only take bits from it (and even if you ignore the rest of my answer):
The definitive guide to form-based website authentication
Faking Session/Cookies?
More reading:
What is the best way to prevent session hijacking?
Also read about:
Session fixation; Session sidejacking; Cross-site scripting;
And again, given you stated this:
Now that I'm developing important websites that need to be 100% secure
You should really spend a lot of time reading about all these things.
Cookie/session hijacking is real, and generally simple (script kiddie stuff).
If you want to produce secure websites and applications, you really need to learn about quite a few attack methods, preventions, etc.
Best way is read the links I've given, then any "branches" which stem from that read about them too.
Eventually you'll have a larger picture of the vast range of security concerns and resolves to them.
Some takeaways for cookies.
You want to limit any sensitive information saved within as it is not secure.
Cookies are perfect for session ids which you can then use to query your database and check if it is expired, matches an ip, matches user-agent and any other security/validation checks you want to do before you route to relogin or resume session.
http://php.net/manual/en/features.cookies.php
You mentioned user authentication. Most encryption protocols can be broken by using and md5 is considered 'broken' at this point due to completeness of lookup tables with all the hashes and the slight variations between hashes.
How can I make MD5 more secure? Or is it really necessary?
Salting your hash is crucial which adds another layer of security as is additional cdn/server restrictions to block/restrict brute force attacks:
https://crackstation.net/hashing-security.htm
http://www.cs.virginia.edu/~csadmin/gen_support/brute_force.php
If one is overly paranoid you can implement two factor authentication ( expensive? ):
https://isc.sans.edu/forums/diary/Implementing+two+Factor+Authentication+on+the+Cheap/9580/
http://www.twilio.com/docs/howto/two-factor-authentication
Don't store any credentials in cookies. There is session cookie and that is enough. In your database you can create a table where you will store PHP session ID together with user id. It is enough to check user's login and password once, at the logging, to establish a session.
I was doing the same as you do: storing login, password and session id in cookies and had many problems - occasionally for unknown reasons the browser was not deleting one of those cookies, or I had problems with paths of those cookies. I had to develop very complicated methodology for assuring that those cookies are properly set and that all of them are present in a given moment - I tinkered with removing and adding those cookies manually in the browser and had to come up with new ways of preventing the problems arising from such activities, but I was always able to make up new way of breaking that down and had to come up with new mechanism for preventing that.
All of this mess stopped when I finally decided to leave only one cookie - session ID, which I authenticate before every session_start() call - you can check if such a session exists and even compare current browser footprint with previously saved one. It is then very simple to foresee bad scenarios - when somebody deletes this cookie, session is over, garbage collection will clean it up. If somebody changes it or adds fake one - you can compare it against your sessions table and not start a session. To have better control over the sessions, use session_set_save_handler functionality.
There is a lot wrong with your chosen implementation.
the username and the hashed password is stored in a cookie
Don't do that. You should consider the content of cookies insecure.
and is loaded and checked against the database any time the user visits a mustbeloggedin page
There is no need to do that at all, if you know the user is already logged in (session).
I'm using md5
Using md5 at all precludes any semblance of security.
On this new website, I'm gonna use sha256
That will make almost no difference if credentials are still stored in a cookie.
So what should you do?
When a user authenticates themselves store their user info in the session. Any time you need to check if the current visitor has already authenticated check the session data. The session's data is stored on the server - it is secure. There's no need to call the db to find out who the user is on each page load, if the user's data is stored in the session.
Do not use cookies to store user credentials, especially if you're storing the password hash as stored in the db.
Don't use md5 - and if you're "forced" to do so change it at the very first opportunity.
I would like for my users to have the capability of "Keep me logged in" when they log in to my website. At the suggestion of the top answer on this post, "Keep Me Logged In" - the best approach, I decided to hash a combination of the user's salt and password in one cookie and store the user's id (a number) in another cookie. Of course, the hash value will also be stored on a database server-side to be validated when the user returns again. The salt value I used is the same one that I used to hash the password of the user when they first register, so it is static - it doesn't change between sessions. There's a few of problems I see with this approach.
1) Is using the registration salt a good idea if it's static or should I generate a different salt each time for the cookie?
2) If someone were to gain access to the cookies and they copy them to a different computer, and then try accessing the website from that computer, theoretically, it will automatically log them in to that user's account, is this not a security issue?
3) In a scenario where some user with malicious intents were to gain access to the database, a secure website would have salted and hashed passwords making it rather difficult for the hacker to gain access into multiple accounts (if at all). But, by simply playing around with the hash and salt values and creating a cookie that matches the values they've changed on the database, they can effectively get access to any account they want, rendering the whole password-hashing process as useless. Therefore, this cookie approach I'm using now is compromising my entire database and all my users' accounts.
So my question is, how do I store a cookie in PHP with sensitive information such as a hash of the user's password without having to worry about the aforementioned issues? Surely websites like Gmail and Hotmail, who offer this "Keep me logged in" feature follow a more secure approach than what I'm doing now, so how would they do it?
Don't store the password in the cookie, hashed or not. In fact, there's no reason to store anything sensitive in the cookie. All you need to do is map a 128-bit (or larger) random id to a user account in your database, and store that id in the cookie. There is no way somebody is going to guess a valid id by remote brute force, especially if you have lock-outs in place.
If someone were to gain access to the cookies and they copy them to a different computer, and then try accessing the website from that computer, theoretically, it will automatically log them in to that user's account, is this not a security issue?
Yes. That's the downside to the feature. However, if your website detects new IP address (particularly from different countries) and requires a second step (text a code to a mobile device, etc), then you take care of this problem along with the general problem of a stolen password. (This of course doesn't help prevent local network attacks, like an insecure public wifi.)
A more convenient solution is to require the "remember me" cookie to use SSL. That way a hacker would not ever see the cookie in plain text transmission, and a local attack would probably be required. (And if such, the remember me cookie is probably the least of the user's concerns.)
they can effectively get access to any account they want, rendering the whole password-hashing process as useless.
Yes, and no. If you use the technique I described (random id) then they can only access accounts that have a "remember me" cookie. But that said, if they have access to your database, they can brute force any account they want. Even salted passwords are easy to crack locally if the password itself is weak.
Also, you can consider the "remember me" login to be a half-login. Access to purchase something, change an email address, etc, would still require a password to be entered. Doing harmless things like posting on a message board could be done without the password.
Finally, note that a PHP session cookie is nothing more than a temporary "remember me" token! So much of this applies to the concept of session hijacking. The "remember me" token simply adds a bigger window of opportunity.
So in short: don't store anything sensitive in the cookie, require SSL for the cookie, and if possible, implement multi-factor authentication ... especially for admin accounts.
Looking for a php login script. I've searched stackoverflow and have seen a lot of posts, but can anyone recommend the best method? Also, If I want to use hashing, how do you decode the password when retrieving? My iPhone app uses the same database and currently the passwords are stored in normal text (not very secure, I know).
Also, if I implement a login page that redirects to info.php, how do you stop the user from going directly to the info.php page without logging in, Session control?
Look forward to hearing your input. Thanks very much.
Bit late for my answer, but i'll post anyway and i know this doesn't directly answer the question but it is related non the less. Here are a few points about login security.
Remember Me
You are best to re-hash the hashed password, and store the rehash in the cookie used to automatically log the user in. When you rehash the password, use something specific to the browser as a seed such as the browser type. This will help prevent the cookie being stolen (via people snooping on the network traffic). This helps prevent any chance of using rainbow tables.
Sessions
Be aware of session hijacking: http://en.wikipedia.org/wiki/Session_hijacking
CSRF
Cross Site Request Forgery - Implemented after you login, but something to be aware of since it only affects logged in members: http://en.wikipedia.org/wiki/Cross-site_request_forgery
HTTPS
HTTPS should be used on the page the login request is being sent to - it does NOT have to be on the page you are typing your login details on!
Hashing
You can hash a password client side using javascript which would only server to protect members from having their passwords stolen while transfering them over the network when not using HTTPS. This is good because many people often use the same password for many sites. The disadvantages are: you can't check password length server side & they can't loggin if javascript is disabled (though you can program around that to a degree). Yahoo used to (might still do) do this years ago.
When you recieve the password on the server it is often rehashed using a seed and stored in the database. This is more secure as even if people know the hash, they still can't login! Only the original password will rehash to the same hash letting the user login.
Keyloggers
If you want to get around keyloggers (or most of them) you can do so by adding a JavaScript keypad / keyboard. The user then clicks the letters and numbers to enter their password using the mouse instead of the keyboard meaning the keylogger has a hard time logging the password.
Know Something, Has Something, Is Something
The three levels of security. Something someone knows such as a password, something someone has such as a phone (google completes these first 2 using 2 step verification), and something someone is such as a finger print. The more of these you fullfill the greater your security credentials are - by a long shot!!!
Bots
Computers sometimes try to brute force a fast login page (must be fast as if the password is incorrect and the script pauses for even just 1 second, that greatly reduces the total login attempts a bot can make. To help stop this you can either pause an incorrect login for 1 or 2 seconds (like linux does) or you can produce a capture that bots have a hard time solving after X incorrect logins (like google does).
There the main points, but i'm sure there are others.
This is a great tutorial on login system design. It covers all the major topics in an object oriented manner and is great for learning about the different considerations.
Decodable passwords are not as secure as they could be, but I've had clients insist that they be able to retrieve and change the password at will, no exceptions. So in some cases I opted to salt a base64 encoded string to store in the database, and that seems to work pretty well. A function exists to encode/decode as needed for the admin user.
Indeed, session control (and/or cookies) are the method to control access. Building it with an object oriented pattern would allow you to do that with just a line or two of code per page (or a line in a header if it's common).
My one warning is to consider if you have a common login level or need user-level permissions. It's significantly more work to decide after you've built the site that permissions-based logins are important. It can become a real monster if not planned for in the beginning.
POST to a HTTPS URL.
You never decode the hashed password. Lost passwords need another mechanism to handle.
Yes, session control. Set a flag in the session on login and check for it on the other pages.
Still under development, but secure, fast, clean, good and up-to-date:
[up to date version] https://github.com/Panique/PHP-Login
[old version's website] http://www.php-login.net
I've created this with some designer & coder help. It has been discussed in several forums and got very positive replies. All current issues can be seen on the github issue page. All code is public, free and forkable.
You don't need to decode the password, you will have to store the hashed password in your database, and when the user tries to login, you compare the stored password with the hash of the entered password.
About info.php, yes, if login succeeds you assign a variable in your session, and to test if the user is logged, you just test if that variable is assigned or not.
basically you hash your password so it cannot be retrieved for malicious purpose, the hash is stored in the database instead of the password in clear text, you only compare the 2 hash values.
your client can store the password as they want, but the web application should control at each step the session validity (store some logged in identifier in the session variables with proper expiration or something like that),
so basically you require("session_control.inc") in every "protected" page so you could check for the session validity.
The best course would be to use an MVC framework which could help in defining the logic in that case.
You can use password hashing but there is also php's crypt() function http://php.net/manual/en/function.crypt.php
They essentially do the same thing but crypt is a little neater IMO. Make sure you also get a good salt generation script so when you save the password in the database here is my password encryption function, notice this isn't that secure without the salt function
function crypt_password($password)
{
if($password){
//blowfish hashing with a salt as follows: "$2a$", a two digit cost parameter, "$", and 22 base 64
$blowfish = '$2a$10$';
//get the random bytes and makes a salt
$salt = $this->get_salt();
//append salt2 data to the password, and crypt using salt, results in a 60 char output
$crypt_pass = crypt($password,$blowfish . $salt);
//blowfish comes out as 60, check
$len = strlen($crypt_pass);
if($len == 60)
{
return $crypt_pass;
}
else {
throw new Exception('encryption failed');
return false;
}
}
else {
throw new Exception('encryption failed, missing password');
return false;
}
}
and then when you want to verify this password you simply query the database for the login email or user id then to verify its as simple as
if (crypt($input_pass, $stored_pass) == $stored_pass) {
return true;
}
I'm developing my own PHP framework. It seems all the security articles I have read use vastly different methods for user authentication than I do so I could use some help in finding security holes.
Some information that might be useful before I start. I use mod_rewrite for my MVC url's. Passwords are encrypted with 24 character salt unique to each user. mysql_real_escape_string and/or variable typecasting on everything going in, and htmlspecialchars on everything coming out.
Step-by step process:
Top of every page:
session_start();
session_regenerate_id();
If user logs in via login form, generate new random token to put in user's MySQL row. Hash is generated based on user's salt (from when they first registered) and the new token. Store the hash and plaintext username in session variables, and duplicate in cookies if 'Remember me' is checked.
On every page, check for cookies. If cookies set, copy their values into session variables. Then compare $_SESSION['name'] and $_SESSION['hash'] against MySQL database. Destroy all cookies and session variables if they don't match so they have to log in again.
If login is valid, some of the user's information from the MySQL database is stored in an array for easy access. So far, I've assumed that this array is clean so when limiting user access I refer to user.rank and deny access if it's below what's required for that page.
I've tried to test all the common attacks like XSS and CSRF, but maybe I'm just not good enough at hacking my own site! My system seems way too simple for it to actually be secure (the security code is only 100 lines long). What am I missing?
Edit: For calling functions from the controller, anything that uses anything other than SELECT queries will require $_POST data to confirm a delete, for example, in addition to the user rank requirements.
I've also spent alot of time searching for the vulnerabilities with mysql_real_escape string but I haven't found any information that is up-to-date (everything is from several years ago at least and has apparently been fixed). All I know is that the problem was something to do with encoding. If that problem still exists today, how can I avoid it?
The encrypt function I borrowed from somewhere and modified:
public function encrypt($str, $salt = NULL) {
if ($salt == NULL) $salt = substr(md5(uniqid(rand(), true)), 0, 24);
else $salt = substr($salt, 0, 24);
return $salt.sha1($salt.$str);
}
Do yourself a favour and use a standard library for hashing your passwords.
Because security tends to be a lot more complicated and with more invisible screw up possibilities than most programmers could tackle alone, using a standard library is almost always easiest and most secure (if not the only) available option.
The standard library:
Take a look at: Portable PHP password hashing framework: phpass and make sure you use the CRYPT_BLOWFISH algorithm if at all possible.
example of code using phpass (v0.2):
require('PasswordHash.php');
$pwdHasher = new PasswordHash(8, FALSE);
// $hash is what you would store in your database
$hash = $pwdHasher->HashPassword( $password );
// $hash would be the $hashed stored in your database for this user
$checked = $pwdHasher->CheckPassword($password, $hash);
if ($checked) {
echo 'password correct';
} else {
echo 'wrong credentials';
}
PHPass has been implemented in some quite well known projects:
phpBB3
WordPress 2.5+ as well as bbPress
the Drupal 7 release, (module available for Drupal 5 & 6)
others
The good thing is that you do not need to worry about the details, those details have been programmed by people with experience and reviewed by many folks on the internet.
Whatever you do if you go for the 'I'll do it myself, thank you' approach, do not use MD5 anymore. It is a nice hashing algorithm, but utterly broken for security purposes.
Currently, using crypt, with CRYPT_BLOWFISH is the best practice.
CRYPT_BLOWFISH in PHP is an implementation of the Bcrypt hash. Bcrypt is based on the Blowfish block cipher, making use of it's expensive key setup to slow the algorithm down.
For more information on password storage schemes, you could also read Jeff`s blog post about it: You're Probably Storing Passwords Incorrectly
I don't see any real prevention for CSRF attacks in there. CSRF is (from my understanding) the most commonly overlooked/screwed up vulnerability in websites. Many of the big guys have been hacked via CSRF vulnerabilities.
The current best solution to this problem is using synchronizer tokens.
You had also better be very religious about escaping/encoding user input properly. Things that are inserted into the database must be escaped, and things output back to the user have to be encoded based on their context: CSS, HTML, JavaScript, etc all have to be encoded differently.
Furthermore, you shouldn't combine SHA-1 with MD5. While SHA-1 is stronger than MD5, you are essentially weakening it by combining it with MD5. Additionally, neither of these algorithms are recommended for use in new applications. For the time being you should be using SHA-256 (it is available out-of-the-box in PHP).
By trying to over-engineer the approach you may be undermining the security.
What session handler are you using? Have you checked that session_regenerate_id() renames an existing session rather than making a copy of it? If the latter then you are creating lots of session files that are much easier to find with a random search.
How do you deal with users splitting sessions? This line of code is going to break depending on the browser and how the user splits the session.
The only place you should be using session_regenerate_id() is when you authenticate the user and when the user logs out.
mysql_real_escape_string and/or variable typecasting on everything going in
NO, no, no. This keeps coming up here.
You don't change the representation of incoming data. By all means /validate/ input, and you should always /sanitize/ output - you don't /sanitize/ input.
If user logs in via login form, generate new random token to put in user's MySQL row. Hash is generated based on user's salt (from when they first registered) and the new token. Store the hash and plaintext username in session variables,
Nothing here which improves your security
Store the hash and plaintext username in session variables, and duplicate in cookies if 'Remember me' is checked
So you store the plaintext password on the users machine! This is so not secure. If you want a remember me function, then encrypt the password and an expiry date with a salt and store that.
On every page, check for cookies. If cookies set, copy their values into session variables.
So users can manipulate any value stored in the session by returning a cookie with the same name? OK so they probably can't predict the hash so it'd be tricky to fake the user - but there are lots of other ways this could be used to compromise your system.
You've tried very hard to make your system secure - but at best all you've actually done is obfuscated the parts of your system that work properly.
C.
You may want to check the user.rank against a whitelist, to make sure that the value exists in the lookup table and is valid (active, not deleted etc), and also to force typecasting and range.
As for tokens, you will want to generate a new token for each page that expects to receive GET/POST data from a form. If a session is hijacked then a token for the session could be insufficient. Setting a shorter timeout for the session could mitigate.
Don't trust anything from a cookie right away, consider using http://php.net/manual/en/book.filter.php before stashing in the Session.
If you plan to have an admin panel for the system it's ideal to enforce password strength, manual admin login name selection (in preference to admin/password stock logins upon setup).
Blacklist the usual login names such as "a';DROP DATABASE..." and "Administrator", you know the drill.
Use least-privilege accounts when setting up your database, you don't want your visitors to be playing havoc with your tables.
"Passwords are sha1 and md5 encrypted"
Why would there be a need to use two hash functions? I guess you do it due to a lack of understanding (no offense!). You should read this article on secure password schemes (hint: use bcrypt).
with session_regenerate_id(); you'll make the "back" button in your browser unusable. But still combined with "remember me" feature it become useless.
I can't see the CSRF defence in your description
There is not a single problem with mysql_real_escape string
I have been simply writing 2 cookies, 1 containing the user ID, and the 2nd containing 1/2 the SH1 hash of the password (salted). The way it works is self-evident.
I realized that I wasnt doing this in the most secure way. Whats a better way of doing this? Preferably using a single authentication cookie.
Also, is there a point to using "hard to calculate hashes"? By that I mean, using bcrypt, or hashing each item 10,000 times with whirlpool, to make it a (relatively) slow hash function (200 ms vs less than 1 ms just plain SHA1)? I mean if someone breaches your DB and gets the hashes.... what is there left to protect, since all your data is in the same DB (Unless you have some sort of a de-centralized setup, which I dont).
use Sessions. Store the session id in the cookie, and store the state of the user on the server side (loggedIn, userId, IP).
To clarify what you need to store in the session array:
loggedIn: A boolean variable about whether the user is logged in or not. You reuse the same cookie for multiple sessions, so you remember the users username next time they come to your site, etc.
userId: The uniqe id of the user in the database. Use this to get more information on the user, like username, email etc. This too can be kept in the session array after the user logs out.
IP: To prevent someone from stealing the session id and using it, you store the IP of the user as well. This is optional, as sometimes you want to allow the user to roam (eg, stackoverflow allows me to move about with my laptop without logging me out when the IP changes).
lastPing: The timestamp the user was last seen. This can be used instead of the cookie expiration date. If you also store the lifetime of the session, then you can log the user out due to inactivity. This means that the session id cookie can be stored on the users computer for a very long time.
When the user logs out or is logged out due to inactivity, you simply set loggedIn to false. When the user logs in with the right username and password you set loggedIn to true and update the other fields (userId, IP, lifetime). When the user loads a page, you check the lastPing against the current time and the lifetime, and either update lastPing or logout the user.
The session data can either be stored in the filesystem or in a database. If stored in a database, then userId is either a foreign key to the user record, or all the data can be put in the user record.
Hashing
rehashing a value several times is not a good idea, because you reduce the security. Instead use salt, combining a static salt (name of the page for example) and the username of the user, together with the password. A hash that takes a long time isn't better than a fast hash, a hash that results in a large digest is better than a hash that results in a short digest (due to brute force). Using SHA1 should be good enough for a normal site (IE, not a bank or a secret military organization).
Currently the unique token for identifying a user is their username + 1/2 of the salted password hash. This token is static, meaning it will stay the same on each request until the user changes their password. This means if I want to impersonate a user in the system I only need to capture/intercept the token once. (Unless you're introducing entropy into the token during the creation of the hash stored in the cookie). Since most users rarely change passwords an attacker will have what amounts to a non-expiring token to access a user account.
A better solution is to use PHP's session mechanism and calling session_regenerate_id on every request to constantly update the token. Doing so makes session hijacking nearly impossible especially over an SSL connection with an IP address/range restriction.
Currently I make 0 DB calls (except
during login, or when something
changes) for logged in users. I wanted
it to remain that way... – Yegor 7
mins ago
PHP session data is stored in the filesystem by default so you won't be making additional DB calls by using the built-in session mechanism.
Also, is there a point to using "hard
to calculate hashes"? By that I mean,
using bcrypt, or hashing each item
10,000 times with whirlpool, to make
it a (relatively) slow hash function
(200 ms vs less than 1 ms just plain
SHA1)?
Hashing a string 10,000 times does not make it 10,000 times more secure than hashing it once. Hash once with a good one-way encryption like SHA1 or Whirlpool.
I mean if someone breaches your DB and gets the hashes.... what is there
left to protect, since all your data
is in the same DB (Unless you have
some sort of a de-centralized setup,
which I dont).
Salting password hashes protects them from a rainbow table attacks. Currently, it's very difficult if not impossible to crack salted passwords with a rainbow table.
If you want to implement a "remember me" functionality for your site, storing the userid in a cookie is acceptable.
You shouldn't store the password in the user's cookie. If they want to, they can save this in their browser.
Ask yourself how strict your security requirements are to determine how hard this will be or not. I use Zend_Auth & Zend_Acl to handle authentication/authorization in my php apps. If you are currently using a framework you might search it for recommended best practices. Even if you aren't using a framework you could search other sites/applications to get a feel for it. There is more to it than that though when it comes to using https for login/entire & entire logged in sessions, http only cookies, etc.
There's several ways you can do this. I'm not going to go too in depth as there's loads of literature on the subject.
First of all, it's better to use something like SHA256 to reduce the off-chance of collisions.
You should also use salting, or dual-salting with one variable salt (such as the IP -- to prevent stealing sessions). A cookie string would look like YOURSALT123.123.123.123USERNAMEPASSWORD before being hashed.
Use sessions in conjunction with your own cookies.
Depending on your security requirements, use SSL.
It all depends on how secure you need to be. A community website about lolcats has different security requirements when compared to a banking website.
this is the best way and easiest way
step1
in your login/index page enter this code
<?php if(check if username and password is correct)
{
header('location:home.php');
$_SESSION['logged']=true;
}
else
{
header('location:index.php');
}
?>
step 2 in your page you want to authenticate
<?php
if(isset($_SESSION['logged']))
{
?>
your page content here
<?php }
else
{
header('location:index.php');
?>
step3 in your logoutpage
<?php
session_start();
session_destroy();
header('Location:index.php');
?>
thats all