CWE ID 327: AbstractNamedCurve.java:94
ndk at sudonym.me
Fri Sep 23 05:24:13 UTC 2022
The sad answer is that the SP can specify which cipher suites are
acceptable to it through the use of metadata, but few IdP's actually honor
it. Shibboleth does.
but as one example:
azure-docs/howto-saml-token-encryption.md at main ·
Azure AD uses AES-256 to encrypt the SAML assertion data.
On Thu, Sep 22, 2022 at 11:05 PM Jeremy Karlson via users <
users at shibboleth.net> wrote:
> > Bummer. If the report can't provide more detail, then the only other
> thing I can think of is: Is there somewhere a list of the crypto algorithms
> that Veracode considers weak and that would trigger the CWE ID 327? If so,
> then we could probably cross-reference to the list of EC named curves we
> support by default and see if there is an intersection.
> Sorry for the delay in responding. I’ve spent the last couple of days
> doing other things, as well as thinking about this. There is no list of
> algorithms that Veracode considers weak that I know of; they seem to rely
> heavily on OWASP, and OWASP says:
> > "For asymmetric encryption, use elliptical curve cryptography (ECC) with
> a secure curve such as Curve25519 as a preferred algorithm. If ECC is not
> available and RSA must be used, then ensure that the key is at least 2048
> Since the file it refers to is very specifically an ECC file, and it
> doesn’t specify exactly which curve it has complaints about, I don’t see
> any way to know. I assume that some curves are better than others, but it
> doesn’t list any specifically as “don’t do this.”
> > Beyond that, EC keys are then used with the fundamental crypto
> operations of signing (ECDSA) and encryption (ECDH) over SAML protocol
> messages and/or data within them. I wouldn't characterize those as
> "negotiation" between systems, because there isn't a back-and-forth kind of
> exchange, it's one-sided really (unlike say TLS). But these fundamental
> crypto ops are used to secure the messages and data exchanged between SAML
> entities, which for standard Web SSO use cases is primarily Identity
> Providers and Service Providers.
> For my own education… If it’s one-sided, in this exchange, who is the
> specifier of which encryption mechanisms are used? In my case, my employer
> is the Service Provider, and we are not an Identity Provider. If it’s the
> Service Provider, then maybe I have a hope of disabling the offending curve
> (if I ever find it). If it’s the Identity Provider, then I think I’d have
> fewer options because we are limited by what all of the IdPs would be
> willing / able to do.
> — Jeremy
> For Consortium Member technical support, see
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users