How secure is the security from my security form?

Re: How secure is the security from my security form?

Aaron,

The most important security issue involved here is the submission of the
login-parameters. If it is a plain HTTP form the data can easily be
intercepted and the login-parameters can be extracted.

There are several ways to prevent this. One would be to use HTTPS instead of
HTTP for submitting the form. This has the disadvantage that you need an
(expensive) certificate.
Another solution is to do the following. When you generate the login-form on
the server-side generate some random key with it. On the page, put some
JavaScript that will hash-encode the entered username/password using the
random key in the hash algorithm. Make sure you use a destructive hash
function with sufficient spreading. Do not post the username/password but
submit the username/hashresult. Since on the server you know the random key
and the hashfunction and the users password you can recalculate the
hashvalue from that data. If the hashvalues match you allow the logon
attempt, otherwise you reject it. This way if someone captures the posted
data he can not use it to attempt a successive logon since the random-key
that was used is no longer valid on the server.

It is not as secure as HTTPS would be but it comes close enough for most
situations. Using a good hash function and random-generator can make it a
pretty secure mathod.

Regards,

Silvio Bierman

Re: How secure is the security from my security form?

Thanks for the info.

https may work then, the only people that are going to be using this are
employees, so we can just ignore the warning (but that does not look very
professional).

I am still going to try to figure out how to configure Tomcat, as I believe
this is the most secure way - but I have tried to sort through "The Apache
Jakarta Project: The Tomcat 4 Servlet JSP Container" @
http://jakarta.apache.org, but have not been able to make it work yet.

If you know of any good books or links that explain this process step by
step, the info would be most appreciated.

Thanks again
Aaron.

"Silvio Bierman" <sbierman@idfix .nl> wrote in message
news:3f250f58$0 $49109$e4fe514c @news.xs4all.nl ...[color=blue]
> Aaron,
>
> The most important security issue involved here is the submission of the
> login-parameters. If it is a plain HTTP form the data can easily be
> intercepted and the login-parameters can be extracted.
>
> There are several ways to prevent this. One would be to use HTTPS instead[/color]
of[color=blue]
> HTTP for submitting the form. This has the disadvantage that you need an
> (expensive) certificate.
> Another solution is to do the following. When you generate the login-form[/color]
on[color=blue]
> the server-side generate some random key with it. On the page, put some
> JavaScript that will hash-encode the entered username/password using the
> random key in the hash algorithm. Make sure you use a destructive hash
> function with sufficient spreading. Do not post the username/password but
> submit the username/hashresult. Since on the server you know the random[/color]
key[color=blue]
> and the hashfunction and the users password you can recalculate the
> hashvalue from that data. If the hashvalues match you allow the logon
> attempt, otherwise you reject it. This way if someone captures the posted
> data he can not use it to attempt a successive logon since the random-key
> that was used is no longer valid on the server.
>
> It is not as secure as HTTPS would be but it comes close enough for most
> situations. Using a good hash function and random-generator can make it a
> pretty secure mathod.
>
> Regards,
>
> Silvio Bierman
>
>
>
>[/color]

Re: How secure is the security from my security form?

Which warning are you referring to? The warning about "unknown certificate
authority?" DO NOT tell people to ignore this warning. It might be benign
in your case, but knowing how most employees think, they would ignore it
for all other sites that may not be benign.

Instead, there are two other options. First, you can actually get a
certificate from Verisign or Thawte. Done.

Or you can self-sign the certificate (which of course is quite a bit
cheaper), and then go around to all machines in your company and install
the certificate (usually, it is fairly easy to do: visit one of the
HTTPS-protected Web sites, and then the warning message should give you
the option to install the certificate).

On Mon, 28 Jul 2003 18:57:46 +0000, Aaron wrote:
[color=blue]
> Thanks for the info.
>
> https may work then, the only people that are going to be using this are
> employees, so we can just ignore the warning (but that does not look
> very professional).
>
> I am still going to try to figure out how to configure Tomcat, as I
> believe this is the most secure way - but I have tried to sort through
> "The Apache Jakarta Project: The Tomcat 4 Servlet JSP Container" @
> http://jakarta.apache.org, but have not been able to make it work yet.
>
> If you know of any good books or links that explain this process step by
> step, the info would be most appreciated.
>
> Thanks again
> Aaron.
>
> "Silvio Bierman" <sbierman@idfix .nl> wrote in message
> news:3f250f58$0 $49109$e4fe514c @news.xs4all.nl ...[color=green]
>> Aaron,
>>
>> The most important security issue involved here is the submission of
>> the login-parameters. If it is a plain HTTP form the data can easily be
>> intercepted and the login-parameters can be extracted.
>>
>> There are several ways to prevent this. One would be to use HTTPS
>> instead[/color]
> of[color=green]
>> HTTP for submitting the form. This has the disadvantage that you need
>> an (expensive) certificate.
>> Another solution is to do the following. When you generate the
>> login-form[/color]
> on[color=green]
>> the server-side generate some random key with it. On the page, put some
>> JavaScript that will hash-encode the entered username/password using
>> the random key in the hash algorithm. Make sure you use a destructive
>> hash function with sufficient spreading. Do not post the
>> username/password but submit the username/hashresult. Since on the
>> server you know the random[/color]
> key[color=green]
>> and the hashfunction and the users password you can recalculate the
>> hashvalue from that data. If the hashvalues match you allow the logon
>> attempt, otherwise you reject it. This way if someone captures the
>> posted data he can not use it to attempt a successive logon since the
>> random-key that was used is no longer valid on the server.
>>
>> It is not as secure as HTTPS would be but it comes close enough for
>> most situations. Using a good hash function and random-generator can
>> make it a pretty secure mathod.
>>
>> Regards,
>>
>> Silvio Bierman
>>
>>
>>
>>[/color][/color]

--
Keep American Families united! Support H.R. 539 and H.R. 832
For more information, see http://www.kkeane.com/lobbyspousal-faq.shtml