passwords, Strings and memory dumps
Fred
Hi everyone,
I'm facing a problem here about password storage in a JVM.
Here's the problem:
An html page sends a login/password to a servlet. This servlet reads the
password through the getParamter method. The getParameter, thus, creates
a String that contains the password in clear text.
I cypher the password and store it for future use.
The problem is that the String that getParameter created is still there
... containing a clear text password. And a memory dump could allow
people to read this password.
My question is : Is there a way to totally discard a String's content
from the JVM's memory?
Thanks for your help.
Fred
---
* 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
Lothar Kimmeringer
Fred wrote:
> The problem is that the String that getParameter created is still there
> ... containing a clear text password. And a memory dump could allow
> people to read this password.
>
> My question is : Is there a way to totally discard a String's content
> from the JVM's memory?
Strings are special in Java and you can't discard them easily
or intentionally.
A common way to handle passwords in cryptographic applications
is the use of character-array where you set the entries to
zero before discarding the reference. Due to the way Java
manages the memory this way still not ensures that there areen't
any copies of the array-values sitting around, but it's better
that the use of Strings where the references are stored in a
specific pool to be able to fulfil the Java-specification where
the following must work:
String a = "hello";
String b = "hello";
assertTrue(a == b);
Best regards, Lothar
--
Lothar Kimmeringer E-Mail: spam...@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)
Always remember: The answer is forty-two, there can only be wrong
questions!
Fred
Lothar Kimmeringer a ocrit :
> Fred wrote:
>
>> The problem is that the String that getParameter created is still there
>> ... containing a clear text password. And a memory dump could allow
>> people to read this password.
>>
>> My question is : Is there a way to totally discard a String's content
>> from the JVM's memory?
>
> Strings are special in Java and you can't discard them easily
> or intentionally.
>
> A common way to handle passwords in cryptographic applications
> is the use of character-array where you set the entries to
> zero before discarding the reference. Due to the way Java
> manages the memory this way still not ensures that there areen't
> any copies of the array-values sitting around, but it's better
> that the use of Strings where the references are stored in a
> specific pool to be able to fulfil the Java-specification where
> the following must work:
>
> String a = "hello";
> String b = "hello";
> assertTrue(a == b);
I read indeed about the fact that Strings were special in Java. The
problem here is that I can't really figure out how to get rid of
Strings... :(
Reading the initial password (html -> servlet) is done through a String
(because getParameter gives its result in a String). Is there a way to
read an HttpServletRequest parameter without generating a String?
Besides this, after being read, the password is sent to a web service
via a method that awaits a String as parameter. The java sources for
accessing the web service are generated using WSDL2Java, and I'm not
sure that I'm able to tell that I'd rather use a character-array than a
String.
So I guess here that, internally, in my servlet, I would be able to
manage/store the password as a character-array. But the problem is more
in all the communication around the servlet (html -> servlet and servlet
-> webservice) that imply the creation of Strings. :(
any solution?
Thanks again.
Fred
Lothar Kimmeringer
Fred wrote:
> I read indeed about the fact that Strings were special in Java. The
> problem here is that I can't really figure out how to get rid of
> Strings... :(
As I said. Assume that you can't.
> Reading the initial password (html -> servlet) is done through a String
> (because getParameter gives its result in a String). Is there a way to
> read an HttpServletRequest parameter without generating a String?
Not that I'm aware of but you can't answer that without knowing
what implementation of the Servlet-API you are using. That means,
you can avoid the creation of String by implementing your own
Servlet-API-implementation, e.g. by downloading Jetty and changing
the corresponding class.
> Besides this, after being read, the password is sent to a web service
> via a method that awaits a String as parameter. The java sources for
> accessing the web service are generated using WSDL2Java, and I'm not
> sure that I'm able to tell that I'd rather use a character-array than a
> String.
Using Axis you can change the generated stubs from String to
char[] and implement a Serializer and Deserializer that is
taking care of the correct handling.
On the other hand you might change the whole concept of trans-
fering passwords themselves and change to a challenge/response-
system, where the password is used for encoding the challenge.
That way you don't have passwords as Strings in HTTP-requests
and even if somebody can sniff the data-transfer the password
is not revealed.
> So I guess here that, internally, in my servlet, I would be able to
> manage/store the password as a character-array. But the problem is more
> in all the communication around the servlet (html -> servlet and servlet
> -> webservice) that imply the creation of Strings. :(
>
> any solution?
Use a JVM-implementation that stores the Strings encrypted in
the memory ;-)
Best regards, Lothar
--
Lothar Kimmeringer E-Mail: spam...@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)
Always remember: The answer is forty-two, there can only be wrong
questions!
---
Wojtek
> Lothar Kimmeringer a écrit :
>> Fred wrote:
>>
>>> The problem is that the String that getParameter created is still there
>>> ... containing a clear text password. And a memory dump could allow people
>>> to read this password.
>>>
>>> My question is : Is there a way to totally discard a String's content from
>>> the JVM's memory?
>>
>> Strings are special in Java and you can't discard them easily
>> or intentionally.
>>
>> A common way to handle passwords in cryptographic applications
>> is the use of character-array where you set the entries to
>> zero before discarding the reference. Due to the way Java
>> manages the memory this way still not ensures that there areen't
>> any copies of the array-values sitting around, but it's better
>> that the use of Strings where the references are stored in a
>> specific pool to be able to fulfil the Java-specification where
>> the following must work:
>>
>> String a = "hello";
>> String b = "hello";
>> assertTrue(a == b);
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 (and longer until the memory the JVM occupied
is over-written). This way less memory is used since both a and b refer
to the same memory location. And this also explains why Strings are
immutable.
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. Indeed, such an action would quickly use up all
available memory when reading large files or in long running Web
applications.
So once the String object is garbage collected, the memory location is
available for another object, and can be over-written.
And there is no easy way to determine what a series of characters
represents in memory. A String object takes up memory, but the
reference to it exists somewhere else. Since you are using a servlet,
then the reference exists on the stack, while the String object exists
in the heap.
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.
> any solution?
Have you actually done a memory dump to see if the String value is
visible?
Don't forget that the series of characters coming from the Web browser
is placed into a String, then parsed out into a HashMap and then placed
into the request. So already you have two copies and you have not yet
extracted the String for processing.
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.
I would be more worried about a key logger on the client machine where
a user enters the password into a Web browser.
--
Wojtek :-)
Lothar Kimmeringer
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".
Wojtek
Lothar Kimmeringer wrote :
> Wojtek wrote:
>> 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.
Hey, this is not a wasted day, I just learned something!
> 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.
True.
And I forget to mention the memory swap file. Which would be an easier
point of access.
>> And there is no easy way to determine what a series of characters
>> represents in memory.
>
> Security by Obscuity doesn't work.
True. Though it does slow the attacker down. Which is the ultimate goal
anyway. There is no encryption system in existance which cannot be
cracked eventually. You can only strech the time it takes.
Hopefully the cracking time will be longer than the lifetime of the
sensitivity of the information.
And then some all-knowing C-level PHB will copy the data in clear onto
his USB key "for convienience" and lose it in a washroom at the strip
club...
--
Wojtek :-)
Fred
Wojtek a ocrit :
> Fred wrote :
>> Lothar Kimmeringer a ocrit :
Ok.
Thanks for your answers.
I understand here that, once the password is in clear text somewhere in
the transmission chain, it gets really really hard to get rid of it.
Maybe the right solution is to never transmit the password but only
transmit a hash of it.
Thanks again.
Fred
Maarten Bodewes
Fred wrote:
>
> I understand here that, once the password is in clear text somewhere in
> the transmission chain, it gets really really hard to get rid of it.
> Maybe the right solution is to never transmit the password but only
> transmit a hash of it.
Use a salt and multiple hashes (say 50) in a row to get rid of some
obvious security issues (replay attacks, just sending over the same hash
value). Even then, a bad password is a bad password so make sure there
is enough entropy in the password. Also make sure you don't allow
endless retries, you have an online system, so that should not be too
difficult to do.
Maarten
Roedy Green
<maarten...@xs4all.nl> wrote, quoted or indirectly quoted someone
who said :
>> I understand here that, once the password is in clear text somewhere in
>> the transmission chain, it gets really really hard to get rid of it.
>> Maybe the right solution is to never transmit the password but only
>> transmit a hash of it.
Note that password fields tend to the char[], not String. This makes
it possible to wipe the field without any danger of the value hiding
somewhere in unallocated space.
You don't even transmit a hash. You digitally sign a challenge phrase
from the server and send it back. The server knows only your public
key, not your private key.
This is all handled magically for you by the Authenticator class. See
http://mindprod.com/jgloss/authentication.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
"Here is a point of no return after which warming becomes unstoppable
and we are probably going to sail right through it.
It is the point at which anthropogenic (human-caused) warming triggers
huge releases of carbon dioxide from warming oceans, or similar releases
of both carbon dioxide and methane from melting permafrost, or both.
Most climate scientists think that point lies not far beyond 2蚓 (4蚌) C hotter."
~ Gwynne Dyer