Developing a secure PHP login and authentication strategy

Question

I\'m developing a login and authentication system for a new PHP site and have been reading up on the various attacks and vulnerabilities. However, it\'s a bit confusing, so

Answer 1

there shouldn't be. the php session is stored on your server not the user. php simpily leaves a session cookie pointing to it. if you're not on shared hosting the session doesn't even have to be hashed.

joe

Answer 2

-use sha1 with salt -of course you must define that every form is not safe so used token for every form. That you create every form entry and sanitize it using preg_match. A process called sanitation.

Answer 3

IMHO it is also important that the session informations are changed after a success login. To save the session information in a database isn't save because of injections.

Answer 4

The scheme seems needlessly complex in a few ways, in that the added complexity doesn't gain you anything in functionality or security.

1. Any data that's sent by the browser (e.g. cookies, User-agent) is spoofable. Checking User-agent will only help when the attacker is behind the same NAT as the spoofed user and the attacker is using a different browser but doesn't think to change the User-agent.
2. Sessions store the session id client-side using either cookies or a URL query parameter. If you want to extend the life of a session, use session_set_cookie_params to keep the session cookie around longer.

The User-agent isn't secret data, so hashing it is unecessary.

The attacks that session cookie+checking remote IP won't catch are:

1. the attacker is behind the same NAT as the user
2. Blind injection attacks, where the attacker spoofs the user's IP. Despite being write-only, these can still do some damage.
3. attacks that make use of the user's own browser, such as cross-site request forgery (CSRF).

2) could be prevented if you can work out a way of sending a challenge to the user's browser, which must be responded to before completing the request, but this is tricky when you didn't write the client. With AJAX it can be done. 3) (as noted by MindStalker) can be prevented by checking the Referer header, which works because CSRF attacks don't have the ability to affect arbitrary headers, and XMLHttpRequest shouldn't allow the Referer header to be set (as per the W3C standard, though implementations might not be compliant). With iframes, it might be possible to get around a Referer check. Also, the Referer header might be blocked client-side.

Answer 5

Depends upon how safe you want to be..

Cross-site vulnerabilities: Lets say another site directs the browser to submit a form to your site that does something like posting spam (or worse) if that user is already logged on the form submission will work. You'll need to check referer and a generated hidden formID for each form to protect against this fully.

Second: If you have high to medium traffic, sessionIDs can be repeated or even guessed, I'd check against a second hand generated ID that is stored in the users cookies.

Answer 6

A few random thoughts :

1. What if I steal the cookie of one of your users (using an XSS attack by injecting some JS code in your website) ? I will then fall in case 2. and thus be able to log in. IMHO, if you want a really secure authentication, do not use "remember me"-type cookies to store user credentials.
2. If you do store the credentials in a cookie, please don't store the password in clear.
3. Checking for the HTTP_USER_AGENT is a good first step to prevent session hijacking, but maybe you could combine it with the IP address ? It is far more difficult to be on the same host than your target than to simply use the same browser.

But in any case, thanks for taking the time of thinking about a good authentication scheme. A lot of PHP developers don't.

EDIT: for the record, let me clarify a point here : there are two cookies in this discusion. One being set automatically by PHP to propagate the session ID (sometimes, we see websites putting it in the URL, eg www.example.com/page.php?sessionId=[...]), and the second one created by you in order to store the user credentials and authenticate him when the session is lost. The XSS attack applies to both, ie an attacker could either steal the session cookie and hijack the session (which has a limited lifetime), or steal the credentials cookie and authenticate later.