Hello Guys,
Is there any way to decrypt Source Password in IDN ?
I know that there is no decryption in IDN, but checking if there is any offline standalone tool to decrypt.
Why do I need this ?
Unfortunately, old developers didn’t store the passwords anywhere like a vault/safe. Now either I need to reset the password of service account for all sources or I need to request for new Service account.
Thanks
Krish
There is not. This is by design, and good, as it encourages best-practices (as you’ve just found).
Passwords are encrypted by the server, secured by PKI. Even in the case where you encrypt a password locally for import into IDN, you have to first fetch a public key to use for encryption.
I agree with you, but I feel recommendations or good practices are to be followed but never forced. There should be an offline tool to decrypt the passwords. Doesn’t matter how great your design is, bad things will happen.
Hi @MVKR7T , passwords stored in Source configuration cannot be decrypted using any tool from my best understanding, as it is assumed that passwords are managed and maintained by customer in their respective preferred Password Management Tool or Vault/Safe as you mentioned.
You might have to reset passwords or get a new service account whichever possible, but this will be a one-time activity as you can take this opportunity and store passwords into the best practice methods which you said above.
Hey Krishna, i agree with you 100% it would have been great if we had a place to decrypt passwords (if only in the sandbox env) in IDN. Of course, with the correct rights in place ie. restricting the capability to only admins.
Totally agree - If passwords can be decrypted out of band that is HUGE security risk and I’d be wary of any vendor that provides this functionality.
Absolutely. If anybody except IDN’s engine can decrypt the values, then that’s an attack route. Any attacker worth their salt in 2023 must be assumed to have the ability to masquerade as you, especially in a cloud environment.
Also, even on the secure path, your IDN admins aren’t necessarily the same people who have access to those passwords. I don’t know that I’d want my IAM team having the clear-text password to CORP-AD\Administrator, or the ability to get it.
Ok, Thanks for your answers. I too know the standards, attacks and recommendations.
Let me clarify, my question is very simple, just YES/NO Is there any password decryption tool in SailPoint IDN which is not known to the outside world, I wish that some SailPoint employee confirms here.
NO! Sailpoint definitely doesn’t supply this and if anyone confirmed here that they had such a tool, I would expect some serious repercussions considering that violates standard behaviors in a development community.
Effectively what you’re asking is if the vendor, or anyone else, has an undocumented backdoor which is CRAZY! If you know and understand the standards, then there’s no point in even asking for this.
Apologies if I sound harsh, but this is core security principles and asking for hacks is not what we should be doing.
I like to put an end to this, because this is not about debating whether Password decryption should be there or not. I am checking here if it is available or not. If SailPoint decided to not to decrypt at all, then that is fine. They will give their own reasons for it.
I believe you might have knowledge about SailPoint IIQ where we can decrypt using context, password which is encrypted at one IIQ can be decrypted in same IIQ not in other environments. Same goes with Windows encryption as well. Encrypted can be decrypted by following security protocols.
I would say we can do the same in IDN, If you are really in the context here, I am not asking to decrypt the password outside completely independent of IDN. We can have an API to decrypt the password which will be inside IDN engine, or a CLI command or a feature in SDK where you have to enter your tokens. If not we can have a stand alone tool as well, where you supply tokens so that it is secured decryption.
We all have opinions and that is good.
If you’re asking about whether it’s possible, then yes, SailPoint can conceptually decrypt your passwords. After all, they can bypass their own Rule criteria and run context.decrypt in any customer’s IDN tenant. For that matter, they could just update the tenant’s backend codebase with one that logs out the secrets to a log file.
Secrets in source configuration are stored encrypted, not hashed, because a real credential (not a hash of one) is usually required to connect to external systems. There appear to be two different forms of them, one that looks like PKI (starts with 2_) and one that’s the same as IIQ (1:).
I hope they would refuse to do so.
Short answer is yes. Long answer, all password in all systems can be decrypted, it depends on the money you are able to spend on performing the attack.
Hi all - I see a variety of replies here and I would like to set some things straight from the SailPoint perspective. Source passwords are always encrypted and stored in an encrypted database.
There is no product feature or ability to decrypt these passwords from a customer, partner, or implementer perspective.
For sources that use virtual appliances, these sources leverage a Zero Knowledge Encryption scheme, where the source passwords are encrypted using the virtual appliance cluster’s public key. The SailPoint cloud cannot decrypt these passwords, because we do not have the private decryption key, which is located on the virtual appliance itself. Whenever connectors are run, the connector engine on the virtual appliance will decrypt any encrypted values using the virtual appliance decryption keys, and hand that to the connector that is executing. There is no implementation interaction with any of that.
For sources that use SaaS connectivity, these sources leverage a different encryption scheme which SailPoint has both encryption and decryption keys. The SailPoint cloud can decrypt these passwords, because that is where the connector executes (for SaaS to SaaS communication). When connectors are run, the connector engine in the cloud will decrypt any encrypted values using the virtual private keys, and hand that to the connector that is executing. There is no implementation interaction with any of that.
Rules do not have the ability to call context.decrypt(...) like you can in IdentityIQ. These types of functions have been stripped out of the prototypical contexts in the virtual appliance and in the cloud; this means that nothing will happen. Moreover, rule validations will fail for including these commands. For cloud rules, these will fail rule validation on import if you include these commands. For connector rules, the API will reject rules if that particular method is found.
SailPoint recommends storing a copy of credentials in Privilege Access Management (PAM) or Key Management Systems (KMS) vaults, and cycling source credentials on a routine basis. SailPoint source APIs can be integrated with these types of systems so we can be kept up to date as these credentials change.
For sources that use virtual appliances, these sources leverage a Zero Knowledge Encryption scheme, where the source passwords are encrypted using the virtual appliance cluster’s public key.
This is good to know. This means that if a VA is reinstalled (a thing that might happen fairly regularly in a non-prod environment), we would need to set the passwords in all of the sources. It also means that we can’t safely store those encrypted secrets in source control, e.g., an SSB-style dev.target.properties, since the system may not be able to decrypt them later if the VA is replaced.
If the VA has the same keyPassphrase as originally entered on other VAs, it will generate the same private keys for decrypting credentials. No need to blow everything away to change credentials.
Just so you know, the first VA that pairs with a VA cluster sets the public key for encryption (associated on the VA cluster). Each VA then should have the same decryption key by virtue of using the same keyPassphrase. This is why it is important for subsequent (2, 3, n) VAs in the same VA cluster to use the same keyPassphrase as the first VA. Otherwise you’ll get an error where there is a key mismatch where credentials are unable to be decrypted by a cluster member.
You should also be able to set a new keyPassphrase in VAs, they’ll just need to be part of a different (new) VA cluster, and source credentials associated with the different (new) cluster will need to be re-entered to encrypt passwords with the new key.
Hope this helps!
Thanks.
My goal is to be able to deploy IDN artifacts (including sources) via a script with zero UI involvement. It’ll just be a bit more code on my end. No worries. It’s pretty straightforward now that you explain it.
This will probably become really easy when you will be able to use a credential provider to a PAM vault or KMS system. This is work currently in flight, so stay tuned. 
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.