
- You are not logged in. | Login
December 27, 2006 9:57 am
- admin
- Administrator


Discuss article: "Password for a page. Part II."
Leave your comments here
Discussed article: "Password for a page. Part II."
April 2, 2007 8:08 am
- stp2233
- Member


Re: Discuss article: "Password for a page. Part II."
Everything is all right but how is it possible to provide ‘Forgot password’ service which all the ‘serious’ sites have and which is sent via e-mail afterwards when password is remembered with md5()?
April 2, 2007 8:32 am
- napkdd1
- Member


Re: Discuss article: "Password for a page. Part II."
I have been using newly downloaded version of IE 6.xx.xxxx for 3 weeks. Anyway cookies are switched off there on default. You should understand that it’s impossible to make user change his settings to get to your site. It will be called ‘dropping of the security level’. Some very brave users are going to submit you their Internet passwords but in the rest of cases they cannot be forced to set up dropped level. And so the sites using cookies are going to stop existing as far as the technology isn’t proper…
April 2, 2007 9:26 am
- bandlist12
- Member


Re: Discuss article: "Password for a page. Part II."
Authentication systems based on sessions usually don’t use login/password within cookie at all. Instead of this flag informing if user has logged in or not is registered in the session. At this if the session identifier’s hash is displayed in the GET-parameters and there is a possibility to catch them when session (and authentication) are active, it’s possible to enter ‘as user’ even i\without knowing his login and password. However this hash is not necessarily to appear within GET-parameters. By working cookies session ID is going to appear in the QUERY_STRING only once at the second click (if you don’t force it to appear there). At this moment only it can be caught in the proxy logs and it is possible to use session without sniffer. At this you may forbid displaying session ID within QUERY_STRING at all.
We are not going to examine listening via sniffer as far as it is easily treated with SSL. Besides that you may foresee compulsory login even for registered users if data they are going to view are of major importance.
Thus there are some solutions for increasing security of a system based on sessions. The simplest of them is obliging customers to use cookies (for the sake of their own security). As far as about 95 per cent of users have cookies switched on this drawback isn’t critical. It will be possible to catch session ID with sniffer only.
Another solution is to limit session with one address. It is worse but still effective. Lots of people can use the same proxy and watch sessions of each other. On the other hand one user can send requests from quite the different addresses if his provider uses load balancing or switched dynamically from one main to another depending on tariff scales. Thus this solution is far from being ideal.
Thus authentication based on sessions is not necessarily to be broken by means of simple copy/paste.
April 2, 2007 9:36 am
- sirburpsalot
- Member


Re: Discuss article: "Password for a page. Part II."
Tell me, please, why do you use cookies for the things like these when you have sessions? It seems to me that after appearance of sessions in PHP cookies are needed only to ‘recognize’ a customer after he returns to the site in some time.
April 2, 2007 9:41 am
- stp2233
- Member


Re: Discuss article: "Password for a page. Part II."
cookies are particular case of sessions.
Last edited by stp2233 (April 2, 2007 9:42 am)
April 2, 2007 9:49 am
- sirburpsalot
- Member


Re: Discuss article: "Password for a page. Part II."
I didn’t realize which authorization method is more secure – cookies or sessions
P.S. You say that cookies are particular case of sessions. But sessions can be used without cookies as well.
April 2, 2007 9:52 am
- stp2233
- Member


Re: Discuss article: "Password for a page. Part II."
Oops... I didn't know that
They can
April 2, 2007 9:56 am
- mambojim
- Member


Re: Discuss article: "Password for a page. Part II."
I like this article: it is short and clear (in spite of the fact that I started working with PHP not so long time ago).
With best regards
April 2, 2007 11:30 am
- SRG
- Member


Re: Discuss article: "Password for a page. Part II."
Excuse me but could you divide source into files (and indicate which part of source sould be placed in a definite file). Thanks
April 2, 2007 11:56 am
- stp2233
- Member


Re: Discuss article: "Password for a page. Part II."
I’ve discovered a lot of new things!
It’s a pity that HEADER() function is incompatible with my data base on PostgreSQL (or with my Internet Explorer)
Function header cannot be out of order due to PostgreSQL.
Why don’t you create user session with login? And not to make validation in the data base on each page but only to look if there is a ‘user’ login in the session variable or not? In order to disable insertion of user variable through form we take it from massive HTTP_SESSION_VARS[].
April 3, 2007 8:13 am
- sirburpsalot
- Member


Re: Discuss article: "Password for a page. Part II."
Postgres really has nothing to do with it… If I understood everything correctly nothing should be transmitted into browser before header function and any cookies shouldn’t be set up/cancelled as well. I.e. in your example header(Location: /file.ext); it shouldn’t work… But maybe I’m mistaken… I’m going to check it…
April 3, 2007 8:40 am
- mellis
- Member


Re: Discuss article: "Password for a page. Part II."
I have a question. I used schedule with cookies described in the previous article. I’ve added to this logout.php script which nulls all the cookies (like cookie_login, cookie_passwd). But if I push Back button after logout.php, I gain access to the previous page again although there shouldn’t be anything like this. Help me, please!
April 3, 2007 8:52 am
- stp2233
- Member


Re: Discuss article: "Password for a page. Part II."
It is treated with sending from all the closed pages header("Expires: Thu, 01 Jan 1970 00:00:01 GMT");
April 3, 2007 9:05 am
- Mr.SMart
- Member


Re: Discuss article: "Password for a page. Part II."
I make it like this:
class Session {...
function set($varname, $value) {
if (!session_is_registered($varname))
if (!session_register($varname)) return false;
$HTTP_SESSION_VARS[$varname] = $value;
return true;
}
function get($varname) {
return $HTTP_SESSION_VARS[$varname];
}...Of course, I understand that if global sessions are allowed, it is possible to write it directly (like $varname = $value and it works in this way)...
BUT I need it via $HTTP_SESSION_VARS and I don't understand why it doesn't function...
April 3, 2007 9:50 am
- SRG
- Member


Re: Discuss article: "Password for a page. Part II."
Someone wanted to know what for do you need cookieS if you have SESSION???
I'll tell you about my problem.
I have written identification on site connected via session() and it worked perfectly on my computer. But as soon as I transferred the site to the provider's server everything stopped working suddenly. I've started searching for the reason...
I have alreday received a letter from provider but there cannot be any mistakes from their side. I've checked and found out that server's configuration doesn't support Session's at all (the server is set up in the wrong way.)
I wrote a script and demonstrated to his hosting how they ~configured properly~SESSION afterwards.
But my site didn't work nevertheless. When I started SESSION testing on the testsess.php file only everything worked perfectly but as soon as I started dealing with transferring from one script to another SESSION-information disappeared.
I think the problems are caused by my net's configuration: I'm connected to a local net with inner IP:12.23.24.1 and external IP 234.23.12.2 (template) and the local one correspondingly 127.0.0.1. I can view my outer IP through mIRC program having made /whois on me.
Finally I've made everything through cookieS. I think that SESSION-technology is too young and it is used not very much. Its mechanism is going to be developed and improved.
April 3, 2007 9:56 am
- mastaweb99
- Member


Re: Discuss article: "Password for a page. Part II."
What is Request.cookies collection and what is its difference from ordinary cookies?
April 3, 2007 10:09 am
- stp2233
- Member


Re: Discuss article: "Password for a page. Part II."
These are the same cookies but in ASP.
April 3, 2007 10:22 am
- senjor_itc
- Member


Re: Discuss article: "Password for a page. Part II."
# phpMyAdmin MySQL-Dump
# version 2.3.1
# http://www.phpmyadmin.net/ (download page)
#
# Host: localhost
# Creation time: 12/4/2002, 17:50
# Server version: 3.23.52
# PHP version: 4.2.3
# Data base: `test`
# --------------------------------------------------------
#
# Table structure `user_logged`
#
CREATE TABLE user_logged (
user_id varchar(128) NOT NULL default '',
login varchar(128) NOT NULL default '',
auth int(6) NOT NULL default '0',
timeout int(6) NOT NULL default '0',
last_query int(6) NOT NULL default '0',
ip varchar(128) NOT NULL default '',
PRIMARY KEY (user_id)
) TYPE=MyISAM;
#
# Data dump of the table `user_logged`
#
INSERT INTO user_logged VALUES ('e65d67d227de6f52c52af1b18533fb1c', 'admin', 1, 3600, 1039010817, '127.0.0.5');
# --------------------------------------------------------
#
# Table structure `user_users`
#
CREATE TABLE user_users (
login varchar(128) NOT NULL default '',
passwd varchar(128) NOT NULL default '',
auth int(6) NOT NULL default '0',
PRIMARY KEY (login,login)
) TYPE=MyISAM;
#
# Data dump of the table `user_users`
#
INSERT INTO user_users VALUES ('admin', '43e9a4ab75570f5b', 1);
INSERT INTO user_users VALUES ('root', '67457e226a1a15bd', 2);


