obfuscation as default

[Carter Bullard]

OK, so taking Mark's suggestion, I added a configuration option to rarc
that describes the behavior, and gives a switch to conveniently turn it off.
We've now got manpage cover on the -x switch, and "ra -h" will print out
the -x option.

# When printing user data in Ascii, there are some protocols where
# argus may have captured plaintext passwords, such as telnet and
# pop email.  As a precaution, ra* programs will attempt to avoid
# printing plaintext passwords in the output.  When this option is
# enabled, plaintext after the string 'PASS ' will be over-written
# with 'x'.
#
# Commandline equivalent:  -x
#
#RA_OBFUSCATE_PASSWORDS=yes

So I'd like to leave the current default behavior, and use -x to turn it off.
Is this going to get closer to solving any issues?

Carter


On Jan 18, 2012, at 7:03 PM, John Gerth wrote:

> Elof's logic is sound. I'm for keeping obfuscation as the default
> and if the documentation is updated, I'm not sure how much
> emitting a message on stderr is worth.
> 
> Just my 2 cents....not trying to muddy the obfuscation waters,
> /J
> 
> On 1/18/12 3:58 PM, Carter Bullard wrote:
>> OK, the count is now  2 - 2.  The issue is valid, that we should not set
>> incorrect expectations.  We could print a warning to stderr, that ra.1
>> obfuscated content?
>> 
>> Carter
>> 
>> 
>> On Jan 18, 2012, at 6:21 AM, elof2 at sentor.se wrote:
>> 
>>> 
>>> First I thought like CS Lee, that it was backwards to obfuscate without asking for it on the commandline. That's why I reported it to the list in the first place.
>>> 
>>> Though, once Carter explained that the default was to obfuscate, to protect and prevent from accidental copy and paste of sensitive data into e.g. an email, I changed my mind.
>>> That is a cheap and simple protection from human mistakes that can get really embarrising/awkward if one paste the wrong data to e.g. a mailinglist.
>>> 
>>> So I vote for the Carter approach. Obfuscate in the clients by default and use -x to reveal the real data.
>>> 
>>> The real problem is that this was an undocumented feature. Once it's a known default (the new man pages), I only see benefits with the default obfuscation.
>>> 
>>> 
>>> Regarding that there are sensitive data in the binary argus file... It contain so much sensitive data that I always treat it as highly sensitive.
>>> I would think three or four times before sending an argus-logfile to e.g. a mailinglist, while a simple copy and paste of some ra output could possibly slip by.
>>> 
>>> /Elof
>>> 
>>> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120118/6276b367/attachment.bin>