Path: csiph.com!x330-a1.tempe.blueboxinc.net!feeder1.hal-mli.net!news.glorb.com!news-out.readnews.com!news-xxxfer.readnews.com!news-out.news.tds.net!newsreading01.news.tds.net!86597e80!not-for-mail From: "Lothar Kimmeringer" Subject: Re: passwords, Strings an Message-ID: X-Comment-To: comp.lang.java.security Newsgroups: comp.lang.java.security In-Reply-To: References: Content-Type: text/plain; charset=IBM437 Content-Transfer-Encoding: 8bit X-Gateway: time.synchro.net [Synchronet 3.15a-Win32 NewsLink 1.92] Lines: 95 Date: Wed, 27 Apr 2011 16:08:36 GMT NNTP-Posting-Host: 96.60.20.240 X-Complaints-To: news@tds.net X-Trace: newsreading01.news.tds.net 1303920516 96.60.20.240 (Wed, 27 Apr 2011 11:08:36 CDT) NNTP-Posting-Date: Wed, 27 Apr 2011 11:08:36 CDT Organization: TDS.net Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.security:178 To: comp.lang.java.security Wojtek wrote: > As I understand it, the String "hello" is present in the source code. > So the Java compiler places it into a string pool, where it exists as > long as the JVM is alive No. The pool-handling is done by the JVM during runtime: import junit.framework.TestCase; public class StringTest extends TestCase { public void testStringCreation(){ char[] array1 = new char[10]; char[] array2 = new char[10]; for (int i = 0; i < array1.length; i++){ array1[i] = (char) ('A' + i); array2[i] = (char) ('A' + i); } String text1 = new String(array1); String text2 = new String(array2); assertNotSame(text1, text2); assertSame(text1.intern(), text2.intern()); } } > However a String which is created while the application is running > (user entered, read from file, HTML parameters) does not get put into > the string pool. That's not true as you can see above. > Indeed, such an action would quickly use up all > available memory when reading large files or in long running Web > applications. There not kept there forever, i.e. if no reference points to the element in the pool it can be garbage collected. The problem is that you can't control the Garbage Collector and its decision if a specific element in the String-pool should be garbage collected or not. > So once the String object is garbage collected, the memory location is > available for another object, and can be over-written. That's true, but until that the content of the String is still in the memory, so a dump still reveals the password and you can't never be sure when a specific String-content is garbage collected. > And there is no easy way to determine what a series of characters > represents in memory. Security by Obscuity doesn't work. > You could request a garbage collection after you have finished with the > password, then create a large garbage String from a random number > genrator. This might over-write the memory. Not necessarily. You can't be sure that System.gc() actually initiated the garbage collection and that the newly created string will overwrite the memory occupied by the password before. > All of this requires that the attacker has physical access to the > server and has the rights to be able to run a memory dump program, and > that the OS allows access to areas of memory not belonging to the > program. Not to forget Java Reflection. > I would be more worried about a key logger on the client machine where > a user enters the password into a Web browser. But if a user's account is cracked it's a better feeling for yourself if you can say "It surely didn't happen here but must have happened somewhere else". Best regards, Lothar -- Lothar Kimmeringer E-Mail: spamfang@kimmeringer.de PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81) Always remember: The answer is forty-two, there can only be wrong questions! --- * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet! --- Synchronet 3.15a-Win32 NewsLink 1.92 Time Warp of the Future BBS - telnet://time.synchro.net:24