[Python-ideas] PEP 506: some thoughts on the output length of token_bytes (and why I think it should be split in half)

Nick Coghlan ncoghlan at gmail.com
Mon Mar 12 09:45:42 EDT 2018

On 11 March 2018 at 01:35, Tom Tervoort <tomtervoort at 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
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)


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180312/4b990630/attachment.html>

More information about the Python-ideas mailing list