More questions on security.

**Aidan** · Jul 17 '05, 02:15 PM

Re: More questions on security.

"Phil Coen" <nobody@nowhere .com> wrote in message
news:e5ydncAmHY 4WrErfRVn-jw@giganews.com ...[color=blue]
>I have never tried to build a web site to restrict users. Before, I always
> wanted everyone to be able to get to everything that I put on one of my
> sites. So now I am trying to write (actually just to learn to write) a
> site with a passworded front door. That is to say, you don't get in
> without the password. Not a thermonuclear secure site proof against
> crackers, the CIA and so forth - just a site with authorization needed.
> Kind of like they do at online newspapers.[/color]

So, you just want people to have to login before they reach the content of
your site? No need for encryption (SSL)?
[color=blue]
> Right now it is the concept that I am needing. I spent the day in the
> bookstore trying to find a book on the subject but no dice. All web
> building books just concern themselves with fancy HTML concepts and PHP
> books just on using the language. Apache books have quite a few chapters
> on security, but only from the standpoint of preventing deep cracking,
> open
> proxies, etc. Could find none that were concerned with how to actually
> build one. Ok, so back to figuring it out.
>
> One way that worked is to check (after the login in screen) the
> PHP_AUTH_USER and PHP_AUTH_PW at the start of every module that I call.
> Works ok, but seems to be a kludge.
>
> The method that I am trying now is to put everything past the login module
> into a subdir, put authorized users into a Linux group, and give access to
> that group. But so far the examples of passing the user and password from
> PHP to the Linux server aren't working. Or rather to say that I haven't
> made it work yet. Well, actually I can do it with Perl easily, but that
> isn't the point and I will never learn PHP if I go back and use what I
> already know.[/color]

Generally, my approach is this:

1. Present a (secure) form, asking for a user/pass pair
2. Check this user/pass pair against a list of user/pass pairs. I usually
store them in a database, but a flat file will work too.
3. If a match is found, start a session for the user with an 'Authenticated'
flag.
4. Each page they subsequently access looks for this 'Authenticated' flag in
the session. If it exists every thing is OK, and you can deliver them the
content... but if it doesn't exist, redirect the user the the login form
(step 1), and pass the URI they tried to access to the login page. If they
login successfully, redirect them to the page they initially requested.
[color=blue]
> Insights anyone?[/color]

Hope that helps.
[color=blue]
> Thanks
> Phil
>
>[/color]

**Colin McKinnon** · Jul 17 '05, 02:15 PM

Re: More questions on security.

[color=blue]
> "Phil Coen" <nobody@nowhere .com> wrote in message
> news:e5ydncAmHY 4WrErfRVn-jw@giganews.com ...[color=green]
>> The method that I am trying now is to put everything past the login
>> module into a subdir, put authorized users into a Linux group, and give
>> access to
>> that group. But so far the examples of passing the user and password
>> from
>> PHP to the Linux server aren't working.[/color][/color]

hrm. "passing the user and password from PHP to the Linux server"

Can you elucidate wht you mean by this ? My guess would be that you are
trying to authenticate the user using the standard authentication systems
on a Linux server. However 'standard' is a very badly defined target. Most
Linux (most Unix) daemons use PAM for authentication, and can support users
stored in LDAP, local files, databases, NIS maps....

IIRC there was a PAM PECL in development but I've lost track of it and ended
up writing my own C wrapper program (which also solves the setuid problem).
But for many pruposes it may be simpler to use the POP/IMAP functions to
verify the credentials.

What exactly is the problem? How are you trying to 'authenticate'?

Aidan wrote:[color=blue]
> 1. Present a (secure) form, asking for a user/pass pair
> 2. Check this user/pass pair against a list of user/pass pairs. I usually
> store them in a database, but a flat file will work too.
> 3. If a match is found, start a session for the user with an
> 'Authenticated' flag.
> 4. Each page they subsequently access looks for this 'Authenticated' flag
> in
> the session. If it exists every thing is OK, and you can deliver them the
> content... but if it doesn't exist, redirect the user the the login form
> (step 1), and pass the URI they tried to access to the login page. If
> they login successfully, redirect them to the page they initially
> requested.[/color]

So Aidan's doing it all in PHP. The problem with this approach is that

1) storing passwords - or password equivalents - unhashed is not generally
considered good security practice.

2) you don't get the benefit of all the tools available for account
management which can be applied to an NSS/PAM based system

having said that, it can be an advantage to maintain a stretch of 'clear
blue water' between the users whom access the website, and the conventional
users.

C.

**Gordon Burditt** · Jul 17 '05, 02:15 PM

Re: More questions on security.

>I have never tried to build a web site to restrict users. Before, I always[color=blue]
>wanted everyone to be able to get to everything that I put on one of my
>sites. So now I am trying to write (actually just to learn to write) a
>site with a passworded front door. That is to say, you don't get in
>without the password. Not a thermonuclear secure site proof against
>crackers, the CIA and so forth - just a site with authorization needed.
>Kind of like they do at online newspapers.[/color]

Consider the possibility of using Apache basic authentication,
activated in .htaccess files. Simple, secure, and it's pretty much
done for you except turning it on and any issues of maintaining the
user list. No PHP code at all required (although the PHP code can
look at who you're logged in as and do something with it, like look
up access privileges associated with that account). I believe there
are some modules for Apache which allow authentication from a MySQL
database, which makes adding users easier.

Gordon L. Burditt

**Daniel Tryba** · Jul 17 '05, 02:15 PM

Re: More questions on security.

Gordon Burditt <gordonb.85729@ burditt.org> wrote:[color=blue]
> Consider the possibility of using Apache basic authentication,
> activated in .htaccess files. Simple, secure, and it's pretty much
> done for you except turning it on and any issues of maintaining the
> user list.[/color]

It's sure simple to setup, but secure?

**Gordon Burditt** · Jul 17 '05, 02:15 PM

Re: More questions on security.

>> Consider the possibility of using Apache basic authentication,[color=blue][color=green]
>> activated in .htaccess files. Simple, secure, and it's pretty much
>> done for you except turning it on and any issues of maintaining the
>> user list.[/color]
>
>It's sure simple to setup, but secure?[/color]

Compared to anything a beginner will cook up using PHP, it's secure.
Especially if it also uses SSL. The original poster wanted something
basic and not necessarily good against the CIA. Network sniffing
attacks are not much of an issue here. Now, if this was protecting
credit card numbers, the advice would be MUCH different.

Gordon L. Burditt

**sfmerkaba@gmail.com** · Jul 18 '05, 05:15 PM

Re: More questions on security.

Gordon,

I would be interested in your advice for protecting credit card
numbers.

My plan was to use mcrypt and store in mySql database. I thought I
might use another field in the database as the key.

I will erase number as soon as the card is authorized.

Thank you for your help.

AND thanks to all those who answer the many questions posted to this
group. I have learned much from you.

Pat

**Gordon Burditt** · Jul 18 '05, 06:55 PM

Re: More questions on security.

>I would be interested in your advice for protecting credit card[color=blue]
>numbers.
>
>My plan was to use mcrypt and store in mySql database. I thought I
>might use another field in the database as the key.[/color]

Well, consider what your biggest threats are here.
If you are trying to protect against the admin of your hosted
web and/or database site, you can pretty well forget it. Although
encrypting the credit card numbers does make it a bit harder
than just a SQL query for all of them.

If your idea here is that nobody will guess which field you are
using as the key, think again. Even if you have 200 fields in the
table, it won't take that long to figure out which one is the key.
Also, you have to worry about the field used as the key changing
(people get married and change their names, addresses and phone
numbers change, etc.) Some fields don't have enough variety to be
used as a key (Let's see, one field can have Mr., Mrs., Miss, Dr.,
Queen, Pope, etc. as values but really the first three are the only
ones that will be used much.) You could use it as *part* of a key.

If you are trying to protect against accidental disclosure of a
dump of your database (or making it downloadable from the site, or
having a virus send it somewhere), it would be best if the key (or
at least an essential part of it) and the encrypted credit number
are kept separated, so whoever gets one probably doesn't get the
other. This, I would think, would mean at least separate tables,
or one table and one config file used by your scripts.
[color=blue]
>I will erase number as soon as the card is authorized.[/color]

Careful, here. How long do you actually need to keep that number
around? Consider the scenario (which is not at all uncommon for
my employer, an ISP): New user signs up for 1 year via web form.
Initial online check of the card says it's OK. The charge goes
through. Forget for the moment that an ISP normally keeps credit
card numbers around for automatic renewals, and pretend it's sort
of like a pre-paid pay-by-the-spam spamming card for an ISP, pay
once with no automatic renewals (unfortunately I think the main use
of this would be by spammers).

Two months later the credit card company reverses the charge because
the REAL cardholder spotted the charge on their statement and
objected that they don't want a dialup account for a Texas ISP
because they live in Iraq, they never ordered it, and their identity
has been stolen. (Two months is not particularly long for this
sort of thing: it can take 5-6 weeks from the charge to the
cardholder receiving the statement, and a couple of weeks before
they read and pay it, and maybe a couple of weeks for the credit
card company to investigate it.) You get this report. Now, *WHICH
ACCOUNT DO YOU SHUT OFF*? Have you still got info needed to determine
that? Can you figure out which other accounts used the same account
number that haven't been reported yet? And do you have enough info
to report the crime, so if the guy gets caught, you have enough
evidence to recover something?

Now, if you do keep the info around, perhaps these older archives
are more safely kept on a private system not usually connected to
the Internet (e.g. dialed up once a week to archive the old records),
perhaps burned on CD-ROM and normally kept in a safe in your home
(and still encrypted).
Gordon L. Burditt

**sfmerkaba@gmail.com** · Jul 21 '05, 06:55 AM

Re: More questions on security.

Gordon,

Thanks for your thoughts. You have definitely given me some good tips
for implementing this system.

This is for a small charity and I am doing this as a volunteer.

I have many years as a mainframe developer but am fairly new to php and
web development -- so this is definitely a learning experience <grin>.

Thanks again,
Pat

More questions on security.

More questions on security.

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment