3 ms·

Some people deride it as "C programmer mentality" when fields have a fixed maximum size. I too used to think having no limits at all was the best approach in m

• andyroid 13y ago
  "As for the choice of 4096, well, I would have chosen 4000 (or 1000) simply because it's more comprehensible from an end-user perspective." Why should an end-user need to comprehend a limit in bytes at all? Good points though!
  • Perseids 13y ago
    Specifically with UTF-8 it depends on the content how many characters fit in these 4096 bytes.
    • chrj 13y ago
      From the patch, it doesn't look like it's bytes, but characters.
      • Perseids 13y ago
        Where do you see this? In https://github.com/django/django/commit/aae5a96d5754ad34e48b7f673ef2411a3bbc1015#L3R405 https://github.com/django/django/commit/aae5a96d5754ad34e48b... they specifically mention bytes.
        • masklinn 13y ago
          MAXIMUM_PASSWORD_LENGTH is used as the max_length of CharField. CharField are unicode, and thus if one reads no further than django/contrib/auth/forms.py and doesn't see MAXIMUM_PASSWORD_LENGTH is also used on KDFs input (which work on bytes) one may get the impression that it's a limit on code units.
          • gsnedders 13y ago
            Then it's Unicode code points, which are still am abstract concept to users. The only thing that's meaningful to users is graphemes — and with Unicode one grapheme can be formed of a potentially infinite number of code points (continuation characters stack, and can be repeated indefinitely), so you cannot practically use that for any limit.
            • masklinn 13y ago
              "characters" is an unfortunately common shortcut for "code points" as that's what unicode-based "char" types tend to mean. And my comment was an explanation of an other user's, nothing more.
  • jzwinck 13y ago
    Mostly they shouldn't need to, but on the off chance it is documented somewhere, it may as well be a "big round number" in human terms rather than computer ones. I often wonder why programmers gravitate powers of two even in places where it doesn't matter (as opposed to say small datatype sizes, where powers of two are useful).
• Perseids 13y ago
  > But for many user input data, there is a point at which a longer value is complete nonsense. The reason I still prefer arbitrary length fields is that I otherwise have to determine the limit myself. And finding reasonable limits isn't always that easy. For example, quite a few sites have about 20 chars as maximum password lengths. Using xkcd's correct-battery-horse-staple method (or formerly most commonly known as diceware) this assumption already fails. Also, what is the correct maximum length for a surname? (See Janice Keihanaikukauakahihuliheekahaunaele.) And then there are these ridiculously short text fields for complaints or questions on sites like UPS that only allow like 400 characters (how these are encoded into bytes raises other questions about how reasonable that limit is). I'd argue it's more work to find out the right limits than to implement arbitrary length fields. In the case of PBKDF2 I would say it's the primitive's (PBKDF2's) fault for allowing a DOS on long passwords. I do not blame the designers though. I have read its definition several times and have never though about DOS attacks, too. Like with padding oracle or length extension attacks this should go on the check list for future designs and PBKDF2 should be phased out.
• ubernostrum 13y ago
  As for the choice of 4096, well, I would have chosen 4000 (or 1000) simply because it's more comprehensible from an end-user perspective. 4096 is a convenient power of 2, and is the same as the default limit enforced by passlib (a popular password-hashing tool in Python).