Can confirm, looks like T3BlbkFJ is present in all keys. This might need to be checked periodically as they might change the signature?

@becojo Just curious, what was the reason for removing the sk- keyword?

@rgmz It was there mostly because I copy pasted another rule. I figured sk- is pretty short and is likely to be present in a lot of files that don't contain an API key, wasting time running the regular expression for nothing.

@zricethezav This might need to be checked periodically as they might change the signature?

They have API keys in the scope of their bug bounty program I would imagine they make some noise if they change the format.

Fair enough. The T3BlbkFJ does seem to be a constant, however, it is not guaranteed:

OpenAI API Keys are of the form sk-\w{48}. Anything not of this form will be discarded.

...That being said, the fact that it's OpenAI base64-encoded makes me doubt that they would remove it.

I just wanted to clarify because I noticed it was in gitleaks.toml but not openai.go (#1200). Thanks for confirming!

oh, good catch my bad

Can confirm, looks like T3BlbkFJ is present in all keys. This might need to be checked periodically as they might change the signature?

Azure's OpenAI Service seems to use a different token format. I discovered an instance where a private Azure endpoint was authenticated with a 32 alphanumeric characters. It's possible the api_key used an Azure AD token; I'm not familiar enough to with Azure to say for certain.

"""
Reference: https://github.com/openai/openai-python#microsoft-azure-active-directory-authentication
"""
import openai

# Setup parameters
openai.api_type = "azure_ad" # I need to double-check what api_type was specified.
openai.api_base = "https://example-endpoint.openai.azure.com/"
openai.api_key = "se23rtrbvtydjt30r0cwspdcpg8a4548"

(I'd expect this to get picked up by the generic rule.)