As per my knowledge and research which i have done over the internet, it seems that currently OPENAM does not support SHA-256 encryption. I am using SAML authentication in my project, and currently using old openfed jar which does not support the SHA 256 encryption. I went through the latest jar also and found that openam does not support it.
FYI ..
Following is the snippet of QuerySignatureUtil.java :
final String querySigAlg;
final String alg = privateKey.getAlgorithm();
switch (alg) {
case "RSA":
//Defaulting to RSA-SHA1 for the sake of interoperability
querySigAlg = SystemPropertiesManager.get(SAML2Constants.QUERY_SIGNATURE_ALGORITHM_RSA,
XMLSignature.ALGO_ID_SIGNATURE_RSA_SHA1);
break;
case "DSA":
//Defaulting to SHA1WithDSA as JDK7 does not support SHA256WithDSA
querySigAlg = SystemPropertiesManager.get(SAML2Constants.QUERY_SIGNATURE_ALGORITHM_DSA,
XMLSignature.ALGO_ID_SIGNATURE_DSA);
break;
case "EC":
querySigAlg = SystemPropertiesManager.get(SAML2Constants.QUERY_SIGNATURE_ALGORITHM_EC,
XMLSignature.ALGO_ID_SIGNATURE_ECDSA_SHA512);
break;
default:
SAML2Utils.debug.error(classMethod + "Private Key algorithm not supported: " + alg);
throw new SAML2Exception(SAML2Utils.bundle.getString("algorithmNotSupported"));
}
While going through the internet i have found the ticket https://bugster.forgerock.org/jira/browse/OPENAM-8627
But it seems that it was done only for .NET fedlet.
Can someone
Well firstly, SHA-256 is not an encryption algorithm.
Digital signatures can use SHA256 as digest algorithm, yes. As you can see in the source of the QuerySignatureUtil, the actual algorithm is now configurable and can take lots of different values. The configuration retrieval is done with the SystemPropertiesManager calls in your snippet, and the config can come from two places:
For fedlet: the properties should be defined in FederationConfig.properties.
For the OpenAM server, the settings can be found under the Common Federation Configuration in the Global settings.
If you want to take a look at the digital signature implementation, then there are two classes of interest:
FMSigProvider: this class deals with proper XML signatures, all the digital signatures will be part of the XML document as per xmldsig spec.
QuerySignatureUtil: this class mainly deals with querystring signing, which has different set of rules than regular XML signatures. In this case the signature will not be part of the signed XML document, instead the signature will be put on the query string. The SAML binding spec that describes the HTTP-Redirect binding discusses this in more details.
If you want to control the DigestMethod value within the digital signature, then you need to have a look at OPENAM-7778, that was implemented in 13.5.0.
If you want to encrypt SAML messages using 256 bit encryption algorithms, then you will need to install the JCE jurisdiction files, after that, you should be able to configure http://www.w3.org/2001/04/xmlenc#aes256-cbc as XML encryption algorithm.
Related
We are trying to automate certain processes with Chilkat.
In particular we are trying to generate a PKCS7 document that contains the following features:
A signed xml document. This signing is done via smartcard and the
output must include the signature. For this point, we are using the
crypt2 object with :
EncodingMode, HashAlgorithm and charset attributes
SetSigningCert, OpaqueSignStringENC methods
We need also to include the signer's digital signature certificate in X.509 ASN encoding.
This second point is where we are having some problems.
We have obtained a valid signed document according to the 2 points through the createp7m method for manual testing but the point of our program is to automate the process in memory. Therefore, we are trying to use the OpaqueSignStringENC("original xml to sign") but we believe the point (2) is not being taken into account.
I don't know if anyone has encountered a similar problem. I just recently started working with encryption, certificates...sorry if I am explaining myself incorrectly.
Thanks everyone for your help and time
On the official Encrypt() doc page, it lists a number of RSA BSafe Crypto-J library encryption options for ColdFusion Enterprise, which I'm using. Under the Usage heading, it lists RSA PKCS#1 v1.5 (sign, verify) (SHA-1,SHA-224,SHA-256,SHA-384,SHA-512), of which I want to use the SHA-256.
I've tried the following as the algorithm parameter, some of which I found googling:
RS256
SHA-256
SHA256
SHA256withRSA
sha256WithRSAEncryption
The result is always an error, e.g. for the first one above:
The RS256 algorithm is not supported by the Security Provider you have chosen.
How do I check the Security Provider I apparently have chosen? I don't see anything about it in ColdFusion Administrator.
What is the correct string, in my case, to pass as the algorithm parameter?
I have relatively less idea about encryption but i have done research on encryption in spring boot in application.properties file but i have not found any material based on multiple password encryption.If someone could provide some material or some direction as to how i would proceed will be helpful
Basically you got to do 3 things.
1. Encrypt your password using jasypt.This can be done using command line tool as indicated here or using a simple java program as indicated here. You need a password along with the string you need to encrypt. password is something like a secret key(or salt) which is used to encrypt the string you want to encrypt.
2. Add this to your application properties or yml jasypt.encryptor.password=password_used_in_the_previous_step
3. And add the encrypted password you got from step 1 like this ENC(Your_Encrypted_Password)
Add the necessary dependencies.
Here is a good example.
https://github.com/ulisesbocchio/jasypt-spring-boot.
Is it possible to "retarget" keys generated via the ncipher JCE API to pkcs11? I know that you can retarget via the generatekey command but I don't see how to do it to an existing JCE key. The first prompt is for the "source application" and the options don't seem to include JCE. Does it support other options beyond the ones listed there or should I be looking at a different way of retargeting?
The ultimate goal here is to export a couple keys (asymmetric and symmetric) that were generated via nCipher's JCE API (yes, I know that an HSM's job is to secure the keys and exporting is usually not a good idea but it is a requirement here). We are able to export keys that were generated via the PKCS11 interface but not ones that were generated via the JCE so our thinking is that if we can retarget it from JCE to PKCS11 we might be able to export these keys as well. If there is another way to do this we are open to that as well.
Lastly, the JCE keys show up as "recovery enabled" when executing the nfkminfo on them. Does that mean that they are exportable or does recovery here mean something else?
Disclaimer: I work for Thales e-Security but do not speak for the company.
Yes you can retarget a jcecsp key to pkcs11. If you have any jcecsp keys in your kmdata/local, /opt/nfast/bin/generatekey will offer jcecsp as a source option. If you have no keys of that ilk, it will quietly omit that option from the source list. However, this retarget process may not do what you think it does. All retargeting does is change the application type and potentially the associated metadata: it doesn't change the fundamental capabilities of the key as those were baked into the protected key blob at generation time and cannot be changed.
The Security World uses nShield key ACLs to limit the key's capabilities (Sign, Verify, Encrypt, Decrypt, Wrap, Be Wrapped, etc.). PKCS#11 pulls its parameters (CKA_SIGN, etc.) directly from the key ACLs, and when generating keys through the API, the ACLs saved in the key blob are derived directly from the parameters in the key template. If you set CKA_SENSITIVE to FALSE, and your Security World allows it, you can generate and save an exportable key. JCE is not that sophisticated: it has no concept of key capabilities at all, so the Provider has to guess at the user's intent with the key and it defaults to a fairly generous set. However, since as you point out the whole idea of HSMs is to protect key bits and not let you have them, Export is not one of the defaults. And what's not baked into the key file when you create it, you don't get by retargeting the key.
One thing you could do if you want to use JCE is to generate the key using a different Provider and then store it in an nCipher.sworld KeyStore using the nCipherKM Provider: this will import the key into the Security World (if your World allows that) and save it as a key_jcecsp_* file. However this has nothing to do with key security so from an HSM perspective it's not recommended. Another thing you could do is to drop down to the native nCore API, generate the key with the ACL entries you require, and then polymorph it to a JCE Key Object and save it in the HSM-backed KeyStore. You can shoot yourself in the foot as many times as you want with the ACLs on the key you create. The polymorphing is very poorly documented: ask Thales Support and they can guide you.
Finally, the Recovery capability means that in addition to the Working Key blob which may be protected by an Operator Card Set, the key file has a Recovery Blob. This is in case that Operator Card Set is lost: the Recovery Blob can be opened up by the Administrator Card Set of the Security World using the rocs utility (Replace Operator Card Set), which will write a new key file under a new OCS. No, this does not mean the key is exportable. It just means that you are protected against losing the OCS. Of course losing the ACS is a non-starter as that is your Root of Trust.
I found that Meteor default use sha-256 to hash password. but I am confused that same password for each account after hashing become different string stored in the database. Anyone would tell the detail implementation, thx
Per the Meteor docs, accounts-password uses bcrypt.
If you look at the source code of loginWithPassword, you should be able to find out where the salt is stored. As a second source, read MasterAM's answer to Laravel & Meteor password hashing which indicates that Meteor from 2011 on uses $2y$ hash strings, i.e. PHP CRYPT_BLOWFISH, which uses
CRYPT_BLOWFISH - Blowfish hashing with a salt as follows: "$2a$", "$2x$" or "$2y$", a two digit cost parameter, "$", and 22 characters from the alphabet "./0-9A-Za-z". Using characters outside of this range in the salt will cause crypt() to return a zero-length string. The two digit cost parameter is the base-2 logarithm of the iteration count for the underlying Blowfish-based hashing algorithmeter and must be in range 04-31, values outside this range will cause crypt() to fail. Versions of PHP before 5.3.7 only support "$2a$" as the salt prefix: PHP 5.3.7 introduced the new prefixes to fix a security weakness in the Blowfish implementation. Please refer to ยป this document for full details of the security fix, but to summarise, developers targeting only PHP 5.3.7 and later should use "$2y$" in preference to "$2a$".
Thus, look for the $2y$ string in the database, and extract the salt from it.