RE: SSL just for a login page
Hi I am not am expert in the security of the web at the moment. Could you explain to me why this would open such a big secuirty hole from swapping from https to https. I was suggesting this because it read this i a 'professional j2ee' book?!! The problem i have is that i need the username and password to be encrypted but i have heard that ssl hits performance quite badly!! I dont think that i could handle filtering, so what do you suggest for the security?? What is the 'norm' for these such problems. Thanks Glen. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSL just for a login page
the problem is your own encryption isn't signed by a third party, which means if someone hack into your server, they could compromise the security. Hackers are smart and have tons of free time. If there's a hole, it will be found and exploited. Most big e-comm sites use hardware acceleration to improve the performance. If you're going to handle moderate SSL traffic, you should get hardware acceleration that sits between the webservers and the browser. Look at BigIP, network SSL modules or other hardware solutions. there are companies selling ssl ethernet cards for systems if you don't need heavy duty SSL. peter lin Drinkwater, GJ (Glen) wrote: Hi I am not am expert in the security of the web at the moment. Could you explain to me why this would open such a big secuirty hole from swapping from https to https. I was suggesting this because it read this i a 'professional j2ee' book?!! The problem i have is that i need the username and password to be encrypted but i have heard that ssl hits performance quite badly!! I dont think that i could handle filtering, so what do you suggest for the security?? What is the 'norm' for these such problems. Thanks Glen. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: SSL just for a login page
Why don't you just build your redirect after they log in. response.sendRedirect(http://; + request.getHostName() + /myApp/home.jsp); -Original Message- From: Drinkwater, GJ (Glen) [mailto:[EMAIL PROTECTED]] Sent: Friday, August 09, 2002 8:52 AM To: 'Tomcat Users List' Subject: RE: SSL just for a login page Hi I am not am expert in the security of the web at the moment. Could you explain to me why this would open such a big secuirty hole from swapping from https to https. I was suggesting this because it read this i a 'professional j2ee' book?!! The problem i have is that i need the username and password to be encrypted but i have heard that ssl hits performance quite badly!! I dont think that i could handle filtering, so what do you suggest for the security?? What is the 'norm' for these such problems. Thanks Glen. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: SSL just for a login page
Hi Let me reply to a few of the emails. the problem is your own encryption isn't signed by a third party, which means if someone hack into your server, they could compromise the security. wouldn't this still be a problem if my public key was signed by a CA?? isn't the cert. for the client to verify who i am, this would not effect the SSL encryption?? Why don't you just build your redirect after they log in. response.sendRedirect(http://; + request.getHostName() + /myApp/home.jsp); i have tried this. What i am doing is using the login to set up a session and adding a attribute to this session. Every jsp checks the session for this object to verify that the user has logged in, if they have not or they have logged out the user is unable to bookmark or go backward into the website. Using the redirect like this some how interferes with the session and messes up the checking. I am not sure why this happens? Glen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSL just for a login page
Drinkwater, GJ (Glen) wrote: Hi Let me reply to a few of the emails. the problem is your own encryption isn't signed by a third party, which means if someone hack into your server, they could compromise the security. wouldn't this still be a problem if my public key was signed by a CA?? isn't the cert. for the client to verify who i am, this would not effect the SSL encryption?? For more details on SSL, here's the spec. http://wp.netscape.com/eng/ssl3/draft302.txt Remember that using SSL include a lot than just encrypting data. It includes establishing secure session, cert management and other processes. In theory, if a hacker compromises your server they can break both a custom encryption ans ssl. But breaking SSL is harder than just decompiling java code to see which algo/padding/key scheme you are using. Whereas breaking SSL would require much more work. In reality, a hacker would more likely break into your database than mess with decompiling your code. Casual hackers will be discouraged by SSL. Hardcore hackers are hard to protect against. good luck with what ever you choose. peter -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: SSL just for a login page
Well, obviously the only thing being protected here is the login and password, user activity after the login will be open to snooping, hijacking, etc. So here's what I think you should do. 1) User logs in through ssl. 2) After a successful login, (still ssl, don't put anything session yet) pass the user's ID and a one-way hashed version of their password to a non ssl page that authenticates this information and sets up their session. Dave -Original Message- From: Drinkwater, GJ (Glen) [mailto:[EMAIL PROTECTED]] Sent: Friday, August 09, 2002 9:19 AM To: 'Tomcat Users List' Subject: RE: SSL just for a login page Hi Let me reply to a few of the emails. the problem is your own encryption isn't signed by a third party, which means if someone hack into your server, they could compromise the security. wouldn't this still be a problem if my public key was signed by a CA?? isn't the cert. for the client to verify who i am, this would not effect the SSL encryption?? Why don't you just build your redirect after they log in. response.sendRedirect(http://; + request.getHostName() + /myApp/home.jsp); i have tried this. What i am doing is using the login to set up a session and adding a attribute to this session. Every jsp checks the session for this object to verify that the user has logged in, if they have not or they have logged out the user is unable to bookmark or go backward into the website. Using the redirect like this some how interferes with the session and messes up the checking. I am not sure why this happens? Glen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: SSL just for a login page
Like I said, you're session is open to snooping and hijacking, but your password is not revealed. -Original Message- From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]] Sent: Friday, August 09, 2002 9:38 AM To: Tomcat Users List Subject: AW: SSL just for a login page That's no solution, as now the oneway hash can be snooped and hijacked. You win absolutly nothing but wasted efford. -Ursprüngliche Nachricht- Von: Durham David Cntr 805CSS/SCBE [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 9. August 2002 16:30 An: Tomcat Users List Betreff: RE: SSL just for a login page 2) After a successful login, (still ssl, don't put anything session yet) pass the user's ID and a one-way hashed version of their password to a non ssl page that authenticates this information and sets up their session. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSL just for a login page
what's to stop a hacker from stealing the session, then going to the user profile page and looking at the password? Of course if you do pass the user to http from https, you can still require profile management go through https, or simply never print the password to the browser. I personally wouldn't want to use a insecure site for anything with personal information. as others have said, you have to weigh the cost vs advantage of tight security. if you're prohibited by cost, ie paying for cert, and hardware, then you really don't have a choice. peter Durham David Cntr 805CSS/SCBE wrote: Like I said, you're session is open to snooping and hijacking, but your password is not revealed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: SSL just for a login page
Yes, you are probably right, I will have to use ssl. Does anybody know of some good stress testing free software??? How does this sound. 1)User logs on and username and password send over ssl. password md5 hashed and compared against users on a database. 2)If valid user logs on, if not user sent to error page. 3) rest of session ssl. if database compromised, hash value would be no use??? Lastly, how do i enforce that the whole of the web site must be over ssl, except the initial welcome page so the user doesn't have to type in port numbers is it something like this in the web.xml file. security-constraint web-resource-collection web-resource-name***/web-resource-name url-pattern/index.html/url-pattern /web-resource-collection user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint security-constraint web-resource-collection web-resource-name***/web-resource-name url-pattern/*/url-pattern //or will this overwrite the index.html url-pattern/*jsp/url-pattern //should it be like this url-pattern/data/*/url-pattern url-pattern/etc/*/url-pattern //etc http-methodGET/http-method http-methodPOST/http-method /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSL just for a login page
And what happens with the user session ??? Every single page a verify if the user session is Ok, if not I have to redirect him to the login page. But if I do what you are saying I will lost the user session. Junior On Fri, 9 Aug 2002 09:08:22 -0500 Durham David Cntr 805CSS/SCBE [EMAIL PROTECTED] wrote: Why don't you just build your redirect after they log in. response.sendRedirect(http://; + request.getHostName() + /myApp/home.jsp); -Original Message- From: Drinkwater, GJ (Glen) [mailto:[EMAIL PROTECTED]] Sent: Friday, August 09, 2002 8:52 AM To: 'Tomcat Users List' Subject: RE: SSL just for a login page Hi I am not am expert in the security of the web at the moment. Could you explain to me why this would open such a big secuirty hole from swapping from https to https. I was suggesting this because it read this i a 'professional j2ee' book?!! The problem i have is that i need the username and password to be encrypted but i have heard that ssl hits performance quite badly!! I dont think that i could handle filtering, so what do you suggest for the security?? What is the 'norm' for these such problems. Thanks Glen. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] - Prefiro as lágrimas da derrota do que a vergonha de não ter lutado... Willan Brook - Don't E-Mail, ZipMail! http://www.zipmail.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: SSL just for a login page
jmeter, available from jakarta.apache.org -Original Message- From: Drinkwater, GJ (Glen) [mailto:[EMAIL PROTECTED]] Sent: Friday, August 09, 2002 9:59 AM To: 'Tomcat Users List' Subject: RE: SSL just for a login page Yes, you are probably right, I will have to use ssl. Does anybody know of some good stress testing free software??? How does this sound. 1)User logs on and username and password send over ssl. password md5 hashed and compared against users on a database. 2)If valid user logs on, if not user sent to error page. 3) rest of session ssl. if database compromised, hash value would be no use??? Lastly, how do i enforce that the whole of the web site must be over ssl, except the initial welcome page so the user doesn't have to type in port numbers is it something like this in the web.xml file. security-constraint web-resource-collection web-resource-name***/web-resource-name url-pattern/index.html/url-pattern /web-resource-collection user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint security-constraint web-resource-collection web-resource-name***/web-resource-name url-pattern/*/url-pattern //or will this overwrite the index.html url-pattern/*jsp/url-pattern //should it be like this url-pattern/data/*/url-pattern url-pattern/etc/*/url-pattern //etc http-methodGET/http-method http-methodPOST/http-method /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSL just for a login page
For stress testing use Apache JMeter. good luck Richard Drinkwater, GJ (Glen) wrote: Yes, you are probably right, I will have to use ssl. Does anybody know of some good stress testing free software??? How does this sound. 1)User logs on and username and password send over ssl. password md5 hashed and compared against users on a database. 2)If valid user logs on, if not user sent to error page. 3) rest of session ssl. if database compromised, hash value would be no use??? Lastly, how do i enforce that the whole of the web site must be over ssl, except the initial welcome page so the user doesn't have to type in port numbers is it something like this in the web.xml file. security-constraint web-resource-collection web-resource-name***/web-resource-name url-pattern/index.html/url-pattern /web-resource-collection user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint security-constraint web-resource-collection web-resource-name***/web-resource-name url-pattern/*/url-pattern //or will this overwrite the index.html url-pattern/*jsp/url-pattern //should it be like this url-pattern/data/*/url-pattern url-pattern/etc/*/url-pattern //etc http-methodGET/http-method http-methodPOST/http-method /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: SSL just for a login page
just downloaded it version 1.7 using it with java 1.4 beta installation says that you dont need to do anything (already got JAVA_HOME), when i run it it just pulls up errors?? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: SSL just for a login page
post this on the jmeter-user list -Original Message- From: Drinkwater, GJ (Glen) [mailto:[EMAIL PROTECTED]] Sent: Friday, August 09, 2002 10:26 AM To: 'Tomcat Users List' Subject: RE: SSL just for a login page just downloaded it version 1.7 using it with java 1.4 beta installation says that you dont need to do anything (already got JAVA_HOME), when i run it it just pulls up errors?? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: SSL just for a login page
i'm using j2sdk1.4.0_01 for linux, and you have to set JAVA_HOME in your PATH. now i do know that javac automatically sets the classpath to the location of the tools.jar file located in /lib -Original Message- From: Drinkwater, GJ (Glen) [mailto:[EMAIL PROTECTED]] Sent: Friday, August 09, 2002 10:26 AM To: 'Tomcat Users List' Subject: RE: SSL just for a login page just downloaded it version 1.7 using it with java 1.4 beta installation says that you dont need to do anything (already got JAVA_HOME), when i run it it just pulls up errors?? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: SSL just for a login page
On Fri, 9 Aug 2002, Drinkwater, GJ (Glen) wrote: Date: Fri, 9 Aug 2002 14:51:32 +0100 From: Drinkwater, GJ (Glen) [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Subject: RE: SSL just for a login page Hi I am not am expert in the security of the web at the moment. Could you explain to me why this would open such a big secuirty hole from swapping from https to https. Switching from http to https is not the problem. Switching back is. I was suggesting this because it read this i a 'professional j2ee' book?!! The problem i have is that i need the username and password to be encrypted but i have heard that ssl hits performance quite badly!! I dont think that i could handle filtering, so what do you suggest for the security?? What is the 'norm' for these such problems. On an http connection, anyone who has access to the physical network can snoop packets and see what is going on. That's why you're trying to encrypt the username and password in the first place, right? The problem is that username/password is not the only sensitive information going back and forth -- the session identifier is also passed up to the server on each request, either in a cookie or as part of the URLs. This is how the server knows that a subsequent request belongs to the logged-in user. Anyone who knows the session id can impersonate the logged on user, and do anything that user is allowed to do. If you switch back to http after logging in, that means the session id will get transmitted in cleartext (and, no, there's nothing you can do to encrypt *just* that). Therefore, any snooper on the network can see this session id and start submitting their own requests with that session id. The server thinks that you've already authenticated, so it lets you do whatever you want. All the snooper has to do is wait for someone to log on, observe their next submit to the server, and snarf the session id ... The bottom line is that using SSL only for the username/password is a total waste of time from a security perspective. If you're not going to encrypt the entire conversation (which includes the session ids), don't even bother trying -- you will only get the illusion (or should I say, *delusion*) of being more secure. In reality, you'd accomplish nothing useful. A more general statement of the principle: once you switch a session from http to https, you should never again accept a non-https request for that same session. Applications that don't obey this rule are hopelessly insecure, and should be avoided like the plague. Thanks Glen. Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
