Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.php > #14276

Re: Php login/registration page

From GS <nomail@nospam.org.invalid>
Newsgroups comp.lang.php
Subject Re: Php login/registration page
Date 2014-10-03 01:38 +0000
Organization A noiseless patient Spider
Message-ID <XnsA3BB1AEBFA590R2D2@127.0.0.1> (permalink)
References <844d52dc-57de-48bc-8d61-ef12d7696389@googlegroups.com> <m0fjdl$64d$1@dont-email.me> <ECKWv.296304$Q61.224596@fx13.iad> <m0gr5h$b0m$1@dont-email.me>

Show all headers | View raw


Jerry Stuckle <jstucklex@attglobal.net> wrote:

> On 9/30/2014 11:33 PM, Richard Damon wrote:
>> On 9/30/14, 8:55 PM, Jerry Stuckle wrote:
>>> On 9/30/2014 7:04 PM, Apple Sizat wrote:
>>>> Can anyone explain how i can create a registration and login page
>>>> using PHP that doesnt use databases, sessions, or cookies?
>>>>
>>>> Is there a tutorial someone can point me to or could anyone tell me
>>>> the method. Thanks
>>>>
>>>
>>> You can do it not using a database (i.e. use a flat file).  But if
>>> you don't use cookies and/or sessions, the login will only be active
>>> for the current request.  It will be forgotten as soon as the PHP
>>> script ends (which is before the last data is sent to the client).
>>>
>> 
>> You could add a token to every URL link to leave the page to go to
>> the next page, that provides storage for the login information, as
>> long as the user navigates via links on your pages.
>> 
>> This could be seen as a version of a "poor mans" session
>> (implementing by hand what session code can take care of
>> automatically). 
> 
> If you aren't storing any information on the server, it has to be more
> than a token.  It must contain all of the necessary information -
> which, as J.O. indicated, makes it very easy to hijack.
> 
> You could also use hidden fields in the page to store information, but
> that has the same problem.  Additionally, since the data are coming
> from the user, they can't be trusted.
> 
> That's the whole reason sessions exist.
> 

Actually you can do it with hidden fields, effectively turning a form
into a giant cookie. What you do is include a cryptographic hash of the
field data whose integrity you want to preserve. To prevent the user
simply rehashing the fields themselves, you include a server-side salt
in the hash. Without access to the PHP source, an attacker would have to
guess not only the salt, but the hashing function and the way the
fields and salt have been combined in order to break it. You can also
customise the session by adding the user's IP address into the
mix, or a timecode if you want the session to expire after a
while. 

define('SALT', 'NaCl or something'); // salt for crypto hash
define('TIMEOUT',14400); // max time limit on form
$timestamp=time();
....
$form.='<input type="hidden" value="'.$name.'" name="name">
<input type="hidden" value="'.$id.'" name="id">
<input type="hidden" value="'.$timestamp.'" name="timestamp">
<input type="hidden" value="'.md5($timestamp.SALT.$name.$id).'"
name="check">';
 ...

if (strcmp(md5($_POST['timestamp'].SALT.$_POST['name'].$_POST['id']),
$_POST['check']) == 0) {
    	// fields are valid 
    	if time() > TIMEOUT + $_POST['timestamp'] {
    	    	// session has expired
    	}
}

In this example we can rely on the timestamp in the form: if the user
had altered it the hashcheck would have failed (in the above version we 
wouldn't know which of the hashed fields has been tampered with if the test 
failed, but that's unlikely to matter, as any tampering should lead to 
rejecting the form.) 

I only use this approach for simple forms - storing a large dataset
would be make for rather bloated forms. It does have the advantage of
not needing any server-side storage of user data though, and the user
doesn't need cookies enabled either. 

Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Php login/registration page Apple Sizat <afor6993@gmail.com> - 2014-09-30 16:04 -0700
  Re: Php login/registration page Jerry Stuckle <jstucklex@attglobal.net> - 2014-09-30 20:55 -0400
    Re: Php login/registration page Richard Damon <Richard@Damon-Family.org> - 2014-09-30 23:33 -0400
      Re: Php login/registration page "J.O. Aho" <user@example.net> - 2014-10-01 06:51 +0200
      Re: Php login/registration page Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-01 08:13 -0400
        Re: Php login/registration page Richard Damon <Richard@Damon-Family.org> - 2014-10-01 22:37 -0400
        Re: Php login/registration page GS <nomail@nospam.org.invalid> - 2014-10-03 01:38 +0000
          Re: Php login/registration page Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-02 21:43 -0400
          Re: Php login/registration page Denis McMahon <denismfmcmahon@gmail.com> - 2014-10-03 03:29 +0000
            Re: Php login/registration page Matthew Carter <m@ahungry.com> - 2014-10-03 00:24 -0400
              Re: Php login/registration page Denis McMahon <denismfmcmahon@gmail.com> - 2014-10-03 18:33 +0000
                Re: Php login/registration page Matthew Carter <m@ahungry.com> - 2014-10-03 16:16 -0400
                Re: Php login/registration page Ed Mullen <ejEVOMER@edmullen.net> - 2014-10-03 18:24 -0500
                Re: Php login/registration page Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-03 20:37 -0400
  Re: Php login/registration page Michael Vilain <vilain@NOspamcop.net> - 2014-09-30 18:38 -0700
  Re: Php login/registration page gordonb.opkrz@burditt.org (Gordon Burditt) - 2014-09-30 21:08 -0500

csiph-web