• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

DSA Encryption In Javascript & Java

 
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
dear all,
SITUATION:
1) In the web application that i develop, after the login is successful i generate a public, private keys in Java and keep them in the session.
2) Similarly, i have JS code for DSA to encrypt and decrypt the form field values.

PROBLEM:
1) Can i encrypt the data in javascript using the server-side generated public-key? if so, see question 2.
2) How can i provide the server-side generated public-key to the JSP pages and What should i give it in the public key.
3) if i have encrypted the javascript data, once i receive the enc data in the server, can i decrypt it using the private-key generated in the server-side?


thank you
Vijay
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to JavaRanch.

Do you really mean "DSA encryption"? DSA is generally used for signatures, not encryption. Maybe you mean RSA?

Either way, is there a particular reason you don't want to use HTTPS, which is the preferred way to secure web conversations?
 
V Vijay Veeraraghavan
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
the real problem is, although the application uses the https and as default the encryption is provided with it, the client has tested (penetration testing) with a tool that is able to detect and log, change all the post request form values. the client has suggested to encrypt the post data for which we develop a public-key and provide to jsps. the jsp can encrypt the form data, in javascript, using the public-key and submit the page. the next action class then can decrypt it using the private-key.

I can also use RSA to generate public, private key pair. anyway, the problem lies the same.
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
HTTPS provides encryption between browser and web server; I think it's unlikely that that was penetrated (maybe if age-old 40-bit keys were used, which could be easily remedied by getting 128-bit keys). So I'd talk to the security testers to determine what they actually penetrated, and how. Then you can think about how to guard against that.

In my opinion it's highly unlikely that you will come up with a more secure solution in JavaScript than anything that HTTPS already provides.
 
V Vijay Veeraraghavan
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i have confirmed with authorities that our server uses the 128 bit encryption only.

the real scenario:
the client has installed the tool "paros" to which all the http, https request as responses passes through. once a page is submitted the tool traps with request and displays all the post parameters (if it contains). we are able to change the params as we like. the client has marked it as a serious security threat to the application as some sensitive data can be seen and modified (any primary-key ids store in the form hidden fields).

this is the reason to which i develop an encryption to encrypt the client side form data. although i can see deep into the now provided solution too contains a flaw (script code can be debugged using firebug etc tools) the only way we can hide the data which is displayed is by encrypting it.

hope i have explained the scenario clearly...
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Firstly, that tool works as a proxy, so of course it has access to all parameters, because it terminates and reestablishes SSL. But your production web app is not going through a proxy you have no control over, so this isn't actually a problem. If someone sees this as a security problem, then -with all due respect- they know very little about how the web works. What they probably meant was that they were able to alter some IDs, and the server side didn't pick up in that, which brings me to the next point.

Secondly, never -and I mean never- roundtrip DB key IDs from the server to the client and back, unless they're encrypted on the server and you can be sure that the client has no way of decrypting them. The client can't be trusted. Some attacker -not someone in the middle, but someone at the client side- will tamper with those IDs, so don't send them in cleartext. Even better, don't send them at all, but keep them in a server-side session.

Lastly, please drop the idea of doing anything with JavaScript and encryption. That's what HTTPS is for, which is secure.
[ October 13, 2008: Message edited by: Ulf Dittmer ]
 
V Vijay Veeraraghavan
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
dear Dittmer,
i appreciate your intelligent solution you have provided. thanks a lot.

## The same is the suggestion i gave to the company which they rejected it due to the reason that there are lots of modules codes to be modified which is a tedious work. Thats s the reason why i have been developing an alternate solution.
anyway, I will express my experiences once again on this issue to the company. let me see what the outcome is.

thanks
Vijay
 
Ranch Hand
Posts: 781
Netbeans IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


## The same is the suggestion i gave to the company which they rejected it due to the reason that there are lots of modules codes to be modified which is a tedious work. Thats s the reason why i have been developing an alternate solution.
anyway, I will express my experiences once again on this issue to the company. let me see what the outcome is.



If your security advisors are saying that HTTPS is insecure then the whole of Internet finance is insecure. Internet finance is not insecure. The only way that a proxy can do such a man-in-the-middle attack is if, during the https handshake preliminaries, it presents a certificate signed by someone you trust. So, the proxy would have had to be installed by someone you trust for them to be able to see the parameter values.

You need to hire a reputable security advisor because as it stands you are trying to solve a problem that does not exist.
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

James Sabre wrote:


## The same is the suggestion i gave to the company which they rejected it due to the reason that there are lots of modules codes to be modified which is a tedious work. Thats s the reason why i have been developing an alternate solution.
anyway, I will express my experiences once again on this issue to the company. let me see what the outcome is.



If your security advisors are saying that HTTPS is insecure then the whole of Internet finance is insecure. Internet finance is not insecure. The only way that a proxy can do such a man-in-the-middle attack is if, during the https handshake preliminaries, it presents a certificate signed by someone you trust. So, the proxy would have had to be installed by someone you trust for them to be able to see the parameter values.

You need to hire a reputable security advisor because as it stands you are trying to solve a problem that does not exist.



Hi All,

Nice to meet you all.

In this scenario, the attacker does not need any proxy which had to be installed. He can uses browser's add on, for instance, Live HTTP header for FireFox which can capture POST data.
There is nothing about HTTPS to be involved in this scenario because the insider acting as the attacker modified values of parameters which were seen via Live HTTP header or Paros as mentioned before, constructed a new URL containing modified values and re-submitted through GET method. As a result, some improper data could be stored into DB.
In my opinion, POST data should be encrypted before being sent to HTTPS in order to solve this problem.

Actaully I am finding the way to get through this as well. Any suggestions are warmly welcome.

Thank you for your interesting.
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Wit kobsutthipoonchai wrote:In my opinion, POST data should be encrypted before being sent to HTTPS in order to solve this problem.


Isn't that exactly what I said?

Ulf Dittmer wrote:Secondly, never -and I mean never- roundtrip DB key IDs from the server to the client and back, unless they're encrypted on the server and you can be sure that the client has no way of decrypting them. The client can't be trusted. Some attacker -not someone in the middle, but someone at the client side- will tamper with those IDs, so don't send them in cleartext. Even better, don't send them at all, but keep them in a server-side session.

 
Wit kobsutthipoonchai
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ulf Dittmer wrote:Isn't that exactly what I said?


Actually it is, I just missed your this quote.
 
reply
    Bookmark Topic Watch Topic
  • New Topic