Performing Cryptographic Audit of Application
Overview
A cryptographic audit systematically reviews an application's use of cryptographic primitives, protocols, and key management to identify vulnerabilities such as weak algorithms, insecure modes, hardcoded keys, insufficient entropy, and protocol misconfigurations. This skill covers building an automated crypto audit tool that scans Python and configuration files for common cryptographic weaknesses.
When to Use
Trigger phrases:
"performing cryptographic audit of application"
"A cryptographic audit systematically reviews an application's use of cryptograph"
When conducting security assessments that involve performing cryptographic audit of application
When following incident response procedures for related security events
When performing scheduled security testing or auditing activities
When validating security controls through hands-on testing
Prerequisites
- Familiarity with cryptography concepts and tools
- Access to a test or lab environment for safe execution
- Python 3.8+ with required dependencies installed
- Appropriate authorization for any testing activities
Objectives
- Detect usage of deprecated algorithms (MD5, SHA-1, DES, RC4)
- Identify insecure cipher modes (ECB) and padding schemes
- Find hardcoded keys, passwords, and secrets in source code
- Verify TLS/SSL configuration strength
- Check key derivation function parameters
- Validate random number generator usage
- Produce a structured audit report with findings and remediation
Key Concepts
This section covers key concepts for performing cryptographic audit of application.
- Ensure all prerequisites are met before proceeding
- Follow the documented workflow steps in sequence
- Record results and any anomalies encountered during this phase
Cryptographic Weakness Categories
| Category |
Examples |
Risk Level |
| Weak Hashing |
MD5, SHA-1 for integrity/signatures |
High |
| Insecure Encryption |
DES, 3DES, RC4, Blowfish |
High |
| Bad Cipher Mode |
ECB mode for any block cipher |
High |
| Insufficient Key Size |
RSA < 2048, AES-128 for long-term |
Medium |
| Hardcoded Secrets |
Keys/passwords in source code |
Critical |
| Weak KDF |
Low iteration PBKDF2, plain MD5 |
High |
| Poor Entropy |
time-based seeds, predictable IVs |
High |
| Deprecated Protocols |
SSLv3, TLS 1.0, TLS 1.1 |
High |
Security Considerations
- Review both application code and configuration files
- Check third-party dependencies for known crypto vulnerabilities
- Verify certificates and TLS configurations on deployed servers
- Ensure secrets are loaded from environment variables or vaults
- Review key storage and rotation practices
Validation Criteria
When NOT to Use
- You don't have explicit written authorization to test
- Task is about defense/detection, not offense (use detection skills)
- You need to implement security controls (use implementing-* skills)
- Task requires compliance auditing (use auditing-* skills)
- You're investigating an incident (use incident response skills)
- Target is out of scope for your engagement
- Task is about vulnerability scanning only (use scanning tools)
Red Flags
- Performing actions without explicit written authorization from the asset owner
- Testing against production systems without a defined scope and rules of engagement
- Treating compliance checklists as security guarantees rather than minimum baselines
- Failing to document exceptions and risk acceptance decisions
- Relying on point-in-time audits instead of continuous monitoring
Verification
- All steps executed successfully against a test environment before production use
- Output documented with screenshots or logs demonstrating expected behavior
- Results validated against known-good baselines or reference implementations
- Documentation complete enough for another analyst to reproduce findings
Process
# Example: IOC detection
import re
IOC_PATTERNS = {
"ip": r"\b(?:\d{1,3}\.){3}\d{1,3}\b",
"domain": r"\b[a-z0-9-]+\.[a-z]{2,}\b",
"hash_md5": r"\b[a-f0-9]{32}\b",
"hash_sha256": r"\b[a-f0-9]{64}\b",
}
def extract_iocs(text: str) -> dict:
return {k: re.findall(v, text) for k, v in IOC_PATTERNS.items()}
- Analyze the task requirements
- Apply domain expertise
- Verify output quality
Anti-Rationalization Table
| Rationalization |
Reality |
| "We are too small to be targeted" |
Automated attacks target everyone. Size does not matter. |
| "Security slows us down" |
A breach slows you down 100x more. Build security in from the start. |
| "We will fix it after launch" |
Vulnerabilities in production are exploited within hours. Fix before deploy. |
1---2name: performing-cryptographic-audit-of-application3description: Use when a cryptographic audit systematically reviews an application's use of cryptographic primitives, protocols, and key management to identify vulnerabilities such as weak algorithms, insecure modes, hardco. Use when working with performing cryptographic audit of application.4license: Apache-2.05---67# Performing Cryptographic Audit of Application89## Overview1011A cryptographic audit systematically reviews an application's use of cryptographic primitives, protocols, and key management to identify vulnerabilities such as weak algorithms, insecure modes, hardcoded keys, insufficient entropy, and protocol misconfigurations. This skill covers building an automated crypto audit tool that scans Python and configuration files for common cryptographic weaknesses.121314## When to Use15**Trigger phrases:**16- "performing cryptographic audit of application"17- "A cryptographic audit systematically reviews an application's use of cryptograph"181920- When conducting security assessments that involve performing cryptographic audit of application21- When following incident response procedures for related security events22- When performing scheduled security testing or auditing activities23- When validating security controls through hands-on testing2425## Prerequisites2627- Familiarity with cryptography concepts and tools28- Access to a test or lab environment for safe execution29- Python 3.8+ with required dependencies installed30- Appropriate authorization for any testing activities3132## Objectives3334- Detect usage of deprecated algorithms (MD5, SHA-1, DES, RC4)35- Identify insecure cipher modes (ECB) and padding schemes36- Find hardcoded keys, passwords, and secrets in source code37- Verify TLS/SSL configuration strength38- Check key derivation function parameters39- Validate random number generator usage40- Produce a structured audit report with findings and remediation4142## Key Concepts4344This section covers key concepts for performing cryptographic audit of application.4546- Ensure all prerequisites are met before proceeding47- Follow the documented workflow steps in sequence48- Record results and any anomalies encountered during this phase49### Cryptographic Weakness Categories5051| Category | Examples | Risk Level |52|----------|----------|------------|53| Weak Hashing | MD5, SHA-1 for integrity/signatures | High |54| Insecure Encryption | DES, 3DES, RC4, Blowfish | High |55| Bad Cipher Mode | ECB mode for any block cipher | High |56| Insufficient Key Size | RSA < 2048, AES-128 for long-term | Medium |57| Hardcoded Secrets | Keys/passwords in source code | Critical |58| Weak KDF | Low iteration PBKDF2, plain MD5 | High |59| Poor Entropy | time-based seeds, predictable IVs | High |60| Deprecated Protocols | SSLv3, TLS 1.0, TLS 1.1 | High |6162## Security Considerations6364- Review both application code and configuration files65- Check third-party dependencies for known crypto vulnerabilities66- Verify certificates and TLS configurations on deployed servers67- Ensure secrets are loaded from environment variables or vaults68- Review key storage and rotation practices6970## Validation Criteria7172- [ ] Scanner detects all injected test weaknesses73- [ ] MD5/SHA-1 usage for security purposes is flagged74- [ ] ECB mode usage is flagged75- [ ] Hardcoded keys/passwords are detected76- [ ] Weak KDF parameters are identified77- [ ] Report includes severity, location, and remediation78- [ ] False positive rate is below 10%79## When NOT to Use8081- You don't have explicit written authorization to test82- Task is about defense/detection, not offense (use detection skills)83- You need to implement security controls (use implementing-* skills)84- Task requires compliance auditing (use auditing-* skills)85- You're investigating an incident (use incident response skills)86- Target is out of scope for your engagement87- Task is about vulnerability scanning only (use scanning tools)888990## Red Flags9192- Performing actions without explicit written authorization from the asset owner93- Testing against production systems without a defined scope and rules of engagement94- Treating compliance checklists as security guarantees rather than minimum baselines95- Failing to document exceptions and risk acceptance decisions96- Relying on point-in-time audits instead of continuous monitoring97## Verification9899- All steps executed successfully against a test environment before production use100- Output documented with screenshots or logs demonstrating expected behavior101- Results validated against known-good baselines or reference implementations102- Documentation complete enough for another analyst to reproduce findings103104## Process105106```python107# Example: IOC detection108import re109110IOC_PATTERNS = {111 "ip": r"\b(?:\d{1,3}\.){3}\d{1,3}\b",112 "domain": r"\b[a-z0-9-]+\.[a-z]{2,}\b",113 "hash_md5": r"\b[a-f0-9]{32}\b",114 "hash_sha256": r"\b[a-f0-9]{64}\b",115}116117def extract_iocs(text: str) -> dict:118 return {k: re.findall(v, text) for k, v in IOC_PATTERNS.items()}119```1201211. Analyze the task requirements1222. Apply domain expertise1233. Verify output quality124125## Anti-Rationalization Table126127| Rationalization | Reality |128|---|---|129| "We are too small to be targeted" | Automated attacks target everyone. Size does not matter. |130| "Security slows us down" | A breach slows you down 100x more. Build security in from the start. |131| "We will fix it after launch" | Vulnerabilities in production are exploited within hours. Fix before deploy. |