Comments on: Why Using App Secrets in Production is a Bad Idea

By: Frank

Frank — Mon, 14 Nov 2022 02:59:01 +0000

Hello,
For an organization using Azure CAP to prevent users from logging in outside the corporate network, if a user has the Application ID, Tenant ID, and Secret in hand, they will be able to get a token and authenticate outside the corporate network using the service principal (i.g. via PowerShell) which makes it even more risky. The only way to reduce the risk is to configure a CAP and block the application from unwanted IP addresses.On the other hand, this could cause the action you are trying to perform to be blocked, as it could communicate with another Microsoft service on a different IP address that is not yet registered in your known location.

By: Sean McAvinue

Sean McAvinue — Wed, 16 Feb 2022 08:39:33 +0000

In reply to Andreas Dieckmann.

Hi Andreas,
I agree Certificates are not perfect but are definitely an improvement over secrets (more difficult to brute force, easier to control access vs a simple sting) .

The additional functionality provided by Conditional Access Workload Identities should help here. As stated, there’s no perfect fix, but there are measures you can take to reduce risk.

By: Andreas Dieckmann

Andreas Dieckmann — Wed, 16 Feb 2022 08:30:11 +0000

I think the explanation lacks of details, why secrets are less secure than certificates. Certificates are also *one* credential used for authentication. If several people share the certificate, you still don’t know who actually used it. Certificates also have an expiration date.

But: it’s way more difficult to brute force a certificate, than a secret string. And it’s a bit more difficult to share among other admins in a company.