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

SHA1 is broken #19

Closed
BloggerBust opened this issue Aug 19, 2016 · 2 comments
Closed

SHA1 is broken #19

BloggerBust opened this issue Aug 19, 2016 · 2 comments

Comments

@BloggerBust
Copy link

According the the README passport-saml-encrypted uses RSA-SHA1 to encrypt SAML. Since SHA1 has been broken for quite some time now https://www.schneier.com/blog/archives/2005/02/sha1_broken.html. Are there plans to update the code to use a hash algorithm from SHA2?

@lmarkus
Copy link
Collaborator

lmarkus commented Aug 19, 2016

That's just for signing, not for the actual encryption of the assertion.

The provider is the one that decides the encryption scheme.
See https://github.com/lmarkus/passport-saml-encrypted/blob/master/lib/decryptSAML.js#L41-L50

@lmarkus lmarkus closed this as completed Aug 19, 2016
@BloggerBust
Copy link
Author

BloggerBust commented Aug 22, 2016

Thank you for the quick response. That makes sense, but in the readme there seems to be a contradiction.

Authentication requests sent by Passport-SAML can be signed using RSA-SHA1. To sign them you need to provide a private key in the PEM format via the privateCert configuration key. For example:

privateCert: fs.readFileSync('./cert.pem', 'utf-8')

Then a little farther down in the readme:

If the response is encrypted, you need to supply your public key to the SAML provider, and use your private key to decrypt the response. This is specified as:

 privateCert: fs.readFileSync('path/to/privkey.pem', 'utf-8')

The property privateCert seems to be used for both signing and decrypting? This is the root of my confusion. If the first statement is true then the private key being used to decrypt the SAML must be using SHA1. Rereading it now though I think that there must be a mistake in the readme? The property can't be used to both sign the SAML requests and decrypt the SAML responses, can it? If it is then doesn't that mean that the SAML is encrypted using SHA1?

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

No branches or pull requests

2 participants