Posted: 19 Apr 2017 21:47 EDT Last activity: 4 Feb 2019 14:09 EST
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?
***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.
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.
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?
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
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.
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.
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.
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?
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)
Thank you for posting your query on PSC. This looks like an inactive post and hence, we suggest you create a new post for your query. Click on the Write a Post button that’s available on the top right pane of this page. Once created, please reply back here with the URL of the new post.
We have also sent you a private message opening up a communication channel in case you have any further questions.