Issue with insecure django-oauth-toolkit library

[panosangelopoulos]

After the latest update of the insecure.json file the Django-oauth-toolkit fails for below 2.0.0

Unfortunately, the django-oauth-toolkit latest version is 1.7.1.

Perhaps there is an error on that.

Links:
https://pypi.org/project/django-oauth-toolkit/#history
https://github.com/pyupio/safety-db/blob/master/data/insecure.json#L1841

[SCH227]

Good day, how are you?

The latest version of django-oauth-toolkit is affected by two vulnerabilities:
django-oauth/django-oauth-toolkit#1124
django-oauth/django-oauth-toolkit#1093

The issues have been tagged Milestone 2.0.0 (check also the links above). That's why we decided to warn our users about this with the specs range <2.0.0.

Thank you for contacting us. Here we are if anything else!

[panosangelopoulos]

@SCH227 Thanks a lot for your message
It seems both of them merged into master and were included in the 1.7.1 release of django-oauth-toolkit.

Perhaps it's fine to change it from 2.0.0 to 1.7.1

[SCH227]

@panosangelopoulos according to this, they weren't included:

https://github.com/jazzband/django-oauth-toolkit/commits/1.7.1

[n2ygk]

These are security BCP breaking changes-- not vulnerabilities. OAuth2 best practices have evolved over time.

[n2ygk]

@SCH227 This is not a vulnerability but best common practice (BCP) that we are moving toward. Please remove this from safety db. Use of oob is still supported by Google for 2 more weeks and hashing client secrets is a "good to have" but not an exposure.

[panosangelopoulos]

@n2ygk Absolutely agree; it's not a security issue but a best practice suggestion.
@SCH227 Shall I create a PR to drop it from the insecure.json file?

[SCH227]

@panosangelopoulos @n2ygk, I understand your concern.
However, we also choose to report when best common practices aren't followed.
A user may decide later that these issues don't represent a risk for their application and follow to ignore them using the --ignore flag. But to make the best decision, they need first to be informed.

Here are good resources on why these issues can be a risk:

django-oauth/django-oauth-toolkit#1104
[especially the links in "Additional context"]

django-oauth/django-oauth-toolkit#729
[consider too that most data breaches that leak passwords happen because of secrets stored in plaintext or weak hashing]

[n2ygk]

The problem is that users can't distinguish between a BCP vs. an actual security issue (like a log4j) in this case. I guess you are forcing me to release 2.0 prematurely.

[simara-svatopluk]

I can only agree with @n2ygk . I'm a BFU, and what I see

• CI job shows error
• It instructs me to upgrade to >= 2.0.0
• I want to upgrade
• The version doesn't exist :-(

What? I (and 3 of my colleagues) are searching the internet what is going on and what shall we do....

We have the safety-db installed because we want to avoid security problems, now it fails for not-security related issue.

[SCH227]

Update:

We have decided to remove these as vulnerabilities for now.
Part of the reason we've come to this decision is that right now it is quite hard to ignore or make exceptions about vulnerabilities using our Safety command-line tool. We are releasing soon a new version of our Safety CLI scanning tool that will make this much easier. When that happens, we will likely add these back as vulnerabilities, since there is precedence with other CVEs that plaintext storage of passwords can be considered something we want to warn our customers about.