6 ms·

Do not reference these kinds of docs whenever you need practical, actionable advice. They serve their purpose, but are for a completely different kind of audien

Do not reference these kinds of docs whenever you need practical, actionable advice. They serve their purpose, but are for a completely different kind of audience. For anyone perusing this thread, your first resource for this kind of security advice should probably be the OWASP cheatsheets which is a living set of documents that packages current practice into direct recommendations for implementers. Here's what it says about tuning Argon2: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#argon2id https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...

tptacek 11mo ago
It's been a couple years since I've looked but the track record of OWASP for cryptography advice has been pretty dismal.
- linsomniac 11mo ago
  Do you have a better recommendation? I feel bad for OWASP. They're doing the lords work, but seem to have a shoestring budget.
  - rubendev 11mo ago
    The OWASP ASVS appendix on Cryptography is one of the best and concise resources I know for this kind of thing: https://github.com/OWASP/ASVS/blob/master/5.0/en/0x92-Appendix-C_Cryptography.md#hash-functions-for-password-storage https://github.com/OWASP/ASVS/blob/master/5.0/en/0x92-Append...
    - akerl_ 11mo ago
      I’d wager that something like 90% of developers who look at that page should close the tab instead of reading any of it. If you’re building a system and need crypto… pick the canonical library for the ecosystem or language you’re working in. Don’t try to build your own collection of primitives.
      - rubendev 11mo ago
        Yes I fully agree. I’m a big fan of libraries like Google Tink that make you pick a use case and use the best implementation for that use case with built in crypto agility. Most crypto libraries are not built like that however. They just give you a big pile of primitives/algorithms to choose from. Then frameworks get built on top of that, not always taking into account best practices, and leave people that are serious about security the job of making sure the implementation is secure. This is the point where you need something like ASVS.
        akerl_ 11mo ago
        What language today still doesn't have a de facto simplified toolbox for wrapping crypto operations? If you're a developer, and you start trying to perform crypto operations for your service and the library you chose is making you question which cipher, what KDF parameters, or what DH group you want, that is 100% a red flag and you should promptly stop using that crypto library.
        rubendev 11mo ago
        Can you give some examples of such commonly used libraries for languages like Java / C# / C++? In my experience there are not many libraries like Google Tink around, and they are not in widespread use at all. Most applications doing encryption manually for specific purposes still have the words AES, CBC, GCM, IV etc hardcoded in their source code. If you review such code, it’s still useful to have resources that show industry best practices, but I agree that the gold standard is to not have these details in your own code at all.
        akerl_ 11mo ago
        I'd probably look at https://libsodium.gitbook.io/doc/bindings_for_other_languages https://libsodium.gitbook.io/doc/bindings_for_other_language... or https://nacl.cr.yp.to/box.html https://nacl.cr.yp.to/box.html
      - rubendev 11mo ago
    - tptacek 11mo ago
      This is just a random list of links to standards and summary tables, some of which are wrong (urandom vs. random, for instance). The "A/L/D" scoring makes very little sense. CBC is legacy-allowable and CTR is disallowed; "verification of padding must be performed in constant time". For reasons passing understanding, "MAC-then-encrypt" is legacy-allowable. They've deprecated the internally truncated SHA2's and kept the full-width ones (the internally truncated ones are more, not less secure). They've taken the time to formally disallow "MD5 and SHA1 based KDF functions". There's a long list of allowed FFDH groups. AES-CMAC is a recommended general-purpose message authenticator. This is a mess, and I would actively steer people away from it.
      - rubendev 11mo ago
        Yes it’s an audit checklist for when you need to know specifically what to use and with which parameters. It’s unfortunate if there are mistakes in there. The people at OWASP would be very happy to receive feedback on their GitHub I’m sure.
        tptacek 11mo ago
        It's a bad audit checklist! If OWASP volunteers can't do a good one, they should just not do one at all. It's fine for them not to cover things that are outside their expertise.
        rubendev 11mo ago
        Which one would you recommend instead? Referring dev teams to NIST standards or the like doesn’t work well in my experience.
        tptacek 11mo ago
        There doesn't always have to be a resource. Sometimes no resource is better than a faulty one. Cryptography is one of those cases.

tptacek 11mo ago

It's been a couple years since I've looked but the track record of OWASP for cryptography advice has been pretty dismal.

linsomniac 11mo ago
Do you have a better recommendation? I feel bad for OWASP. They're doing the lords work, but seem to have a shoestring budget.
- rubendev 11mo ago
  The OWASP ASVS appendix on Cryptography is one of the best and concise resources I know for this kind of thing: https://github.com/OWASP/ASVS/blob/master/5.0/en/0x92-Appendix-C_Cryptography.md#hash-functions-for-password-storage https://github.com/OWASP/ASVS/blob/master/5.0/en/0x92-Append...
  - akerl_ 11mo ago
    I’d wager that something like 90% of developers who look at that page should close the tab instead of reading any of it. If you’re building a system and need crypto… pick the canonical library for the ecosystem or language you’re working in. Don’t try to build your own collection of primitives.
    - rubendev 11mo ago
      Yes I fully agree. I’m a big fan of libraries like Google Tink that make you pick a use case and use the best implementation for that use case with built in crypto agility. Most crypto libraries are not built like that however. They just give you a big pile of primitives/algorithms to choose from. Then frameworks get built on top of that, not always taking into account best practices, and leave people that are serious about security the job of making sure the implementation is secure. This is the point where you need something like ASVS.
      - akerl_ 11mo ago
        What language today still doesn't have a de facto simplified toolbox for wrapping crypto operations? If you're a developer, and you start trying to perform crypto operations for your service and the library you chose is making you question which cipher, what KDF parameters, or what DH group you want, that is 100% a red flag and you should promptly stop using that crypto library.
        rubendev 11mo ago
        Can you give some examples of such commonly used libraries for languages like Java / C# / C++? In my experience there are not many libraries like Google Tink around, and they are not in widespread use at all. Most applications doing encryption manually for specific purposes still have the words AES, CBC, GCM, IV etc hardcoded in their source code. If you review such code, it’s still useful to have resources that show industry best practices, but I agree that the gold standard is to not have these details in your own code at all.
        akerl_ 11mo ago
        I'd probably look at https://libsodium.gitbook.io/doc/bindings_for_other_languages https://libsodium.gitbook.io/doc/bindings_for_other_language... or https://nacl.cr.yp.to/box.html https://nacl.cr.yp.to/box.html
    - rubendev 11mo ago
  - tptacek 11mo ago
    This is just a random list of links to standards and summary tables, some of which are wrong (urandom vs. random, for instance). The "A/L/D" scoring makes very little sense. CBC is legacy-allowable and CTR is disallowed; "verification of padding must be performed in constant time". For reasons passing understanding, "MAC-then-encrypt" is legacy-allowable. They've deprecated the internally truncated SHA2's and kept the full-width ones (the internally truncated ones are more, not less secure). They've taken the time to formally disallow "MD5 and SHA1 based KDF functions". There's a long list of allowed FFDH groups. AES-CMAC is a recommended general-purpose message authenticator. This is a mess, and I would actively steer people away from it.
    - rubendev 11mo ago
      Yes it’s an audit checklist for when you need to know specifically what to use and with which parameters. It’s unfortunate if there are mistakes in there. The people at OWASP would be very happy to receive feedback on their GitHub I’m sure.
      - tptacek 11mo ago
        It's a bad audit checklist! If OWASP volunteers can't do a good one, they should just not do one at all. It's fine for them not to cover things that are outside their expertise.
        rubendev 11mo ago
        Which one would you recommend instead? Referring dev teams to NIST standards or the like doesn’t work well in my experience.
        tptacek 11mo ago
        There doesn't always have to be a resource. Sometimes no resource is better than a faulty one. Cryptography is one of those cases.