I'm not proposing anything here. A limit of 4096 or even 256 would suggest limits for the reasons you mention. However, 28 bytes suggests more specific reasons. It's also short enough that diceware-like passwords [0] are untenable.
The question is whether there are technical reasons for choosing the value of 28 bytes, not whether we need a limit at all. https://theworld.com/~reinhold/diceware.html 2026年1月29日 13:19:54 JST、[email protected] より: >When you say arbitrary length, how many gigabytes, and what should the >system do when an attacker can force oom-kills in the auth server? > >no, there needs to be a limit somewhere. > >Quoth [email protected]: >> Hello 9fans, >> >> I'm trying to understand whether there are technical reasons for us (9front) >> having a 27-character limit on auth passwords. >> >> On 9front, this can be traced back to PASSWDLEN defined in authsrv.h. That >> constant was split off from ANAMELEN in commit 3c622887, and /doc/prog4.ms >> mentions that ANAMELEN is a vestige of when 9p used fixed 28-character >> buffers for paths, defined as NAMELEN. >> >> And this is where the trail runs cold. I am unable to find out why ANAMELEN >> exists at all. Key derivation functions should be able to handle arbitrary >> length passwords, so ostensibly PASSWDLEN is not needed in principle. Is >> this just a historical quirk, or am I missing something? >> >> I'm thinking it might be interesting to say something about this at iwp9, so >> any thoughts or discussion here is quite welcome. >> >> Cheers, >> B. Wilson ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te7acf42f92a5d9b6-M3ac6222f182a11e0164ae6d3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
