If a page is password-protected, does this also stop spambots getting 
through to find an email address?

Client-side Y/N?
Server-side Y/N?

-dE|_---

"dE|_"  writes:

> If a page is password-protected, does this also stop spambots getting 
> through to find an email address?
>
> Client-side Y/N?
> Server-side Y/N?

I was about to say "yes (it blocks them)" and then I saw this.  What
do you mean by client and server side?  I know the terms mean, but in
what way might it affect the answer?  Are you thinking of come kind of
client-side script to do something relating to the password?  If so,
then answer depends on exactly what.  Almost nothing you do
client-side is of much help, but it can sometimes be a serious
security hole.

-- 
Ben.

"Ben Bacarisse"  wrote in message 
news:87hc9im0lr.fsf@bsb.me.uk...
> "dE|_"  writes:
>
>> If a page is password-protected, does this also stop spambots getting
>> through to find an email address?
>>
>> Client-side Y/N?
>> Server-side Y/N?
>
> I was about to say "yes (it blocks them)" and then I saw this.  What
> do you mean by client and server side?  I know the terms mean, but in
> what way might it affect the answer?  Are you thinking of come kind of
> client-side script to do something relating to the password?  If so,
> then answer depends on exactly what.  Almost nothing you do
> client-side is of much help, but it can sometimes be a serious
> security hole.

The client-side password system I've been testing is pretty good actualy. 
Maybe not MI5 or HSBC, but have a look at the source Jscript for 
http://www.websitefoundry.co.uk/indexpass.html

It scrambles up the entire page in base64, once the password is accepted 
there is no redirecting, the page is unscrambled and refreshed to the 
original. Set up with software.

My 'wise guy' Ben came round and set up htaccess where it was required, the 
above method is just prettier.

-dE|_---

"dE|_"  writes:

> "Ben Bacarisse"  wrote in message 
> news:87hc9im0lr.fsf@bsb.me.uk...
>> "dE|_"  writes:
>>
>>> If a page is password-protected, does this also stop spambots getting
>>> through to find an email address?
>>>
>>> Client-side Y/N?
>>> Server-side Y/N?
>>
>> I was about to say "yes (it blocks them)" and then I saw this.  What
>> do you mean by client and server side?  I know the terms mean, but in
>> what way might it affect the answer?  Are you thinking of come kind of
>> client-side script to do something relating to the password?  If so,
>> then answer depends on exactly what.  Almost nothing you do
>> client-side is of much help, but it can sometimes be a serious
>> security hole.
>
> The client-side password system I've been testing is pretty good actualy. 
> Maybe not MI5 or HSBC, but have a look at the source Jscript for 
> http://www.websitefoundry.co.uk/indexpass.html
>
> It scrambles up the entire page in base64, once the password is accepted 
> there is no redirecting, the page is unscrambled and refreshed to the 
> original. Set up with software.

Ah, I thought you were talking about systems that tried to obscure a
password.  I've seen some that actually enable the password to be
extracted!  Page encryption is possible client-side.

Word on the web is that your example uses RC4 and is thus unbreakable
(in practise).  I've had a look and does use RC4 but in an odd
repeated way using the same key which I am pretty sure introduces a
lot of weakness.  At the very least it repeatedly exposes the same
data that was found to be problematic with WEP.  I am sure it fine for
your purposes, but it is not how I'd do it.

You do have the problem that you can't trace accesses.  One the page
is served, you don't know of it was decoded.  Server-based systems
give you an audit log of accesses and access attempts.

> My 'wise guy' Ben came round and set up htaccess where it was required, the 
> above method is just prettier.

...and way more secure than HTTP basic authentication though,
personally, I still would not use client-side scripting for
accessibility reasons.

-- 
Ben.

dE|_  wrote:
> It scrambles up the entire page in base64, once the password is accepted 
> there is no redirecting, the page is unscrambled and refreshed to the 
> original. Set up with software.

So you're essentially ignoring anyone who can't (or won't) run
javascript? Mmmm.

Chris

"Chris Davies"  wrote in message 
news:fbsco5xq4d.ln2@news.roaima.co.uk...
> dE|_  wrote:
>> It scrambles up the entire page in base64, once the password is accepted
>> there is no redirecting, the page is unscrambled and refreshed to the
>> original. Set up with software.
>
> So you're essentially ignoring anyone who can't (or won't) run
> javascript? Mmmm.

I am still in two minds about this script method vs. htaccess and haven't 
paid for the software (£45). Partly depends on the audience and how vital a 
pretty entry page is.

Mind you; <noscript> Goes to htaccess instead </noscript>

I can call my connections in to put together a full scale server-side 
security system, but this would of course only be for higher budgets, the 
above for low.

-dE|_---

On 27/8/08 4:06 pm, in article h4etk.3645$W71.3175@newsfe12.ams2, "dE|_"
 wrote:

> 
> "Chris Davies"  wrote in message
> news:fbsco5xq4d.ln2@news.roaima.co.uk...
>> dE|_  wrote:
>>> It scrambles up the entire page in base64, once the password is accepted
>>> there is no redirecting, the page is unscrambled and refreshed to the
>>> original. Set up with software.
>> 
>> So you're essentially ignoring anyone who can't (or won't) run
>> javascript? Mmmm.
> 
> I am still in two minds about this script method vs. htaccess and haven't
> paid for the software (£45). Partly depends on the audience and how vital a
> pretty entry page is.
> 
> Mind you; <noscript> Goes to htaccess instead </noscript>
> 
> I can call my connections in to put together a full scale server-side
> security system, but this would of course only be for higher budgets, the
> above for low.
> 


htaccess is about as secure as you'll ever need unless the server gets
hacked in which case you're buggered anyway.

Client side security is actually and oxymoron in my opinion.

-- 
Andy Jacobs
http://www.redcatmedia.co.uk