Limiting access to a website

[Peter Chant]

I'm considering setting a website up for a club. I do not plan the contents
to be for public consumption, but on the other hand I'm not going to have
anything on there that is confidential, that would cause a problem if it
went further.

The basic reason is for publicity of club events. I want to make it easy to
use. I suspect a login with a password would be too much effort for most
people. I also note that computer literacy is not a skill all of them
have, the sort of people who have not got the computer skills to be
confident to shop on Amazon.

Basically the problem is communication. Some of them read quarterly
newsletters, some of them bin them. I send the occasional email out with a
list of events, but if I do it too often some of them will start ignoring
them. I have found telephoning people individually to be very successful,
but I am not paid to do it and have a life.

However, I need to be proactive rather than take the curl up and die
approach. For those who are keen on the idea a website might help.

I suspect that security through obscurity is just to lax, a url

http://foo.bar/tbntrjvoprnio/index.html

is just pointless.

My plan is as follows:

1. Make them log in using their email address as a username. Email them
their passwords first.

2. For people who have cookies enabled, store a cookie on their computer
identifying them.

3. Use the cookies for future logins. Perhaps change the cookie at the
start of each session. Perhaps make this expire.

Alternatively, or if cookies are off, I could require a code, used for one
session only, to be used for a session. The user would enter their email
address. If it matched a list then the code would be sent to the user via
email and they could use it as a password.

Any thoughts? I do not want to make a special mail shot just to give
everyone passwords by mail. Too much effort and cost for too little
reward.



--

http://www.petezilla.co.uk

[Scott]

Re: Limiting access to a website

Peter,

You might consider having a single login for the whole club, if the data
you're hiding is not confidential. This will cut down on your coding
time a bit, and you can still use cookies to bypass the login after the
first time. I had a successful outcome doing this on a club site before.

Scott

Peter Chant wrote:[color=blue]
> I'm considering setting a website up for a club. I do not plan the contents
> to be for public consumption, but on the other hand I'm not going to have
> anything on there that is confidential, that would cause a problem if it
> went further.
>
> The basic reason is for publicity of club events. I want to make it easy to
> use. I suspect a login with a password would be too much effort for most
> people. I also note that computer literacy is not a skill all of them
> have, the sort of people who have not got the computer skills to be
> confident to shop on Amazon.
>
> Basically the problem is communication. Some of them read quarterly
> newsletters, some of them bin them. I send the occasional email out with a
> list of events, but if I do it too often some of them will start ignoring
> them. I have found telephoning people individually to be very successful,
> but I am not paid to do it and have a life.
>
> However, I need to be proactive rather than take the curl up and die
> approach. For those who are keen on the idea a website might help.
>
> I suspect that security through obscurity is just to lax, a url
>
> http://foo.bar/tbntrjvoprnio/index.html
>
> is just pointless.
>
> My plan is as follows:
>
> 1. Make them log in using their email address as a username. Email them
> their passwords first.
>
> 2. For people who have cookies enabled, store a cookie on their computer
> identifying them.
>
> 3. Use the cookies for future logins. Perhaps change the cookie at the
> start of each session. Perhaps make this expire.
>
> Alternatively, or if cookies are off, I could require a code, used for one
> session only, to be used for a session. The user would enter their email
> address. If it matched a list then the code would be sent to the user via
> email and they could use it as a password.
>
> Any thoughts? I do not want to make a special mail shot just to give
> everyone passwords by mail. Too much effort and cost for too little
> reward.
>
>
>[/color]

[irimtester@gmail.com]

Re: Limiting access to a website

Sounds like too much work to me. Both for you and the user. I have
too many passwords to remember already, and if I have to mess with
one-time codes because I don't know how to turn cookies on and off, I
would quickly lose interest in the site. Since confidentiality is not
a real issue, why not just have their email address serve as both logon
and password. Simply have them enter their email on the first page,
check it against the list that you sent email notifications to. If
they are on the list, they are in, otherwise, no access.

[Chung Leong]

Re: Limiting access to a website

Peter Chant wrote:[color=blue]
> I'm considering setting a website up for a club. I do not plan the contents
> to be for public consumption, but on the other hand I'm not going to have
> anything on there that is confidential, that would cause a problem if it
> went further.
>
> The basic reason is for publicity of club events. I want to make it easy to
> use. I suspect a login with a password would be too much effort for most
> people. I also note that computer literacy is not a skill all of them
> have, the sort of people who have not got the computer skills to be
> confident to shop on Amazon.
>
> Basically the problem is communication. Some of them read quarterly
> newsletters, some of them bin them. I send the occasional email out with a
> list of events, but if I do it too often some of them will start ignoring
> them. I have found telephoning people individually to be very successful,
> but I am not paid to do it and have a life.
>
> However, I need to be proactive rather than take the curl up and die
> approach. For those who are keen on the idea a website might help.
>
> I suspect that security through obscurity is just to lax, a url
>
> http://foo.bar/tbntrjvoprnio/index.html
>
> is just pointless.
>
> My plan is as follows:
>
> 1. Make them log in using their email address as a username. Email them
> their passwords first.
>
> 2. For people who have cookies enabled, store a cookie on their computer
> identifying them.
>
> 3. Use the cookies for future logins. Perhaps change the cookie at the
> start of each session. Perhaps make this expire.
>
> Alternatively, or if cookies are off, I could require a code, used for one
> session only, to be used for a session. The user would enter their email
> address. If it matched a list then the code would be sent to the user via
> email and they could use it as a password.
>
> Any thoughts? I do not want to make a special mail shot just to give
> everyone passwords by mail. Too much effort and cost for too little
> reward.
>
>
>
> --
> http://www.petezilla.co.uk[/color]

Well, since the information isn't confidential, why border trying to
protect it? Just have appropriate entries in your robots.txt so Google
doesn't index your site.

[Chung Leong]

Re: Limiting access to a website

Peter Chant wrote:[color=blue]
> I'm considering setting a website up for a club. I do not plan the contents
> to be for public consumption, but on the other hand I'm not going to have
> anything on there that is confidential, that would cause a problem if it
> went further.
>
> The basic reason is for publicity of club events. I want to make it easy to
> use. I suspect a login with a password would be too much effort for most
> people. I also note that computer literacy is not a skill all of them
> have, the sort of people who have not got the computer skills to be
> confident to shop on Amazon.
>
> Basically the problem is communication. Some of them read quarterly
> newsletters, some of them bin them. I send the occasional email out with a
> list of events, but if I do it too often some of them will start ignoring
> them. I have found telephoning people individually to be very successful,
> but I am not paid to do it and have a life.
>
> However, I need to be proactive rather than take the curl up and die
> approach. For those who are keen on the idea a website might help.
>
> I suspect that security through obscurity is just to lax, a url
>
> http://foo.bar/tbntrjvoprnio/index.html
>
> is just pointless.
>
> My plan is as follows:
>
> 1. Make them log in using their email address as a username. Email them
> their passwords first.
>
> 2. For people who have cookies enabled, store a cookie on their computer
> identifying them.
>
> 3. Use the cookies for future logins. Perhaps change the cookie at the
> start of each session. Perhaps make this expire.
>
> Alternatively, or if cookies are off, I could require a code, used for one
> session only, to be used for a session. The user would enter their email
> address. If it matched a list then the code would be sent to the user via
> email and they could use it as a password.
>
> Any thoughts? I do not want to make a special mail shot just to give
> everyone passwords by mail. Too much effort and cost for too little
> reward.
>
>
>
> --
> http://www.petezilla.co.uk[/color]

Well, since the information isn't confidential, why bother trying to
protect it? Just have appropriate entries in your robots.txt so Google
doesn't index your site.

[Peter Chant]

Re: Limiting access to a website

[color=blue]
> Well, since the information isn't confidential, why border trying to
> protect it? Just have appropriate entries in your robots.txt so Google
> doesn't index your site.[/color]

Well, not confidential as in credit card numbers, but not necessarily
public. Also making it not public deflects some hastle from the people who
think computers are the work of the devil and the internet doubly so. I'm
giving them less excuse to complain. Some people don't give out their
phone numbers on the basis that we'll give them to double glazing companies
and the such like! As if we'd do that. It makes it a real pain in the
arse when we have the need to contact them urgently.

I'm avoiding putting in peoples names and phone numbers (not members,
crucial contacts) but thinking of adding email addresses for contact where
possible, relayed via an alias on my machine to the real address. Either
that or a web form.

Basically if say Fred is running a competition he may not want his name and
telephone number displayed publically on the internet. Whether it is
appropriate on a private web site is a matter for debate.

Basically I want a private web site with as little fuss as possible.

--

http://www.petezilla.co.uk

[Peter Chant]

Re: Limiting access to a website

Scott wrote:
[color=blue]
> Peter,
>
> You might consider having a single login for the whole club, if the data
> you're hiding is not confidential. This will cut down on your coding
> time a bit, and you can still use cookies to bypass the login after the
> first time. I had a successful outcome doing this on a club site before.[/color]

Interesting. Glad to hear it has worked in practice. Maybe combine that
with irimtester's suggestion. I could for a bit more security use email
address and membership number, but that is more hastle for all. Just stick
with email address.

Hmm,

email address as login for first time, match against list.

Cookies for subsequent logins if enabled.

More detailed information, that is sent via the mailing list already, could
be requested via a web form and sent to the (matched) email address.

Thanks,

Pete

--

http://www.petezilla.co.uk

[Gordon Burditt]

Re: Limiting access to a website

>1. Make them log in using their email address as a username. Email them[color=blue]
>their passwords first.
>
>2. For people who have cookies enabled, store a cookie on their computer
>identifying them.
>
>3. Use the cookies for future logins. Perhaps change the cookie at the
>start of each session. Perhaps make this expire.
>
>Alternativel y, or if cookies are off, I could require a code, used for one
>session only, to be used for a session. The user would enter their email
>address. If it matched a list then the code would be sent to the user via
>email and they could use it as a password.
>
>Any thoughts? I do not want to make a special mail shot just to give
>everyone passwords by mail. Too much effort and cost for too little
>reward.[/color]

A bank uses this approach for online banking (overkill for your
purposes, but there are some lessons here):

1. Users already have usernames and passwords assigned for using online
banking. They have also already chosen an image and a title for
that image (the "site key"), and answers to some security questions.

2. User goes to the web site, enters his username, and submits the form.
3. If the computer already has the bank cookie on it for this
account, go to step 6.
4. The user is asked one of the security questions. He's also asked
if this computer is at a secure location. (home or work computer:
maybe secure. internet cafe or library: not secure).
5. The user submits the form. If the info is not correct, go to 4 for
a limited number of tries.
6. A page displays the user's site key (an image and a title for it).
If the user does not see the site key, he has been warned NOT to
enter his password as this may be a spoof site.
7. User enters his password and submits the form.
8. If the password is correct and the computer is at a secure location
(according to the user), the server puts the bank cookie on the computer.
9. The page for online banking is returned.

You probably don't want to go through the whole "site key" thing,
although if there's a chance someone might spoof your site, it could
be worthwhile. Bank spoof sites have become a serious problem.

The point here is that the presence of a cookie can be used to bypass
part of the login sequence, but *LET THE USER SAY WHETHER THE COMPUTER
IS SECURE OR NOT* before putting something on it that lets people
log in as the user. Also it lets people who don't allow cookies
at all in, but they have to go to a little extra trouble.

Perhaps you could allow someone in with the cookie *OR* a password,
but let them ask for the cookie (or not).

Gordon L. Burditt

[Chung Leong]

Re: Limiting access to a website


Peter Chant wrote:[color=blue]
> Well, not confidential as in credit card numbers, but not necessarily
> public. Also making it not public deflects some hastle from the people who
> think computers are the work of the devil and the internet doubly so. I'm
> giving them less excuse to complain. Some people don't give out their
> phone numbers on the basis that we'll give them to double glazing companies
> and the such like! As if we'd do that. It makes it a real pain in the
> arse when we have the need to contact them urgently.[/color]

Just because a site isn't password-protected doesn't make it "public."
If a site isn't indiced by a search engine, then it's private enough.
It's sort of like keeping your phone number off the telephone book.

My basic point is that people in general don't seek out information
that they don't need. If secrecy isn't required, then it seems
counterproducti ve to put up a barrier.

[MsKitty]

Re: Limiting access to a website

Another easy to implement option I have used for a club site is to have
the sensitive stuff (peoples emails, message board) behind one username
and password where i can tell them the username and password on the
login page in language only a club member would get.

For example, The username is the coach's nickname and the password is
the name of his dog.

Kitty

http://www.openskywebdesign.com

[Peter Fox]

Re: Limiting access to a website

Following on from Peter Chant's message. . .[color=blue]
>I'm considering setting a website up for a club. I do not plan the contents
>to be for public consumption, but on the other hand I'm not going to have
>anything on there that is confidential, that would cause a problem if it
>went further.[/color]

I've just read the 10 or so messages in this thread and here is my
different suggestion.

* You might find it extremely useful to identify (with reasonable
confidence short of definite) who is accessing the site either for
statistics or general policing. eg What do you do if somebody leaves
the club? So one ID per person sounds a good idea.

* You already have some sort of ID system in your membership list. Ie.
some unique tag that you control and doesn't change at the whim of the
member (eg email address can change but club membership number is
fixed.)

* If you email people their access 'code' then that's a reasonably
private thing. The problem you are majoring on is getting people to
type in 'their membership number' [For purposes of discussion I'll
ignore spoofing considerations of using a membership number - you
wouldn't use that.] All you do is email them an address such as
<http://myclub.co.uk/members.php?Mbr No=12345> which is different for
each member.

Your 'index.htm' page is for non-members with a bit linking to how to
access members area (including what if you are a member but unexpectedly
here.)

members.php redirects duff $_GET['MbrNo'] values to the front page.

Your joining instructions go as follows:
1. Go to myclub.co.uk and click on 'I am a member'
2. Enter your name, number, email address and street name
The system then sends you an email informing you how to access the
member's area.
(You log the information for the benefit of the membership sec who can
check street names. The access code is some hash or random number.)
3. Go to the web page indicated in the email AND BOOKMARK IT.
(You might also attempt to set a cookie, that can be fallen back on if
the user goes direct to the main page.)

Can you see what's happened? The access key is in the bookmark and
doesn't rely on cookies or memorising passwords or any typing in.

When a page is accessed with ?MbrNo=12345 you should start it with
"Hello Charlie Smith" just so _everyone knows_ the system has identified
them. If Bots get to index.htm then that's great 'cos you presumably
want to let non-members know of your Good Works. But make sure there is
no link between index.htm and members.php (even if members.php is botted
all that happens is a redirect to index.htm 'cos no bot will know the
?MbrNo bits required.


--
PETER FOX Not the same since the borehole business dried up
peterfox@eminen t.demon.co.uk.n ot.this.bit.no. html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.dem on.co.uk>

[Rafe Culpin]

Re: Limiting access to a website

In article <1141956510.336 629.101880@z34g 2000cwc.googleg roups.com>,
chernyshevsky@h otmail.com (Chung Leong) wrote:
[color=blue]
> Just because a site isn't password-protected doesn't make it "public."
> If a site isn't indiced by a search engine, then it's private enough.
> It's sort of like keeping your phone number off the telephone book.[/color]

But do remember that blocking with robots.txt only keeps out spiders which
obey the rules. Spammers' spiders are out to steal whatever they can, and
may regard robots exclusions as a 'good stuff here!' flag. So you still
need to disguise any personal information :-(

--
To reply email rafe, at the address cix co uk

[Peter Chant]

Re: Limiting access to a website

Gordon Burditt wrote:

[color=blue]
>
> You probably don't want to go through the whole "site key" thing,
> although if there's a chance someone might spoof your site, it could
> be worthwhile. Bank spoof sites have become a serious problem.
>[/color]

I don't see spoofing to be a problem, there is no financial gain. I was not
expecting to put any information up, except 'Hello Fred' that would differ
from user to user.
[color=blue]
> The point here is that the presence of a cookie can be used to bypass
> part of the login sequence, but *LET THE USER SAY WHETHER THE COMPUTER
> IS SECURE OR NOT* before putting something on it that lets people
> log in as the user. Also it lets people who don't allow cookies
> at all in, but they have to go to a little extra trouble.
>
> Perhaps you could allow someone in with the cookie *OR* a password,
> but let them ask for the cookie (or not).[/color]

So you are saying, use a login but give them the option of using cookies
only if they are enabled.

Pete


--

http://www.petezilla.co.uk

[Peter Chant]

Re: Limiting access to a website

Peter Fox wrote:
[color=blue]
>
> I've just read the 10 or so messages in this thread and here is my
> different suggestion.[/color]

Cheers
[color=blue]
>
> * You might find it extremely useful to identify (with reasonable
> confidence short of definite) who is accessing the site either for
> statistics or general policing. eg What do you do if somebody leaves
> the club? So one ID per person sounds a good idea.[/color]

Yes
[color=blue]
>
> * You already have some sort of ID system in your membership list. Ie.
> some unique tag that you control and doesn't change at the whim of the
> member (eg email address can change but club membership number is
> fixed.)[/color]

Yes, it is a database ran by myself. This will not be linked to the
internet. _I_ use an id number system that does not change. Don't get me
started on the membership number system someone else uses that changes on a
yearly basis as they renew and / or mid year when they realised they
recorded a payment out of sync...
[color=blue]
>
> * If you email people their access 'code' then that's a reasonably
> private thing. The problem you are majoring on is getting people to
> type in 'their membership number' [For purposes of discussion I'll
> ignore spoofing considerations of using a membership number - you
> wouldn't use that.] All you do is email them an address such as
> <http://myclub.co.uk/members.php?Mbr No=12345> which is different for
> each member.
>[/color]

Good plan. Looking at the above a random number per user with a reasonable
length should do the trick. It would be difficult to guess the access
numbers on that basis. Easy on my separate membership database to
generate, via a cron job an access list:

tom,genovhvowvb uor
dick,riovnionio vnio
harry,hgioevnei oerr

etc
[color=blue]
> Your 'index.htm' page is for non-members with a bit linking to how to
> access members area (including what if you are a member but unexpectedly
> here.)
>
> members.php redirects duff $_GET['MbrNo'] values to the front page.
>[/color]

I'm thinking maybe about having just one page, index.php and using
variables, a switch statement and 'include' to produce each page.
<http://myclub.co.uk/members.php?Mbr No=12345&page=c alender>
I only want half a dozen pages at best so this keeps authentication nice and
simple.

[color=blue]
> Your joining instructions go as follows:
> 1. Go to myclub.co.uk and click on 'I am a member'
> 2. Enter your name, number, email address and street name
> The system then sends you an email informing you how to access the
> member's area.
> (You log the information for the benefit of the membership sec who can
> check street names. The access code is some hash or random number.)
> 3. Go to the web page indicated in the email AND BOOKMARK IT.
> (You might also attempt to set a cookie, that can be fallen back on if
> the user goes direct to the main page.)
>
> Can you see what's happened? The access key is in the bookmark and
> doesn't rely on cookies or memorising passwords or any typing in.[/color]

Yes, that is simple and aviods cookies. I'm not going to register anyone
via the website at the moment. Just keep it simple, they can email me.
[color=blue]
>
> When a page is accessed with ?MbrNo=12345 you should start it with
> "Hello Charlie Smith" just so _everyone knows_ the system has identified
> them.[/color]

Useful & friendly.
[color=blue]
> If Bots get to index.htm then that's great 'cos you presumably
> want to let non-members know of your Good Works. But make sure there is
> no link between index.htm and members.php (even if members.php is botted
> all that happens is a redirect to index.htm 'cos no bot will know the
> ?MbrNo bits required.
>[/color]

Only really intending this as a limited thing to give members the chance to
pull information from a website rather than wait until I send it out on a
mailing list, at least for the moment.

Thanks to all who have responded in this thread, it was useful and probally
has saved me time by avoiding making things overcomplicated .

Pete

--

http://www.petezilla.co.uk