bugtraq - Re: base64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3f727ccf.64320@achurch.org>
Date: Thu, 25 Sep 2003 14:20:44 JST
From: achurch@...urch.org (Andrew Church)
To: bugtraq@...urityfocus.com
Subject: Re: base64


>On Wed, Sep 24, 2003 at 03:13:57PM -0400, MightyE wrote:
>> I agree, I don't think it's unreasonable to reject improperly formatted 
>> messages.
>
>>   Take the low road 
>> catchall, and simply reject them as a matter of course.
>
>this runs counter to the maxim of Postel
><http://www.postel.org/postel.html>:
>
>"Be liberal in what you accept, and conservative in what you send." 

     It depends how you interpret it.  I'd interpret the rejection as being
conservative on the sending side--leaving the data as is would violate
_that_.  I could see an argument for correcting malformed data where
possible (e.g. cutting off all data after the first = sign), but that
raises the question of how to know that you're transmitting the same
content that the sender intended.  Particularly in cases like this, where
the standard is ambiguous, the only "safe" options with respect to
preserving the content are to send the data on as is or reject it entirely,
and in that case I think Postel's maxim would lean toward rejection; the
"liberal" part is only for data you can accurately interpret.

  --Andrew Church
    achurch@...urch.org
    http://achurch.org/