<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 11 March 2018 at 01:35, Tom Tervoort <span dir="ltr"><<a href="mailto:tomtervoort@gmail.com" target="_blank">tomtervoort@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span style="font-family:monospace,monospace">32 > 16, so what's the problem?<br>------------------------------<wbr>-<br><br>First of all, I'd like to point out that the three examples in the docs<br>(<a href="https://docs.python.org/3.6/library/secrets.html#generating-tokens" target="_blank">https://docs.python.org/3.6/<wbr>library/secrets.html#<wbr>generating-tokens</a>) explicitly generate 16-byte tokens. If the current<br>default is the most secure solution, why deviate from it here?<br></span></div></blockquote><div><br></div><div>1. For readability (as you say, shorter tokens *are* easier to read)<br></div><div>2. For independence from the default length setting<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span style="font-family:monospace,monospace">I think there a quite some situations where unnecessarily long codes can cause usability problems: when using a system<br>where users have to manually type in a random code (I frequently have to do that when using the password manager on my<br>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<br>converted to smaller QR codes, and to nicer URLs.<br><br>Sure, a user can always choose to just pick a value for nbytes and set their own length. However, if they want to pick<br>a secure value, they are being tasked with considering the implications. A user should be able to rely on the library<br>picking a good secure default.<br></span></div></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span style="font-family:monospace,monospace">I think security functionality should be made as ergonomic as possible, without compromising security. When security<br>features unnecessarily create usability issues, people are discouraged from using them in the first place.<br></span></div></blockquote><div><br></div><div>"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.<br><br></div><div>With the API token generation examples already explicitly specifying 16 bytes, the only change needed  to get to that state would be to amend <a href="https://docs.python.org/3/library/secrets.html#how-many-bytes-should-tokens-use">https://docs.python.org/3/library/secrets.html#how-many-bytes-should-tokens-use</a> to mention the readability question, and the fact that 16 is a reasonable choice in most cases.<br><br></div><div>With the current setup, the ideal adoption cycle will see someone going:<br></div><br><div>* It works, yay!<br></div><div>* The tokens are a bit hard to read though, how do I improve that?<br></div><div>* OK, I don't need the super-conservative 32 bytes, 16 bytes is fine, so I'll pass that in explicitly<br></div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span style="font-family:monospace,monospace">So yeah, that was my argument for making tokens 16 bytes long instead of 32. Please let me know if and why I am<br>completely wrong:P<br></span></div></blockquote><div><br></div><div>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.<br><br></div><div>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)<br></div></div><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Nick.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>