Skip to content
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: Query for Use of an inappropriate cryptographic hashing algorithm on passwords #15122

Open
wants to merge 20 commits into
base: main
Choose a base branch
from

Conversation

geoffw0
Copy link
Contributor

@geoffw0 geoffw0 commented Dec 15, 2023

New query for Use of an inappropriate cryptographic hashing algorithm on passwords.

This query is designed to be used alongside the existing swift/weak-sensitive-data-hashing query, and I've made some adjustments to that query to avoid duplication and to make sure results are reported by the most appropriate query. Previously:

swift/weak-sensitive-data-hashing: password, credential or private info -> MD5 or SHA1 hash

Now:

swift/weak-sensitive-data-hashing: non-password credential or private info -> MD5 or SHA1 hash
swift/weak-password-hashing: password -> MD5, SHA1, SHA2 (including variants such as SHA-512), SHA3 hash

To do this I had to make passwords an explicit kind of sensitive data in Swift (SensitivePassword), and I added MAD syntax for it (sensitive-password). I also fixed the sensitive data regular expressions for mobile phone numbers, added a couple of missing sinks for sensitive data hashing, and made some class names consistent while I was working in this area.

TODO:

  • team review
  • docs review
  • DCA run

@geoffw0 geoffw0 added the Swift label Dec 15, 2023
@geoffw0 geoffw0 requested a review from a team as a code owner December 15, 2023 13:34
Copy link
Contributor

github-actions bot commented Dec 15, 2023

QHelp previews:

swift/ql/src/queries/Security/CWE-328/WeakPasswordHashing.qhelp

Use of an inappropriate cryptographic hashing algorithm on passwords

Using a insufficiently computationally hard hash function can leave data vulnerable, and should not be used for password hashing.

A strong cryptographic hash function should be resistant to:

  • Pre-image attacks. If you know a hash value h(x), you should not be able to easily find the input x.
  • Collision attacks. If you know a hash value h(x), you should not be able to easily find a different input y with the same hash value h(x) = h(y).
  • Brute force. If you know a hash value h(x), you should not be able to find an input y that computes to that hash value using brute force attacks without significant computational effort.
    All of MD5, SHA-1, SHA-2 and SHA-3 are weak against offline brute forcing, since they are not computationally hard. This includes SHA-224, SHA-256, SHA-384 and SHA-512, which are in the SHA-2 family.

Password hashing algorithms are designed to be slow and/or memory intenstive to compute, which makes brute force attacks more difficult.

Recommendation

Ensure that for password storage you should use a computationally hard cryptographic hash function, such as:

  • Argon2
  • scrypt
  • bcrypt
  • PBKDF2

Example

The following examples show a function that hashes a password using a cryptographic hashing algorithm. In the first case the SHA-512 hashing algorithm is used. It is vulnerable to offline brute force attacks:

let passwordData = Data(passwordString.utf8)
let passwordHash = Crypto.SHA512.hash(data: passwordData)

// ...

if Crypto.SHA512.hash(data: Data(passwordString.utf8)) == passwordHash {
    // ...
}

Here is the same function using Argon2, which is suitable for password hashing:

import Argon2Swift

let salt = Salt.newSalt()
let result = try! Argon2Swift.hashPasswordString(password: passwordString, salt: salt)
let passwordHash = result.encodedString()

// ...

if try! Argon2Swift.verifyHashString(password: passwordString, hash: passwordHash) {
    // ...
}

References

@geoffw0
Copy link
Contributor Author

geoffw0 commented Dec 20, 2023

DCA shows 4 result changes:

  • two new results for swift/cleartext-transmission, in SwissCovid__swisscovid-app-ios and signalapp__Signal-iOS, caused by phoneNumber sources (TP).
  • two lost results for swift/weak-sensitive-data-hashing in DanielZSY__RxCommonKit, inside a PBKDF1 library implementation (FP, I think, but I'm very much open to opinions on these).

The run also shows some "interesting" rows for stage timings, which look like they might be an unintended result of changes to the DCA rules (i.e. they shouldn't be flagged?). Overall analysis time is fine. I will look into this next year and most likely do another DCA run to confirm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant