使用cookie而不是会话存储用户名和密码错误？

Question

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?

Answer 1

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.