Security

A Python secrets module

A recent discussion that we covered about the default Python random number generator (RNG) has now headed off in a different direction. There was concern that the default RNG (as provided by random.random()) is not cryptographically strong, but that it is used as if it were out of ignorance. That led to suggestions of defaulting to stronger random numbers, even though that would change Python's behavior for some programs.

Since then, though, there is another proposal on the table that led to the withdrawal of PEP 504, which was proposed in that earlier discussion. That PEP was not looked on favorably by Guido van Rossum, while Steven D'Aprano's pre-PEP for a "secrets" module drew immediate support from the Python benevolent dictator for life (BDFL). The proposal still has not been formally accepted, but it has turned into PEP 506 and looks to be bound for Python 3.6.

Since Python's default RNG (as provided by random.random()) is not cryptographically strong, Nick Coghlan (and others) proposed that, by default, Python should generate crypto-strength random numbers. For those use cases that require other attributes (such as reproducibility based on a seed value) the random module would continue to use the existing default RNG (based on the Mersenne Twister algorithm). That is the now-withdrawn PEP 504. Van Rossum and others were not happy to see the semantics of the random module change when there are already mechanisms available to generate random numbers for high-security purposes (os.urandom() or the random.SystemRandom class).

D'Aprano's approach is to step up a level. One of main complaints about the existing RNG is that users who do web searches for ways to generate passwords or tokens in Python invariably end up with recommendations for using the random module in unsafe ways. Instead of changing the random module to try to avoid unsafe uses, D'Aprano is proposing adding a new module that will provide both crypto-strength random numbers and higher-level functions to generate passwords, tokens, and other security-sensitive objects that require strong random numbers. It would, effectively, add "batteries" (after all, Python is said to have "batteries included") that would help users bypass the random module which is seen as "an attractive nuisance when it comes to generating (for example) passwords or secure tokens".

Van Rossum's response to the pre-PEP suggested that an initial set of functions that would be provided by the secrets module should be added to the PEP. As Tim Peters noted, that is an invitation for bikeshedding: "I'll get it started :-)". He proposed promoting some of the methods from the SystemRandom class to top-level functions in the secrets module (for things like randrange(), randbits(), and choice()). In addition, he listed four "token" functions that would produce various types of tokens:

 Token functions
    .token_bytes(nbytes)
        another name for os.urandom()
    .token_hex(nbytes)
        same, but return string of ASCII hex digits
    .token_url(nbytes)
        same, but return URL-safe base64-encoded ASCII
    .token_alpha(alphabet, nchars)
        string of `nchars` characters drawn uniformly
        from `alphabet`

As predicted, there was a fair amount of bikeshedding over various details of what Peters had suggested, but the basic concepts were not strongly opposed. Whether the token functions should return bytes or string types was discussed, and for those that return bytes, which encoding should be used.

Some of the names for the top-level rand*() functions were questioned, as was including some of the more derivative SystemRandom methods (e.g. randbelow() can easily be defined in terms of randrange()). There was also a question about providing a default for the number of bytes returned by the token*() functions. D'Aprano suggested using 32 as the default, with the understanding that that number may rise in the future, which seemed fairly non-controversial. The default is there to give naïve users a guideline for a current "hard-to-attack length".

As the discussion progressed, adding password generation to the secrets module seems to have fallen by the wayside, which is rather interesting since it was one of the prime motivators for the original discussion. Paul Moore suggested changing the name of the token_alpha() function to "password" or something similar. The idea would be to indicate to beginners that it is a starting point for the "generate a random password" task.

Coghlan was initially in favor of a password-generation function as part of the secrets module, but several others argued against it. To start with, the requirements for passwords differ wildly depending on their use. Some believe that secrets.password() (or its equivalent) would simply be used to generate default passwords to return from web applications, rather than in some kind of program to generate passwords to be used at various web sites. The alphabet requirements for the former are probably under the control of the programmer, while upper/lower case questions, punctuation restrictions, and other complications arise when generating passwords for other sites.

Brett Cannon pointed out that password generation is more painful than might be expected:

Marc-Andre Lemburg agreed, but suggested that "the general purpose functionality of having a function which returns a string of given length and characters from a given set is useful" for creating password generators of various sorts. Those functions should not use the word "password", however. Peters piled on with the naysayers, suggesting that the documentation could provide examples of how to generate passwords that build on the tools provided by the secrets module.

Coghlan then also agreed. He noted that, like the itertools module, secrets could add "recipes" for uses like password generation to its documentation. Down the road, password generation could be considered for addition to secrets, but it doesn't need to be done immediately, because "adding things later is relatively easy, while taking them away is hard". Meanwhile, secrets without password generation still solves problems he was hoping to see solved:

Python 3.6 is still quite a ways off, as it is currently planned for the end of 2016, so there is plenty of time for the contents of the secrets module to be fully fleshed out. From the discussion so far, though, there would seem to be no real barrier to its inclusion. As Coghlan said, it will provide a clearer story for generating random numbers in Python.

Comments (1 posted)

Security quotes of the week

Comments (1 posted)

Qubes OS 3.0 released

Comments (57 posted)

Ad-blocking extension AdBlock sold to new owner

Many online media outlets are reporting the news that ownership of the popular ad-blocking browser extension AdBlock has been sold to a new owner. Not to be confused with similarly named projects AdBlock Plus and AdBlock Edge, this AdBlock announced the news of the sale to its users in a pop-up window. TheNextWeb reports that AdBlock employees refused to identify the buyer. In related news, the new owner has decided to join the "Acceptable Ads" whitelisting program run by rival AdBlock Plus. An announcement on the AdBlock Plus site confirms the move, and notes that an "independent review board" will now decide which advertisements are included the Acceptable Ads whitelist. Public nominations for the board are said to be open.

Comments (58 posted)

activemq: information disclosure

Comments (none posted)

binutils: multiple vulnerabilities

Comments (none posted)

commons-httpclient: denial of service

Comments (none posted)

fuseiso: two vulnerabilities

Comments (none posted)

gdk-pixbuf: two vulnerabilities

Comments (none posted)

jenkins-script-security-plugin: unspecified vulnerability

Comments (none posted)

kernel: denial of service

Comments (none posted)

kernel: multiple vulnerabilities

Comments (none posted)

nodejs: denial of service

Comments (none posted)

openhpi: world writable /var/lib/openhpi directory

Comments (none posted)

openjpeg2: use-after-free vulnerability

Comments (none posted)

openjpeg2: code execution

Comments (none posted)

python-PyJWT: privilege escalation

Comments (none posted)

spice: multiple vulnerabilities

Comments (none posted)

webkitgtk: code execution

Comments (none posted)

zendframework: SQL injection

Comments (none posted)