Because Strings hold onto their internal char[], unreferencing a String
password means it hangs around in memory until the JVM garbage collects it.
If you can ever prevent it from becoming a String, keep it as a char[] or
byte[] -- then zero it all out before the array is unreferenced.
Paul
On M
On Mon, Jul 8, 2013 at 7:05 PM, Roger L. Whitcomb wrote:
> Well, that's what .Net did with SecureString, and OpenSSL did as well.
> There is a longer discussion here:
> http://stackoverflow.com/questions/8881291/why-is-char-preferred-over-st
> ring-for-passwords
> that talks more about the pros a
Well, that's what .Net did with SecureString, and OpenSSL did as well.
There is a longer discussion here:
http://stackoverflow.com/questions/8881291/why-is-char-preferred-over-st
ring-for-passwords
that talks more about the pros and cons.
The main reason I bring it up is that, even though it doesn
Or maybe a Password class that's tailor designed to obsfucate and zero
contents...
On 7/8/13 3:23 PM, "sebb" wrote:
>On 8 July 2013 23:05, Roger L. Whitcomb wrote:
>> I had a thought that it would be more secure to pass password data
>> around in VFS as byte arrays instead of String objects so
I would expect char[] or byte[] to be just as easily recognizable. People
have used them to store passwords because those data types can be zero'd
out; whereas, String is immutable and references are kept by the intern
mechanism of String. If the char[] or byte[] is ever converted to a String
(or o
I've seen char[] used for passwords instead of String, but not byte[]. As
soon as you use a byte[] for a String you need to track an encoding as
well.
Gary
On Mon, Jul 8, 2013 at 6:05 PM, Roger L. Whitcomb wrote:
> I had a thought that it would be more secure to pass password data
> around in
Also worth noting: an extensively developed [Citation Needed], open source,
java obfu tool (proguard) considers even proper String encryption to have
such little value as to not include it.
http://proguard.sourceforge.net/#FAQ.html
On Mon, Jul 8, 2013 at 6:26 PM, Mark Thomas wrote:
> "Roger L.
"Roger L. Whitcomb" wrote:
>I had a thought that it would be more secure to pass password data
>around in VFS as byte arrays instead of String objects so they could
>less easily be found by memory dumpers/scanners. This would apply (for
>instance) to GenericFileName constructor and access method
On 8 July 2013 23:05, Roger L. Whitcomb wrote:
> I had a thought that it would be more secure to pass password data
> around in VFS as byte arrays instead of String objects so they could
> less easily be found by memory dumpers/scanners. This would apply (for
> instance) to GenericFileName constr
I had a thought that it would be more secure to pass password data
around in VFS as byte arrays instead of String objects so they could
less easily be found by memory dumpers/scanners. This would apply (for
instance) to GenericFileName constructor and access methods, etc.
Obviously, at some point,
On 07/04/2013 10:20 PM, Benedikt Ritter wrote:
> Hi,
>
> we had this discussion lately where we talked about attracting new
> contributors for commons [1]. Over the past few days I've been thinking
> about this topic again and I've come to the conclusion that there are
> several things we could do
2013/7/8 sebb
> On 8 July 2013 09:44, Benedikt Ritter wrote:
> > 2013/7/8 sebb
> >
> >> On 8 July 2013 09:12, Thomas Vandahl wrote:
> >> > On 06.07.2013 16:10, Benedikt Ritter wrote:
> >> >>
> >> >> This may or may not be a problem when for creation of a git mirror by
> >> >> infra. But the qu
Hi,
I'm currently learning how to publish our sites. I've read through the docs
[1] and this should be as easy as checking a component out, updating to the
lastest parent and calling mvm clean site-deploy, right?
When I run this on BeanUtils (we have this [2] request to update the site)
it does a
It is unfortunate that most of ArrayUtils' methods do not support varargs
because they were originally created with the array argument first.
Semantically I think the concept of ArrayUtils#contains(Object, Object...
array) is more sensible anyway. There is actually no technical reason why
this me
Hi Matt,
I don't have an array of objects. I have some variables that need to be
checked whether are null or not.
if (obj1 != null && obj2 != null && obj3 != null && obj4 != null) {
// Do something...
}
To use ArrayUtils.contations(), I need to code something like:
if (ArrayUtils.contains(
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=27176&projectId=69
Build statistics:
State: Failed
Previous State: Failed
Started at: Mon 8 Jul 2013 17:20:01 +
Finished at: Mon 8 Jul 2013 17:20:51 +
Total time: 49s
Build Trigger: Schedule
Build
I don't know exactly why this thread is getting split, but I think several
of us are taking the implicit position that we shouldn't necessarily
include a separate utility method for things that can be accomplished with
existing utility methods. It's arguably best that these (and any?) classes
be k
Hi,
The proposed method is related to objects. As we have StringUtils.isBlank(),
isNotBlank(), isEmpty() etc., the ObjectUtils.isNotNull(Object... objs) is
intended to check if all objects are not null. So, instead of
if (obj1 != null && obj2 != null && obj3 != null && obj4 != null) {
// D
WRT #firstNonNull, I don't know why I couldn't find it before. I do now,
and I agree it would seem to fit better in ArrayUtils.
Matt
On Mon, Jul 8, 2013 at 10:04 AM, Jörg Schaible
wrote:
> Hi Matt,
>
> Matt Benson wrote:
>
> > On Mon, Jul 8, 2013 at 8:22 AM, Jörg Schaible
> > wrote:
> >
> >> H
Hi Matt,
Matt Benson wrote:
> On Mon, Jul 8, 2013 at 8:22 AM, Jörg Schaible
> wrote:
>
>> Hi Hen,
>>
>> Henri Yandell wrote:
>>
>> > I don't see any value having the first two methods - replacing the '=='
>> > sign is a bit too far in the 'provide simple methods' direction I think
>> :)
>> >
>>
On Mon, Jul 8, 2013 at 8:22 AM, Jörg Schaible
wrote:
> Hi Hen,
>
> Henri Yandell wrote:
>
> > I don't see any value having the first two methods - replacing the '=='
> > sign is a bit too far in the 'provide simple methods' direction I think
> :)
> >
> > I think the third method is already in Lang
Hi Hen,
Henri Yandell wrote:
> I don't see any value having the first two methods - replacing the '=='
> sign is a bit too far in the 'provide simple methods' direction I think :)
>
> I think the third method is already in Lang as:
>
> ArrayUtils.contains(array, null);
Well, no, this is n
On 8 July 2013 09:44, Benedikt Ritter wrote:
> 2013/7/8 sebb
>
>> On 8 July 2013 09:12, Thomas Vandahl wrote:
>> > On 06.07.2013 16:10, Benedikt Ritter wrote:
>> >>
>> >> This may or may not be a problem when for creation of a git mirror by
>> >> infra. But the question is, do we really need thi
2013/7/8 sebb
> On 8 July 2013 09:12, Thomas Vandahl wrote:
> > On 06.07.2013 16:10, Benedikt Ritter wrote:
> >>
> >> This may or may not be a problem when for creation of a git mirror by
> >> infra. But the question is, do we really need this directory or can we
> >> remove it?
> >
> >
> > We c
On 8 July 2013 09:12, Thomas Vandahl wrote:
> On 06.07.2013 16:10, Benedikt Ritter wrote:
>>
>> This may or may not be a problem when for creation of a git mirror by
>> infra. But the question is, do we really need this directory or can we
>> remove it?
>
>
> We can surely remove it. The reason I
2013/7/8 Thomas Vandahl
> On 06.07.2013 16:10, Benedikt Ritter wrote:
>
>> This may or may not be a problem when for creation of a git mirror by
>> infra. But the question is, do we really need this directory or can we
>> remove it?
>>
>
> We can surely remove it. The reason I kept the tempbuilds
On 06.07.2013 16:10, Benedikt Ritter wrote:
This may or may not be a problem when for creation of a git mirror by
infra. But the question is, do we really need this directory or can we
remove it?
We can surely remove it. The reason I kept the tempbuilds so far was
that they correspond to "rele
27 matches
Mail list logo
