|
|
Posted by Dan Trainor on 03/01/05 17:49
Mikey wrote:
>>To address Mikey's question - I am not looking for a way to
>>uniquely identify users. For one, it's just not possible.
>>On top of that, the vast majority of members with to stay
>>anonymous for reasons that I am not even going to begin to
>>state on this list, because we all know where that will end up.
>
>
> I think you have misunderstood me - I mean't uniquely identifying *clients*
> - browsers.
>
>
>>I am trying to ensure that one login and one password are
>>specific to one client. Several methods of this include
>>making sure that not more than two IPs use a specific
>>login/password throughout a pre-set threshold, and on top of
>>this, the automatic blocking of IPs that attempt brute-force
>>style attacks. These two items alone would be an invaluable
>>tool in the assurance that logins and passwords are not abused.
>
>
> As I say, have a look at phpsec.org - the article on sessions is what you
> want, and it will explain why doing something like that will not work as
> expected. Some proxies assign new IPs for every request from a single
> client (AOL in particular). Do you really want to exclude a large
> proportion of the internet population?
>
> HTH,
>
> Mikey
>
Mikey -
I'm pretty aware of how it all works. However, the problem lies in the
fact that because most of the pre-installed billing software relies
solely on .htaccess/.htpasswd-based authentication, it's not possible to
just change the whole login system. For the most part, they're still
using privative means of authentication which are broken to begin with.
The difficulty is trying to find a solution that would limit access and
do all the fancy stuff that we had discussed, without interfering with
the pre-existing authentication system. Many of the solutions that I've
seen so far include some mod-rewrite hackery that a PHP script or
"Gateway" modifies to allow/disallow access based on a given set of
criteria.
It's unfortunate that most of the billing systems operate this way.
They're not going to change - and I know this because I had worked with
the biggest. It would benefit them greatly to investigate other means
of authentication, perhaps with a SQL back end and such - but that is a
subject I'd not want to bring up here because I know it's been discussed
many a time on this list, and I'd hate to start another flame war.
Although it would benefit them greatly, most of their customers expect
stuff in a simplistic and uniform manner. Changing the whole
login/authentication system would wreak havoc among these clients who
are not technically inclined, and is just not possible at this time.
Friends and I have given serious thought to actually starting our own
processing solution, but it is not possible at this time due to the
large amount of liability that we would inherit. Perhaps though, with
time, this will be possible. When that time comes, we plan on having an
"open" solution that would try to set some sort of robust and highly
configurable standard for this specific application.
Thanks again for taking the time to respond.
-dant
Navigation:
[Reply to this message]
|