we migrated v5 to v10 , but we wanted verify that the subscriptions are working with existing client id and secret which we missed track of it somehow.
we have many consumer applications (more than 200 ). it may not  be good to reach out each application team and get details . is there anyway to get secret for specific applications . we tried below command , it is returning hashed secrete.. we don't how to decrypt  it .Could you please help on it?

apic credentials:list --app poc-api-s --catalog asm --org erie-testorg --server cpd-cp4i.apps.nprho..com/integration/apis/np-apic/np-apic --scope catalog --output -

------------------------------
santhoshkumar surisetty
------------------------------

Hiya,

client secrets are essentially passwords and so are not actually stored, all apic stores is a one way hash, so you definitely cannot retrieve the value.

Never trust a system that allows you to download passwords as it means they're been stored in a retrievable way.

Cheers

Chris

------------------------------
Chris Dudley
------------------------------

May be the correct question is - How to migrate applications without resetting client secret ? You do not necessary need it in plain for migration

------------------------------
Denis Migulin
------------------------------

@santhoshkumar surisetty

As others have already mentioned, client_secret is in hash  (there is no way you can get the clear text back from it).  And I hope your application developer will not provide you the client_secret​

Net: v5 client_secret is migrated over (we purposely support that to make the migration less painful) to v10/2018, the system knows this is a migrated application, with client_secret protected in v5 format

If the above migration is a test run, one option to handle the verification (instead of `trust us`)

- create a dummy application before hand the migration, keep the dummy client_secret, test against an api to make sure it works [as in verify the correctness of the client_secret by the gateway)

- perform migration

- perform the same test above (the client_secret will work against the migrated environment)

------------------------------
Shiu Poon
Senior Technical Staff Member - Security/Integration
IBM
San Jose CA
------------------------------

As others have said, you don't validate client secret by checking its value. For client secret, the validation should be that a call that used to work before migration using client id/secret still works post-migration.

Think of it as keeping some sample applications/subscriptions and their corresponding API calls handy that you can use to verify if the migration worked properly.

------------------------------
SUMANTO Biswas
------------------------------

For security reasons, it is obvious that stored passwords should be in the form of one-way hash functions.
However @Shiu Poon i have a question about the algorithm used by the API Connect v10 to store and compare passwords (secrets that we can find in the APIM database, credential table, client_secret_hashed column) . What is the algorithm and what additional variables does it use (salt / additional password)?
Knowledge of the algorithm can facilitate the process of testing the correctness of data migration, especially if we know the original value of the generated and shared passwords.

------------------------------
Piotr Bornikowski
------------------------------

Original Message:
Sent: Thu April 21, 2022 11:55 AM
From: SUMANTO Biswas
Subject: Client Secrets for API Connect v10

As others have said, you don't validate client secret by checking its value. For client secret, the validation should be that a call that used to work before migration using client id/secret still works post-migration.

Think of it as keeping some sample applications/subscriptions and their corresponding API calls handy that you can use to verify if the migration worked properly.

------------------------------
SUMANTO Biswas
------------------------------