Password Hashing in Authentication Service
We are integrating with LDAP for authentication for our operators to login to our Pega applications. We configured this using the Authentication Service leveraging on the Pega OOTB LDAP service provider JNDI (com.sun.jndi.ldap.LdapCtxFactory) and implementing Secured LDAP. In the Authentication Service, we have specified the Bind Distinguish Name and Bind Password.
I would like to know, if I configure password hashing as SHA-256 in my prconfig (implementing <env name="crypto/onewayhashalgorithm" value="SHA-256"/>), does Pega apply this hashing algorithm to the Bind Password I have saved in my LDAP Authentication Service?
Thanks
***Moderator Edit: Vidyaranjan | updated SR details***
***27/07/2017: Updated by moderator: Lochan to add documentation feedback request ID***
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Pegasystems Inc.
IN
Bind Password is sent to LDAP for its service authentication. We do not use one-way hashing to store this password in Pega. Instead, we encrypt (decryptable) the password and store in Pega.
The config setting applies only to properties of type Password (Pega property type). The bind password is no such type and is therefore unaffected by this setting.
OCBC Malaysia
MY
I’m sorry but you are still not answering our concerns.
If whatever settings we configured for password hashing in prconfig is not going to apply to this Bind Password for LDAP service authentication and instead; you mentioned that Pega will encrypt/decrypt and store in Pega, could you let us know what algorithm or standard you apply for your encrypt / decrypt?
I’m sorry but you are still not answering our concerns.
If whatever settings we configured for password hashing in prconfig is not going to apply to this Bind Password for LDAP service authentication and instead; you mentioned that Pega will encrypt/decrypt and store in Pega, could you let us know what algorithm or standard you apply for your encrypt / decrypt?
Is the standard equivalent or more secure than Triple DES? If we do not know the standard, then how Pega guarantee that a hacker hacking into our Pega database will not be able to easily decrypt and stole the password and subsequently use it to hack the LDAP, and steal all the login credentials from our LDAP?? Pls address this concern as we need to know the capability of Pega to ensure what we build in your product is going to be secure.
Pegasystems Inc.
IN
PRPC uses Cipher mechanism to transform/encrypt the 'Bind password'
To know more information and to customize site-specific cipher implementation please go through the following link.
https://pdn.pega.com/security/how-to-encrypt-passwords-properties-and-blobs
OCBC Malaysia
MY
Thanks for the article but it is still not answering the question. When it mentioned that the type of encryption used by default is the "Process Process Commander reversible portable cipher, which is the same across all PRPC implementations and requires no additional effort " what is the standard applied for this portable cipher?
Pegasystems Inc.
IN
OCBC Malaysia
MY
Hi kakul,
Isn't it that Mr. patnv already replied above that the LDAP authentivation Bind Password is not hashed? He said it is encrypt & decrypted by Pega. Sharing the article on hashing does not answer anything since that password is not covered by hashing also. In fact, the original question is asked due to that article did not confirm that the password in authentication service is covered. So what is the point we refer that article again? Thanks
Cognizant
GB
Hi LyeFongC, perhaps the answer to your question is Yes. Although I cannot personally confirm, I could help you validate this for yourself.
Here is an excerpt from Pega Security notes: All Password property values that are added after the change are stored by using the SHA-1 algorithm, and all the Password property values that are created before the change are stored by using the MD5 algorithm. All passwords continue to function normally, with no visible indicator as to which algorithm a specific password uses.
Also, refer these snapshots which (do not) reveal the Bind Password for an Authentication Service. Moreover, you will notice a similarity in the way the Operator Password and Authentication Service passwords have been (hashed and) stored in Pega.
Hi LyeFongC, perhaps the answer to your question is Yes. Although I cannot personally confirm, I could help you validate this for yourself.
Here is an excerpt from Pega Security notes: All Password property values that are added after the change are stored by using the SHA-1 algorithm, and all the Password property values that are created before the change are stored by using the MD5 algorithm. All passwords continue to function normally, with no visible indicator as to which algorithm a specific password uses.
Also, refer these snapshots which (do not) reveal the Bind Password for an Authentication Service. Moreover, you will notice a similarity in the way the Operator Password and Authentication Service passwords have been (hashed and) stored in Pega.
Which suggests that the Bind Password configured in an Authentication Service rule is hashed as well.
OCBC Malaysia
MY
Hi, Based on your answer, do you mean even when I apply SHA-256, the bind password for LDAP authentication services is still going to be hashed as SHA-1 only? I am quoting based on the excerpt you shared for Pega Security Notes which mentioned SHA-1 instead of saying that it will follow the configured hashing method from prconfig.
Thanks
OCBC Malaysia
MY
Hi pratikatwork,
Wonder if you are able to confirm how the Bind Password hashing works for the LDAP Authentication Service? Thanks
Pegasystems
IN
Since the bindpw has to be sent in original to ldap, we use reversible encryption. AES 128 is the default. We ensure the encrypted text is not same for a given text by adding salt to the formatted value, it's a two pass encryption.
We recommend customers to use site specific cipher if they want to use stronger algorithms.
The password hashing algorithm applies to the operator passwords, we don't store the original values of operator passwords. We do a hash comparison during login authentication.
Hope this answers your question.
Deutsche Bank
US
Where do you store the salt (I believe with salt, you need to store it somewhere to be able to decrypt or generate comparable hash)? Also, from the looks of all the passwords, they don't look to be straight-encrypted, but rather go through something like base64 transformation? Is this accurate description?
Deutsche Bank
US
I'm also facing the same question. We used MD5 (default hash) for 7.1.8, and the LDAP bindPW is stored using a reversible obfuscation algorithm. I'm pretty sure its NOT MD5 because MD5 is not reversible (yes, can be cracked, but officially its not reversible). This shows that the encryption algorithm is in fact reversible and something which a hacker can easily figure out. I suppose this is just obfuscation, and not really encryption, otherwise storing passwords to external systems in Pega would be pointless (similar to base64)
Now, when it comes to passwords, allegedly what you specify in your hash env setting is what pega encrypts the password with (currently set to SHA-512). However, it's not possible to verify that this is the case. When i review the operator record's pyPwdCurrent value, the value changes EVERYTIME I change the password for that operator (everytime changing it to the exact same password). So there is some additional level of obfuscation which Pega is applying to the password. I've reviewed the same links and documentation, and its once again not clear what is the actual mechanism Pega is using to encrypt/hash the password.
Can we have some more detail explanation on this behavior? At the current moment, it's not possible to verify that pega is in fact using a stronger algorithm when the encrypted password stream changes and the only visible difference is the length (which can easily be just padding)
Pegasystems Inc.
US