# Alibaba Cloud Detector Should Display Access Key ID Instead of Secret in Raw Field

[jhonxie369-star]

Alibaba Cloud Detector Should Display Access Key ID Instead of Secret in Raw Field

Issue Description

The Alibaba Cloud detector currently displays the Access Key Secret in the Raw field instead of the Access Key ID, which is inconsistent with other cloud provider detectors and less useful for identification purposes.

Current Behavior

When detecting Alibaba Cloud credentials, TruffleHog outputs:

Raw result: [30-character secret value]

Expected Behavior

It should display the Access Key ID for better identification:

Raw result: LTAI[20-character identifier]

Why This Matters

1. Identification: Access Key IDs are designed to be identifiers and are safer to display
2. Consistency: AWS and other cloud detectors show the ID in the Raw field
3. Verification: IDs make it easier to verify which credential was found without exposing sensitive data
4. User Experience: Users expect to see the identifier, not the secret value

Code Analysis

In pkg/detectors/alibaba/alibaba.go, the current implementation assigns:

s1 := detectors.Result{
    Raw:   []byte(resMatch),              // Currently: Secret
    RawV2: []byte(resMatch + resIdMatch), // Currently: Secret+ID
}

Should be (consistent with AWS detector):

s1 := detectors.Result{
    Raw:   []byte(resIdMatch),            // Should be: ID
    RawV2: []byte(resIdMatch + ":" + resMatch), // Should be: ID:Secret
}

Comparison with AWS Detector

The AWS detector correctly shows:

• Raw: Access Key ID (AKIA...)
• RawV2: ID:Secret combination

The Alibaba detector should follow the same pattern for consistency.

Impact

• Security: Reduces exposure of sensitive secret values in output
• Usability: Makes it easier to identify which credential was detected
• Consistency: Aligns with established patterns in other detectors

[shahzadhaider1]

Hi @jhonxie369-star,
Thank you for taking the time to open this issue, we really appreciate your contribution to the project!
However, we don't recommend updating the Raw field value once set, as it is used as an identifier and changing it can interfere with existing findings.

[jhonxie369-star]

Moreover, the timeout period for verifying Alibaba key pairs is too short at only 5 seconds, which results in validation timeout failures. I tested with a 15-second timeout and verification was successful.（You can try testing for 10 seconds.）

I have fixed the above-mentioned issues in the uploaded file and also improved the verification return information to be similar to AWS output. Please review and consider adopting these changes.

As for the issue you mentioned, all other detectors are the same, only Alibaba's one got it wrong. And the logic of each detector is independent, the tool only obtains its detection results. Modifying a single detector will not affect other logic, at least in Alibaba (which I have verified locally).


Of course, if you don't want to modify the raw field value, it's okay. At least the timeout issue needs to be resolved, because extending the timeout can really succeed. Not extending the timeout period will result in failure.

alibaba_fixed.go.txt

[jhonxie369-star]

Hi @jhonxie369-star, Thank you for taking the time to open this issue, we really appreciate your contribution to the project! However, we don't recommend updating the Raw field value once set, as it is used as an identifier and changing it can interfere with existing findings.

I provided some code in my previous response for your reference and review.