Comments (4)
random.SystemRandom()
is not a pseudorandom generator. The "pseudo-random generators" in question refers to the Mersenne Twister used by default if you call, e.g. random.randint()
In contrast, random.SystemRandom()
is a wrapper around os.urandom()
that should be a cryptographically-secure source of entropy provided by the operating system.
os.urandom(size, /)
Return a bytestring of size random bytes suitable for cryptographic use.
The short answer to the title question is, "No": what this library is doing is secure. Maybe there's a case to be made that it would be more obvious to call secrets.SystemRandom()
than random.SystemRandom()
but the secrets
module just imports random.SystemRandom()
the underlying implementation is identical.
from authlib.
I was indeed wrong about random.SystemRandom
being PRNG, my bad./dev/urandom
is a bit of an oddity in that it is a PRNG, seeded with true random data, quoting man urandom
:
When read, the /dev/urandom device returns random bytes using a pseudorandom number generator seeded from the entropy pool.
It's debatable, of course, whether the quality of randomness it produces is to be deemed sufficient for authlib
, and it's another debate altogether, I would say.
To come back to this issue, regardless of quality of /dev/urandom
in this context, having been well aware that secrets.SystemRandom
uses random.SystemRandom
under the hood currently, I still think that's long-term a dangerous assumption to rely on, also for the reason that [importing of] modules like random
or secrets
should communicate intent. Either one of these is free, as part of developing Python, to change how it works under the hood, and which modules it imports in turn, if at all, to continue abiding by the fundamental software contract documented for it and the service it advertises through objects its exports. Is authlib
effectively deferring the issue of the module it imports, to when the aforementioned assumptions start breaking? Is it not better to change the code now, at least for readability's sake but also to avoid the issue in the future altogether? And is it not slightly alarming that despite the clear discouragement by documentation of random
, authlib
, a popular offering dealing in security, chooses to rely on a mechanism which does not, strictly speaking, offer the software contract authlib
should demand?
To try and put it plainly, random.SystemRandom
does not have to effectively be CSRNG and is free to cease to be one, while authlib
by nature should require a CSRNG, which secrets.SystemRandom
is bound to offer.
from authlib.
The security of /dev/urandom
is almost certainly beyond the scope of this library.
As to the question of secrets.SystemRandom
vs random.SystemRandom
I think it's purely a matter of opinion. The secrets
module has existed only since Python 3.6, so to me, as a question of readability random.SystemRandom
is more familiar and obvious, but I don't feel that strongly about it, and others might disagree.
I think your concerns about possible future changes to the Python standard library are probably unfounded. The Python authors are surely well aware that random.SystemRandom()
is used for cryptographic applications, and they would not change it to a less-secure implementation.
from authlib.
I'll close this issue for now, as secrects.SystemRandom
is the same with random.SystemRandom
. However, we may use secrets.token_urlsafe
directly later in state generator or other things.
from authlib.
Related Issues (20)
- rfc7519 JsonWebEncryption is initialized with an incorrect list of algorhythms.
- Incorrect check for insecure transport on OAuth1.0
- Have special character encoding be optional HOT 1
- Quoting (URL-encoding) Base authentication username / password is incorrect HOT 7
- JWT authentication issue HOT 3
- Allow to disable expired token auto-refresh
- Need to be able to add headers when calling authorize_redirect() HOT 2
- do not have refresh token HOT 2
- JWTClaims accepts True/False `iat`.
- Too slow to generate id token with RSA HOT 1
- Token refresh failed when using AsyncOAuth2Client with client credentials
- getting no client id from vk.com oauth HOT 1
- Change token in session HOT 2
- Algorithm confusion when verifying JSON Web Tokens with asymmetric public keys HOT 5
- Support for plain code_challenge_method HOT 4
- Why self.form.get('grant_type') and not self.data.get('grant_type') ? HOT 10
- New token will not be fetched if grant_type='client_credentials' is passed for fetch_token()
- Unpinned Dependency on cryptography Breaks Installation Due to Rust Requirement HOT 1
- Python 3.12 support HOT 3
- EdDSA fails to decrypt JWTs
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from authlib.