0

I'm making my first fullout website were users can sign up and log in. Is the following cookies secure? Do I need a more specific random code for the name instead of username or password?

setcookie("username", "$username", time()+3600);
setcookie("password", "$password", time()+3600);
Mat
  • 202,337
  • 40
  • 393
  • 406
Matt
  • 159
  • 1
  • 1
  • 4
  • 1
    Do you have a specific reason for setting cookies directly instead of using php's session functions? – Sam Dufel Apr 06 '12 at 21:02
  • 1
    "Is putting a plain text password on the wire and in a file on the client secure?" - no, not really. You're not supposed to be storing the plaintext password at all, for that matter. – Mat Apr 06 '12 at 21:03
  • Stop what you are doing. use session_start() and the $_SESSION super global. – rook Apr 09 '12 at 23:10

3 Answers3

1

Someone could steal the cookie file from your users browser and gain access to his username/password, you do not want that. So you give the user some random auth-token (session id) and associate the user on the serverside with a dataset, containing login information. Php has that feature already build-in.

So you should use php's session engine instead. http://de3.php.net/manual/en/book.session.php

It also kinda handles the problem what happens if your Browser does not support Cookies.

worenga
  • 5,776
  • 2
  • 28
  • 50
  • 1
    Also, from Mat's comment, you should NEVER store the password in clear text. You should hash the password (SHA1 for example) and store the hash on the server. – Pepe Apr 06 '12 at 21:07
  • event if its salted and hashed storing a password in a cookie is never a good idea. – worenga Apr 06 '12 at 21:09
1

It should be use if users want to remember their login and password to logged them back automatically. If not use sessions.

And the password should be encoded. Never store the password that someone has typed directly! It's safe if your password is encoded, like :

md5('my_password');

With this encoding there is no way to decrypt the password because it's linked to an infinity of values.

When you compare the 2 passwords to see if there are the same do this when both password are encoded

Jerome Ansia
  • 6,854
  • 11
  • 53
  • 99
  • MD5 is considered broken and should not be used for cryptographic purposes. – Jared Ng Apr 07 '12 at 02:22
  • It's broken but it's a one way encryption so for password it's fine – Jerome Ansia Apr 08 '12 at 00:32
  • Various flaws have been demonstrated in MD5. There are so many better and readily available hash functions out there, so why on earth would you continue to use/recommend MD5? – Jared Ng Apr 08 '12 at 08:42
  • because in for password i think it's still 100% secure, but what other available hash are that easy to use in PHP? – Jerome Ansia Apr 09 '12 at 19:15
  • bcrypt is arguably one of the best ways to securely hash passwords in PHP, and is fairly easy to implement. One problem with hashes such as MD5 is that they are designed for speed, making it easier for attackers to mount an offline brute force attack. The following may be useful to you: http://stackoverflow.com/a/6337021/886994 – Jared Ng Apr 09 '12 at 22:31
  • Thanks i'll keep that in mind when i'll have to implement an account system next time then ;) – Jerome Ansia Apr 10 '12 at 14:29
0

Yes, they are secure, as they are specific to the computer/browser only. (the cookies).

Time is good, as they auto-delete after an hour.

YES, specify a more random code instead of "username" and "password" for the ID's of the cookies, such as "(nameofsite)usern" and "(nameofsite)pas", as the cookies with the names "username" and "password" may interfere with cookies already on the users computer/browser from another website.

I'm assuming you're already encoding your passwords as they are submitted.

Hugo Cornellier
  • 161
  • 2
  • 7
  • 16