Talk:Java Server Faces - Revision history

Stephendv: /* EUxx discussion */

2008-01-14T15:16:34Z

‎EUxx discussion

Ebing: /* EUxx discussion */

2007-06-11T18:30:20Z

‎EUxx discussion

Ebing: New page: == EUxx discussion == I think the blog by EUxx missed some of the details of the implementation. Note that while the MAC and the IV are known, there is still a secret key known to the ser...

2007-06-11T18:23:22Z

New page: == EUxx discussion == I think the blog by EUxx missed some of the details of the implementation. Note that while the MAC and the IV are known, there is still a secret key known to the ser...

New page

== EUxx discussion ==
I think the blog by EUxx missed some of the details of the implementation. Note that while the MAC and the IV are known, there is still a secret key known to the server used in the MAC that prevents the client from generating a new MAC. This is a fairly common pattern. You can see Inderjeet's response at:
http://weblogs.java.net/blog/inder/archive/2005/05/securing_webapp.html

I think we should either take this section out, or expand on why its an issue.

← Older revision		Revision as of 15:16, 14 January 2008
Line 5:		Line 5:
	I think we should either take this section out, or expand on why its an issue.		I think we should either take this section out, or expand on why its an issue.
	[[User:Ebing\|Ebing]] 14:30, 11 June 2007 (EDT)		[[User:Ebing\|Ebing]] 14:30, 11 June 2007 (EDT)
		+
		+	Moved it here, till the author can correct [[User:Stephendv\|Stephendv]] 10:16, 14 January 2008 (EST)
		+
		+	===EUxx===
		+	http://jroller.com/page/eu stated the following:
		+	''It seems there are few gaps in this claim. Data sent to the client look like this: [MAC][IV][ENCDATA] As you can see, MAC and IV values are known to the client. It means that nothing can stop client from tampering ENCDATA block and then generate a new MAC. This can be improved with using signature based on public key scheme instead of MAC. However that will increase amount of computations for building message data and will require to store public key in HttpSession. Another potential security issue is related to the usage of block cipher. By the nature of Object Serialization Stream Protocol, every encrypted plain text will have common patterns. More over, because client can indirectly control content of the encrypted data by submitting specially crafted requests to the server, that some data from request will be sent back in encrypted form). This can open the door for "known-text" attack and I'm not sure how good "industrial-strength" ciphers against such attacks. Again, this can be improved by generating secure key for every request, but it will create additional troubles on concurrent scenarios and will require that key will be distributed across the cluster on every change. So, I think that above issues has to be investigated more deep and proper security analysis must be done before suggesting any solution that is using some forms of cryptography.''

← Older revision		Revision as of 18:30, 11 June 2007
Line 4:		Line 4:

	I think we should either take this section out, or expand on why its an issue.		I think we should either take this section out, or expand on why its an issue.
		+	[[User:Ebing\|Ebing]] 14:30, 11 June 2007 (EDT)