Le 10/10/16 à 23:40, Emmanuel Lécharny a écrit :
> Le 10/10/16 à 21:39, Steve Moyer a écrit :
>> Thanks for the kind words ... I was going to offer to be on your BOF panel
>> (since you were at the time a panel of one) but when I went to add the
>> session to my schedule, it was gone. It feels like we're making progress
>> with it here at PSU anyway.
>> I should have expected your answer below ... it didn't occur to me that each
>> of the password elements were one character in the actual password - I would
>> have expected them to be in a containing element too.
> The rational being 'you should use a char' is that you *can* blank the
> char just after having used it to store the password. Typically, you
> would do sometjing like :
> char password = grabPassword();
> doSomethingWithPassword( password );
> for (i = 0; i < password.len; i++)
> password[i] = '\0';
> You simply can't do taht with a String, as it's immutable. Using
> something like password = null; does not help either : you depend on the
> GC to reclaim the unused String, and it may take time.
> So, yes, using a char *may* sounds like the right thing to do.
> Now, consider that : you want to transmit the password to a remote
> server (over a Secured connection, obviously !).
> Obviously, you need to convert your char to something that is easy to
> transfert, lightweight, and that does not require a complex marshaling.
> Typically, you transfer hex values as String, so eating 2 chars per
> char. This is an acceptable solution.
> Note that in this case, you *will* trnasform your char to a String,
> which is, well, a mistake, for the exact reason we wanted to use char
> instead !!! Really dumb...
> My opinion is that there is no reason to use a char over a String for
> passwords, if you are going to transit them across a network. You first
> don't have a hand on how your doata are going to be converted to
> whatever format taht is going to be used under the hood, except if you
> manage the transmission yourself. Plus you need to be *very* careful on
> cleaning up he various char you have used to store the password, plus
> all the container in between your code and the socket (it's unlikely
> that the network layer is going to use zero-copy algorithm, which means
> a buffer will be copied, and not blanked afterward : you still depend on
> the GC !).
> But there is more : even if you use a char, there is a (short) period
> of time where your memory *will* contain a copy of your password.
> Shorter than for a String, but still. A malevolant piece of code taht
> periodically dump your memory will statistically be able to get a copy
> of your memory during this short period of time, giving it enough time
> to capture snapshot. And if your machine has already been poluted by
> malware, that means you haven't protected it well.
> Bottom line : people are freaking out, trying to enforce rules without
> having an understanding on what's going on in a system, and expect you
> to overdue, when some other more efficient mesure will do.
> Oerengeniering your cde is more likely to have some security impact than
> dead simple code that works well.
> Last, not least, String are immutable for mere mortal, not for a decent
> Java coder : you can have access to the char that stores the data in
> your String, if you want to blank it, thanks to reflection.
Forgot to mention that storing the password s provided (ie, 'secret',
for instance) is not a good idea. It does not fit the requirement that a
password may contain *any* char from 0x00 to 0xFF. We should end up with
a String that is a representation of the password in hex form :
736563726574 for 'secret'.