f



How secure is the security from my security form?

Hey, I have a question about how secure the following will be....

I want to have a login form that posts to itself, so when it loads it checks
if there is a username and password on the query list.

If there is not, it asks for one.

If there is, it checks to see if the information is valid.

If it is not valid, it deletes the attributes and calls itself again.

If it is valid it sets a particular session variable to be some value and
redirects to the next page.

Every page from there on in will check to see if the session variable is set
and if not will redirect back to the login page.

Are there any security risks/holes that I should know about?

Thanks in advance,
Aaron

PS I do have access to Tomcat, but have been unable to figure out how to set
it up (this is my first time setting up security for a site) - so if anyone
has any tips/links that information would be most appreciated.  Thanks
again.


0
Aaron
7/28/2003 1:24:49 AM
comp.lang.java 3285 articles. 1 followers. Post Follow

3 Replies
1863 Views

Similar Articles

[PageSpeed] 8

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




0
Silvio
7/28/2003 11:53:45 AM
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...
> 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
>
>
>
>


0
Aaron
7/28/2003 6:57:46 PM
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:

> 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...
>> 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
>>
>>
>>
>>

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

0
Ingo
7/29/2003 12:15:36 AM
Reply: