Question

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.

Group Tags

Comments

Keep up to date on this post and subscribe to comments

Pega
April 24, 2017 - 9:41am

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.

April 24, 2017 - 10:09pm
Response to patnv

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.

Pega
April 25, 2017 - 9:20pm
Response to LyeFongC

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

May 8, 2017 - 9:18pm
Response to patnv

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?

Pega
July 13, 2017 - 11:30am
Response to LyeFongC

128/AES/PCBC/PKCS5Padding

Pega
April 25, 2017 - 2:18am

Hi,
Please go through this detailed document on password hashing. https://pdn.pega.com/about-password-hashing/about-password-hashing
Hope it is helpful

April 25, 2017 - 2:31am
Response to kakul

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

June 7, 2017 - 7:06pm

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.

June 22, 2017 - 10:39pm
Response to pratikatwork

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

June 28, 2017 - 5:48am
Response to LyeFongC

Hi pratikatwork,

Wonder if you are able to confirm how the Bind Password hashing works for the LDAP Authentication Service? Thanks

 

 

Pega
December 1, 2017 - 9:16pm
Response to LyeFongC

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. 

 

December 1, 2017 - 10:22pm
Response to Srikanth

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?

 

Pega
December 4, 2017 - 1:50am
Response to EugeneR7

Salt is stored along with the encrypted text and yes we do base64 to avoid problems during DB writes. 

December 1, 2017 - 4:59pm

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)

December 1, 2017 - 5:20pm
Response to EugeneR7

Hello!

 

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.

 

Thanks,

Marissa | Community Moderator | Pegasystems Inc.