bugtraq - RE: Cracking String Encryption in Java Obfuscated Bytecode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <C4B880098AA68B4CB4A0B82B1419A46002B5F40F@mailva>
Date: Mon, 27 Nov 2006 06:49:49 -0800
From: Jeremy Epstein <jeremy.epstein@...methods.com>
To: Jim Manico <jim@...ico.net>, subere@...on.org
Cc: bugtraq@...urityfocus.com
Subject: RE: Cracking String Encryption in Java Obfuscated Bytecode

Jim,

With all respect, I (partially) disagree with you:

> With respect, I disagree from a Java perspective.
> 
> 1) If you are deploying Java on the server you are protected 
> by so many layers, code obfuscation is not critical

True, but there are more reasons than just security for using obfuscation -
reducing (but not eliminating!) the risk of reverse engineering, protection
of intellectual property, etc.  So if you're saying "code obfuscation is not
critical FOR SECURITY" I agree, but not necessarily for other reasons.

> 2) If you are deploying Java Applets for enterprise 
> applications, you are nuts. They are inherently insecure and 
> Java applets have a long history of critical problems.

Well, this is true - but it's the wrong reason.  As just about everyone on
this list knows, relying on the client side to do security enforcement is
inherently a losing proposition.  And obfuscating the bytecode doesn't make
client-side enforcement any more secure.

--Jeremy