Php login/registration page

[Apple Sizat]

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

[Jerry Stuckle]

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).

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[Gordon Burditt]

> Can anyone explain how i can create a registration and login page
> using PHP that doesnt use databases, sessions, or cookies?

One possible way would be to dispense with PHP and computers and
the Internet entirely, and hire grad students.

> Is there a tutorial someone can point me to or could anyone tell
> me the method. Thanks

You need to store information about registered users *somewhere*.
A database provides protection against data getting clobbered when,
say, two new users sign up at the exact same time. You could use
a flat file for this, with sufficient locking against simultaneous
updates of a flat file. If you don't understand why this is
necessary, or how to do it, you're going to get it wrong. It might
be wrong too if your OS gets it wrong. Since you asked the question
above, you're probably going to get it wrong if you try to do it
yourself. No, that's not intended as an insult. Even the pros get
it wrong sometimes.

Where do you intend to keep the information on registered users?

Unless you intend to have the session end when you click on the
login page, or requiring entering login information on *EVERY* page,
you need to be able to track which page goes with which session
somehow. Otherwise, two sessions logged in as the same user will
interfere with each other. PHP provides a way to do sessions without
cookies (a variable is added to each URL - see the PHP configuration
variable session.use_trans_sid) - but that's still sessions. This
tends to be a security hole. It appears in the browser address
bar. A user cutting and pasting a URL and posting it or sending
it to someone may give away access to their account, or cause two
users with the same session ID to interfere with each other in odd
ways (such as, for example, paying for someone else's airline
ticket with your credit card).


You could use Apache's "plain" authentication. This involves: (a)
the browser will pop up a request for a username and password when
you navigate to a protected page, and you have no control whatever
over what it looks like, (b) the browser caches this information
so the user doesn't have to enter it on every page, and (c) there
is NO "logout" function. This option is so popular I've never seen
it used on any web site actually intended for viewing by the public
(as opposed to a test site used for learning.) This doesn't solve the
problem that two users logged in with the same user name interfere
with each other. ISPs often provide this method (it comes free with
Apache), but users are normally responsible for their own web design or
have to hire someone to do it for them.

[Richard Damon]

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).

[J.O. Aho]

And session easy to hijack.

--

//Aho

[Jerry Stuckle]

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.

[Richard Damon]

He didn't SAY he couldn't store anything on the server, and it would be
a bit hard to understand a "registration page" that didn't save
something somehow on the server. He just said he couldn't (or doesn't
want to use) databases, sessions, and cookies.

Jerry had already pointed out an alternative to the Database, I was just
pointing out that it is possible to create something like a cookieless
session via other means.

[GS]

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.

[Jerry Stuckle]

And like anything else - it is insecure. Salts are not that hard to
discover, if you have both the source and the encrypted data. And even
if the salt cannot be determined, the fields in the page can be reused -
i.e. in a cURL request.

I would never recommend someone who uses such insecure techniques.

Jerry

[Denis McMahon]

On Fri, 03 Oct 2014 01:38:44 +0000, GS wrote:

> Actually you can do it with hidden fields, effectively turning a form
> into a giant cookie.

You only need one [hidden] field to pass as much data as you like, as you
can put all the data you want to pass in a serialised string form eg json.

However there are flaws:

You're exposing almost all the data to the user, including any hashes
used to verify the data is unchanged. This may present various attack
vectors.

If this is a get request, you'll hit a request string length limit fairly
quickly. This may limit the usefulness of the method.

To be honest, the exercise as set is an extremely bad one, as it is
forcing the students to use fundamentally unsafe methods. It would be
better to teach the building blocks of good secure form handling first,
and then give them exercises in form handling to complete.

It seems that the lecturer has fallen into the mistake of starting the
hands on coding before teaching the important fundamentals. A course
designed around coding websites with PHP should commence with in depth
explanations and examples of preventing security flaws, validating and
verifying input, and the mechanisms PHP provides to prevent the users
messing with the data, rather than exercises that teach coders to hand
all the data to the user to play with!

--
Denis McMahon, denismf...@gmail.com

[Matthew Carter]

While everything said so far is true, I think its all a bit
overkill for what was likely intended as a simple exercise in teaching
novice users the very basics of a registration/sign in processes (which
is something a new programmer can relate to and understand a lot more
than security considerations).

I'd think the intention of a non-database registration page would be a
page where the user fills out a form and the data posted writes to a
flat file (which is then subsequently read from for confirming a user is
registered, to access a single member only page).

Something like the following (insecure registration code follows - do
not really use this code):

<?php
function register()
{
if(empty($_POST['id']) || empty($_POST['pass']))
{
throw new Exception('Both id and pass are required fields.');
}

$file = '/tmp/user-data';

if(!file_exists($file))
{
file_put_contents($file, '');
}

$users = unserialize(file_get_contents($file));

if(isset($users[$_POST['id']]))
{
throw new Exception(
'That user name is already taken, please choose another!');
}

$users[$_POST['id']] = $_POST['pass'];
file_put_contents($file, serialize($users));

printf("Thank you for registering %s", $_POST['id']);
}

$err = '';

if(!empty($_POST))
{
try
{
register();
}
catch(Exception $e)
{
$err = $e->getMessage();
}
}
?>
<!DOCTYPE html>
<html>
<head>
<title>Registration</title>
</head>
<body>
<span style="color:red;"><?php echo $err;?></span>
<form name='reg' method='post' action=''>
User: <input type='text' value='' name='id'>
Pass: <input type='password' value='' name='pass'>
<input type='submit'>
</form>
</body>
</html>

--
Matthew Carter (m...@ahungry.com)
http://ahungry.com

[Denis McMahon]

On Fri, 03 Oct 2014 00:24:01 -0400, Matthew Carter wrote:

> I'd think the intention of a non-database registration page would be a
> page where the user fills out a form and the data posted writes to a
> flat file (which is then subsequently read from for confirming a user is
> registered, to access a single member only page).

But that flat file is a database.

This is one of the issues. You can't store registration information to
use at a future login time without holding somewhere, on the server, a
list of users. Regardless of how and where you store it on the server,
it's a database.

--
Denis McMahon, denismf...@gmail.com

[Matthew Carter]

"A database is an organized collection of data." - Wikipedia.

How literal do you take it/where do you draw the line though? Written
to disk = database? Stored in RAM = database? A collection of Pokemon
cards = a database?

In the context of software, I think 99% of the time a reference to a
"database" is a reference to a DBMS, not the literal meaning.

[Ed Mullen]

Coherent, terse, functional and likely true.

+1


--
Ed Mullen
http://edmullen.net/
Do Lipton employees take coffee breaks?

[Jerry Stuckle]

That could be true. But looking at the requirements again, it doesn't
seem ANYTHING needs to be saved. Please point to a single requirement
which stats that.

OTOH, the requirements indicate data is only to be passed via hidden
fields - which would indicate nothing saved.