On 11 March 2018 at 01:35, Tom Tervoort <tomtervo...@gmail.com> wrote:
> 32 > 16, so what's the problem? > ------------------------------- > > First of all, I'd like to point out that the three examples in the docs > (https://docs.python.org/3.6/library/secrets.html#generating-tokens) > explicitly generate 16-byte tokens. If the current > default is the most secure solution, why deviate from it here? > 1. For readability (as you say, shorter tokens *are* easier to read) 2. For independence from the default length setting > I think there a quite some situations where unnecessarily long codes can > cause usability problems: when using a system > where users have to manually type in a random code (I frequently have to > do that when using the password manager on my > phone, for example) it's nice if you can save half of the time they have > to spend on that. Shorter codes can also be > converted to smaller QR codes, and to nicer URLs. > > Sure, a user can always choose to just pick a value for nbytes and set > their own length. However, if they want to pick > a secure value, they are being tasked with considering the implications. A > user should be able to rely on the library > picking a good secure default. > I think security functionality should be made as ergonomic as possible, > without compromising security. When security > features unnecessarily create usability issues, people are discouraged > from using them in the first place. > "32 bytes is the conservative default, while 16 bytes is a common explicit override to improve token readability with little or no reduction in pragmatic security" is still pretty easy to use. With the API token generation examples already explicitly specifying 16 bytes, the only change needed to get to that state would be to amend https://docs.python.org/3/library/secrets.html#how-many-bytes-should-tokens-use to mention the readability question, and the fact that 16 is a reasonable choice in most cases. With the current setup, the ideal adoption cycle will see someone going: * It works, yay! * The tokens are a bit hard to read though, how do I improve that? * OK, I don't need the super-conservative 32 bytes, 16 bytes is fine, so I'll pass that in explicitly > > So yeah, that was my argument for making tokens 16 bytes long instead of > 32. Please let me know if and why I am > completely wrong:P > I don't think you're completely wrong, and I suspect if anyone had gone through this level of detailed analysis prior to 3.6, we might have made the default 128 bits of entropy instead of 256. As it is though, I think you've made the case for a docs change to make it explicit that 16 bytes of entropy is almost certainly going to be fine for practical purposes (which will benefit all users of 3.6+), but not for a reduction in the actual default (which would require invoking the "Hey, we said we might change it at any time!" caveat on the default length, and we included that caveat because we weren't sure of the potential future security implications of quantum computing, not because 32 byte tokens are harder to read than 16 byte ones) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
