http://qs321.pair.com?node_id=916162


in reply to RFC: SecureString - Obfuscated / masked strings exept when you need them

One question: what about Data::Dumper and friends? Sure what you've done is interesting, but if a password is part of a structure or object which gets dumped, you're no further ahead. I'd suggest storing the value as sub { $value }. At least it won't be so obvious then. Otherwise, I like it.

Oh yes. Also I don't think that the default obfusticator ought to use the length of the value in the masked string as that leaks information, i.e. the length of the value.

And I prefer Text::Masked

Replies are listed 'Best First'.
Re^2: RFC: SecureString - Obfuscated / masked strings exept when you need them
by duelafn (Parson) on Jul 22, 2011 at 18:04 UTC

    Yes, very important. I store the sensitive value Inside-Out, and incompatilibity with data serialization tools is one of the classic (dis)advantages of inside-out objects. The serializer simply can not access the sensitive data since the sensitive value is stored in a lexical variable in the Text::Hidden package.

    Since debugging is often done with these serialization tools, in future versions I intend to try to serialize as smartly as possible: make it clear in the serialized output that the value has been masked; warn or die if a de-serialized object is used. Of course, I can only support the most popular serializers, but even those which will not have built-in support will not be able to access the sensitive value - even if they dump code references.

    Regarding length of the value: Yes, I had waffled on that for a bit but for debugging purposes (detecting the empty string) went with length for now since overriding the obfuscated value to be a fixed string is easy. I will probably make the default a bit more safe/smart and even more debug-friendly in the next version. My plan now is to return: "«empty»" | "«undef»" | "XXXXX" (fixed length) as appropriate from the default obfuscator.

    Good Day,
        Dean