New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Swift: detect the use of constant passwords for password-based encryption #11063
base: main
Are you sure you want to change the base?
Swift: detect the use of constant passwords for password-based encryption #11063
Conversation
|
QHelp previews: swift/ql/src/queries/Security/CWE-259/ConstantPassword.qhelpConstant passwordDeriving password-based encryption keys using hard-coded passwords is insecure, because the generated key may be easily discovered. Data hashed using constant salts are vulnerable to dictionary attacks, enabling attackers to recover the original input. RecommendationUse randomly generated passwords to securely derive a password-based encryption key. ExampleThe following example shows a few cases of hashing input data. In the 'BAD' cases, the password is constant, making the derived key vulnerable to dictionary attakcs. In the 'GOOD' cases, the password is randomly generated, which protects the hashed data against recovery. References
|
| "qhelp.dtd"> | ||
| <qhelp> | ||
| <overview> | ||
| <p>Deriving password-based encryption keys using hard-coded passwords is insecure, because the generated key may be easily discovered. Data hashed using constant salts are vulnerable to dictionary attacks, enabling attackers to recover the original input.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sentence appears to be about constant salts and needs updating to be about passwords. The query @description claims the issue is about the password being recoverable from the source code (i.e. security through obscurity), though perhaps dictionary and other attacks become feasible with a constant password as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually modified the description compared to the query about salts to make it more specific to passwords, but perhaps my initial attempt wasn't good enough. I would like to actually differentiate between two scenarios:
- using a constant password for password-based encryption key derivation (which this query is about)
- hardcoding credentials (e.g., keys, passwords, user names).
The latter is more about CWE-798, and I think that's what you meant by recovering from the source code. On the other hand, this query is just about detecting the use of constant passwords to derive keys used for encryption. That's why this query is just checking that this info is not a constant value.
My conclusion from this discussion (and also while writing the query) is that we perhaps need another query for CWE-798 that checks for those hardcoded credentials.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case perhaps the query @description needs updating, as that's where the reference "potential attackers can easily recover them from the source code" comes from.
On hardcoded credentials, we have queries like cs/hardcoded-credentials (not ported to Swift as yet) for this but also rely on secret scanning (which is separate from codeql) for textually recognizable things like AWS keys (regardless of whether they're in source code or not).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I've now added a row about a cs/hardcoded-credentials-like query to the query prioritization board, I would welcome your thoughts on prioritizing it and which kinds of credentials it should cover)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still not sure I understand what is being said about salts and dictionary attacks - doesn't a constant password for key derivation enable more straightforward attacks than dictionary attacks?
| </example> | ||
|
|
||
| <references> | ||
| <li><a href="https://www.okta.com/blog/2019/03/what-are-salted-passwords-and-password-hashing/">What are Salted Passwords and Password Hashing?</a></li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we can find a reference specifically about constant passwords?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This RFC is more about the process where these passwords are stored. Do you think it might be more appropriate here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That looks like a good reference. No harm in having both if both are relevant.
Deriving password-based encryption keys using hard-coded passwords is insecure, because the generated key may be easily discovered. Data hashed using constant salts are vulnerable to dictionary attacks, enabling attackers to recover the original input.
The rule currently supports all ciphers that the CryptoSwift API provides, but we can always extend it further if more APIs are added.
I'd appreciate a review of the query itself, the accompanying tests, and the associated documentation.