1

I guess that keeping the password as it is in the cookies it is unsafe. The problem is that I'm using password_hash(), and to verify the password I must have the password without the encrypt. In the login form it's easy - 

<?php
     password_verify($_POST['password'], $dbpassword);
?>

the problem is the verification using the cookies. In my config file I have the same verification as in the logging form, except that the data is coming from the cookies, and it returns false or true. But the password in the cookie is already encrypted so password_verify() won't work. So what should I do?

  • 14
    Don't store passwords in cookies. Period. – John Conde Jan 02 '14 at 15:24
  • @JohnConde so how can I verify that the user is logged in? –  Jan 02 '14 at 15:25
  • There is no way to securely store a password in a cookie; you shouldn't even need to store a password in a session – Mark Baker Jan 02 '14 at 15:25
  • It's a no-go. It's bad practice and a big security risk, don't do it. – Leonardo Jan 02 '14 at 15:25
  • 3
    Only verify the password once, use sessions to keep track of logged-in users. – jeroen Jan 02 '14 at 15:25
  • @VladGincher use Sessions, but don't store your passwords there – Leonardo Jan 02 '14 at 15:25
  • @VladGincher set a flag in cookies. Create a session with user data. Check in each page if user data is empty. If so, kill session and redirect to wherever you want. – Alfabravo Jan 02 '14 at 15:26
  • @jeroen But I want users to be auto logged in, like in Google. And doesn't someone can edit session that the server will think that he is logged in? –  Jan 02 '14 at 15:27
  • As said, store a a generated ID in cookie ( and DB ) for a limited time, to let users pre-logg on your site. – Peon Jan 02 '14 at 15:28
  • 1
    @VladGincher Don't worry about someone editing their session. The chances, that someone else will magically guess the full session id are smeller then someone guessing your password. – Peon Jan 02 '14 at 15:30
  • @Dainis Abols: Thats totally wrong. Never heard about session hijacking? Someone can steal the cookie and then he has access to your account. So compare at least the ip's. – TheNiceGuy Jan 02 '14 at 15:32
  • @Michael How much date you store inside the cookie and your db when you verify the request is totally another topic. – Peon Jan 02 '14 at 15:33
  • @DainisAbols I don't understand you. Maybe I should create a `password_hash()` to the id, username and email and then in every page I'll verify it in the cookies? No one will know how to hash the "Secret login cookie", so no one will be able to login as that user... –  Jan 02 '14 at 15:34
  • That is a long story, you can start by reading [this](http://stackoverflow.com/questions/549/the-definitive-guide-to-form-based-website-authentication). – Peon Jan 02 '14 at 15:36
  • There are ways to protect (harden...) against session hijacking, but a server-side solution is the only way to go, whether you use a standard session or store your session data in a database. Check your Google cookies, no passwords there... – jeroen Jan 02 '14 at 15:39

2 Answers2

2

Storing passwords in cookies is a serious no-go! Don't do it!

What I think you are asking, is 'how do I check if a user is logged in?'

I suggest using SESSIONS, as opposed to COOKIES.

When a user visits your website a COOKIE with a session ID is created automatically, and is transmitted on every page that is accessed.

Sessions are stored on the server.

When you do your user authentication (check the username and password exist on the database and match the details supplied) then you can set some session variables (e.g. $_SESSION['loggedin'] = true;) then when you want to check if the user is logged in, you look for this session variable (e.g.

//Check if user is logged in.
if(array_key_exists('loggedin',$_SESSION) && $_SESSION['loggedin'] === true) {
  // do something here
}

This is just a basic implementation and I strongly recommend reading some on-line resources regarding PHP security.

Richard Parnaby-King
  • 13,858
  • 11
  • 64
  • 123
  • But session is not cookie... Will it be safe if I'll create a cookie with hashed username, ip and more, and just verify it each time? –  Jan 02 '14 at 15:55
  • No, it will not be safe. If a user has malicious code on their computer that is reading cookie information, even if it is hashed, there is a possibility for a malicious user to work out what the users' details are. For this reason, no website should use cookies to store sensitive data. – Richard Parnaby-King Jan 02 '14 at 16:28
  • So how can I create the auto login option like Google and Facebook? –  Jan 02 '14 at 16:39
1

There is no way to store the password securely in a cookie. An alternative (although still not recommended) is to store it in $_SESSION instead-- it's still somewhat insecure in that a session could be hijacked or that malicious code could cause it to be sent out over the network. You shouldn't be comparing actual passwords anyway, you need to be using hashes (md5 or something more secure) with a salt.

Basically:

$db_password=get_password_hash_from_db(); /*you should store the md5(salt+password) in the db, not password*/
$salt='some_secret_constant';
if ($_POST['password']) $_SESSION['password']=md5($salt+$_POST['password']);
if ($_SESSION['password']!=$db_password) die('Wrong Password');
Joe Love
  • 4,498
  • 1
  • 17
  • 29
  • You shouldn't store passwords in the session, they have no place there. `md5 + salt` is **not strong** enough. PHP has good password hashing functions, for more information see this tutorial: http://php.net/manual/en/function.password-hash.php – Halcyon Jan 02 '14 at 17:19
  • That's covered in my answer. I answered how to do what the OP asks, and warned against doing that as well. Thanks for the link to md5 alternatives. Please note that in my example, the password is not stored in the session. – Joe Love Jan 02 '14 at 17:39