Is it possible to build a authentication method for user login, without the use of session or cookie variables?
yep, have them login every page request.
You theoretically could build one by using PHP's built-in Filesystem extension, but you really don't want to be storing sensitive information this way.
I suppose if you placed the plain text file outside the webroot, hashed the password and turned off error reporting (to avoid potential errors to show the location of the file) it could be ok.
If it was for a rinky-dinky site without any added potential risk for a client then maybe, but I think I'd choose a login system based on cookies/sessions in 99% of cases.
Any particular reason you're looking for an alternate method?
afaik using sessions would be the easiest way to check user bona fides. Why don't you want to use sessions?
The hash would still need to exist on the client – in a cookie. That is unless you used some other method such as ip but that would be very insecure.
- Out of curiosity, if you made usernames unique, could you not generate a password hash based on that? Not that it's any more secure (in fact it's probably less so), but would that technically
bypass the need for a cookie?
I might be wrong, but if I remember correctly, then so called "http basic authentication", which on Apache httpd is enforced by .htaccess and .htpasswd files, does not rely on cookies. Instead it instructs browser to send HTTP authentication header. See for yourself. Good advanced usage examples can be found here: AskApache - Crazy Advanced Web Development
'asks the browser to send information with requests' ....it walks like a cookie, and quacks like a cookie...
But... Is not a cookie Instead it is a HTTP header (yes I know that cookie is as well transfered in header) other than one used for cookies.
Now, I do not know why materix wants to avoid cookies. Maybe because of recent legislation changes, maybe just out of curiosity...
This is foremost a theoretical question. Sessions also create a cookie on the client. There seems to be a tendency towards, especially within the Europe Union legislation, to limit the usage of cookies, e.g. Businesses urged to prepare for EU cookie laws | IT PRO.
So therefore I was wondering, which options there are to avoid using cookies in your apps.
Using a session cookie is safe with the new EU laws. It is impossible to have any form of user authentication without them. In either case, they would have to go after every single site that uses PHP sessions if they want to go after this. My mother a few days asked me "what is a cookie?" when her bank's website told her, her browser had no cookies. I can bet it will be the same over there in the EU. This law will do nothing but confuse users. And is the wrong solution to the problem.
A session identifier cookie hardly falls into the category of personal information gathering; if such were not permitted, the apache authorization headers would be disallowed too.
Anthony's point is one that was brought up in the original news posting article (which... is somewhere on this forum, i believe... might be a different one); if the user says no you may not store any cookies, the site cannot store the information that the user has said no, and has to ask again. and again. and again.
The act of logging in is opt-in to accept this session cookie.
Not sure about the UK, but here in The Netherlands the new cookie laws being discussed deal primarily with third party cookies. Of course, you should never ask a politician what a third party cookie is
For sure, it IS possible.
Haven't heard of GET/POST parameters to pass on the session ID?
That way there definitely is NO cookie required.
Which is the same exact thing as cookies. You only are changing the semantics. But passing this stuff in the URL is a lot easier to session hijack.
No, it's not the same.
I've never seen any browser that allows one to disable specific URL parameters.
The other point is, that as parameter, the session ID is not stored at the client and resent the next time he visits the page, so there's no "tracking".
But passing this stuff in the URL is a lot easier to session hijack.
Oh c'mon, are you serious?
Security by obscurity has never been a good thing.
It's equal in which way the session ID get's transmitted - you have to verify the client anyhow, e.g. by fingerprinting so it doesn't mater if it's passed in by Cookie or URL.
Anyway, I justed wanted to point out that your statement, that cookies are required, is nonsense.
Its not obscurity. Go look up session hijacking and the issues with having a session id in the URL.
- I would reply more, short on time at the moment.