Cryptographic Failures چیست؟ بررسی ضعف‌های رمزنگاری در سایت و روش‌های جلوگیری

# Cryptographic Failures چیست؟ بررسی ضعف‌های رمزنگاری در سایت و روش‌های جلوگیری

Cryptographic Failures یا «شکست‌های رمزنگاری» به مجموعه‌ای از ضعف‌های امنیتی گفته می‌شود که در اثر نبود رمزنگاری، استفاده از الگوریتم یا پروتکل ضعیف، ذخیره نامناسب رمز عبور، نشت کلیدهای رمزنگاری، تولید مقادیر تصادفی قابل پیش‌بینی یا پیاده‌سازی اشتباه Encryption ایجاد می‌شوند. نتیجه این خطاها می‌تواند افشای اطلاعات کاربران، سرقت Session، دسترسی به اطلاعات محرمانه، بازیابی Passwordها یا حتی به خطر افتادن کامل یک سامانه باشد.

در OWASP Top 10 2025، Cryptographic Failures در جایگاه A04 قرار دارد. OWASP این دسته را به ۳۲ ضعف CWE مرتبط کرده و تأکید می‌کند که مشکلات رمزنگاری معمولاً به افشای داده‌های حساس یا Compromise شدن سیستم منجر می‌شوند.

رمزنگاری یکی از قدرتمندترین ابزارهای دفاعی امنیت اطلاعات است؛ اما فقط در صورتی که درست استفاده شود. وجود HTTPS، Hash، Encryption یا حتی یک الگوریتم شناخته‌شده به‌تنهایی تضمین نمی‌کند که داده‌های یک سایت واقعاً امن باشند. اگر کلید در Source Code قرار گرفته باشد، Password با الگوریتم نامناسب ذخیره شود، Random Token قابل پیش‌بینی باشد یا یک Nonce دوباره استفاده شود، ممکن است لایه رمزنگاری ظاهراً وجود داشته باشد اما عملاً حفاظت مورد انتظار را ایجاد نکند.

در این مقاله رخنه‌کاو، Cryptographic Failures را از دید امنیت برنامه‌های وب بررسی می‌کنیم، تفاوت Encryption، Hashing و Encoding را توضیح می‌دهیم و مهم‌ترین اشتباهات مربوط به Password، TLS، Key Management، Secretها، Tokenها و داده‌های حساس را بررسی خواهیم کرد. سپس مجموعه‌ای از راهکارهای دفاعی و یک چک‌لیست کاربردی برای کاهش این ریسک ارائه می‌کنیم.

Cryptographic Failures دقیقاً چیست؟

Cryptographic Failures زمانی رخ می‌دهد که یک برنامه برای محافظت از اطلاعات حساس به رمزنگاری نیاز دارد اما این حفاظت وجود ندارد یا به شکل نادرست پیاده‌سازی شده است.

این مشکل ممکن است در سه سطح اصلی ظاهر شود:

1. اصلاً رمزنگاری وجود ندارد.
2. رمزنگاری وجود دارد اما الگوریتم، کلید، پروتکل یا تنظیمات آن ضعیف است.
3. الگوریتم مناسبی انتخاب شده اما نحوه استفاده از آن اشتباه است.

بنابراین تصور اینکه Cryptographic Failures فقط مربوط به الگوریتم‌های قدیمی مانند MD5 است، تصویر کاملی از این آسیب‌پذیری ارائه نمی‌دهد.

OWASP در نسخه ۲۰۲۵ مواردی مانند استفاده از الگوریتم‌های شکسته یا پرریسک، Entropy ناکافی، Random Number Generator قابل پیش‌بینی، کلیدهای Hard-coded، استفاده بیش از عمر تعیین‌شده کلید، استفاده مجدد از Nonce و ضعف‌های مشابه را در این دسته قرار می‌دهد.

یک مثال ساده

فرض کنید یک فروشگاه اینترنتی تمام صفحات خود را از طریق HTTPS ارائه می‌کند.

در نگاه اول ممکن است تصور کنیم اطلاعات کاربران امن است.

اما Database همان فروشگاه Password کاربران را با یک Hash سریع و قدیمی ذخیره می‌کند و API Key در فایل Source Code قرار گرفته است.

در این شرایط HTTPS فقط ارتباط بین مرورگر و Server را محافظت می‌کند. اگر Database یا Repository لو برود، حفاظت مورد انتظار برای Password و API Key وجود ندارد.

Cryptographic Security باید در تمام چرخه داده بررسی شود، نه فقط هنگام باز شدن سایت در Browser.

چرا Cryptographic Failures خطرناک است؟

هدف اصلی رمزنگاری ایجاد چند ویژگی امنیتی مهم است.

مهم‌ترین آن‌ها عبارت‌اند از:

Confidentiality یا محرمانگی، Integrity یا یکپارچگی، Authentication یا تأیید هویت و در برخی کاربردها Non-repudiation.

اگر مکانیزم رمزنگاری شکست بخورد، ممکن است یک یا چند مورد از این ویژگی‌ها از بین بروند.

برای مثال اگر اطلاعات بدون TLS منتقل شوند، فردی که بتواند ترافیک شبکه را مشاهده کند ممکن است اطلاعات را بخواند یا تغییر دهد.

اگر Passwordها ضعیف Hash شده باشند، افشای Database می‌تواند زمینه بازیابی تعداد زیادی Credential را فراهم کند.

اگر Session Token قابل پیش‌بینی باشد، مهاجم ممکن است بتواند Token معتبر را حدس بزند.

اگر Key اصلی Encryption در همان Database یا Repository نگهداری شود، رمزگذاری اطلاعات ممکن است در برابر مهاجمی که به همان محل دسترسی پیدا کرده، ارزش بسیار کمی داشته باشد.

به همین دلیل OWASP Cryptographic Failures را صرفاً یک خطای کوچک برنامه‌نویسی نمی‌داند.

در داده‌های OWASP Top 10 2025، این دسته دارای بیش از ۱.۶ میلیون رخداد ثبت‌شده در داده‌های مشارکت‌کنندگان بوده و ۲۱۸۵ CVE به CWEهای این دسته مرتبط شده‌اند.

تفاوت Encryption، Hashing و Encoding چیست؟

یکی از رایج‌ترین دلایل طراحی اشتباه سیستم‌های امنیتی، یکسان در نظر گرفتن Encryption، Hashing و Encoding است.

این سه مفهوم اهداف متفاوتی دارند.

<table> <thead> <tr> <th>مفهوم</th> <th>هدف اصلی</th> <th>برگشت‌پذیر؟</th> <th>نمونه کاربرد</th> </tr> </thead> <tbody> <tr> <td>Encryption</td> <td>محرمانه نگه داشتن اطلاعات</td> <td>بله، با کلید مناسب</td> <td>رمزگذاری اطلاعات حساس</td> </tr> <tr> <td>Hashing</td> <td>تولید اثر انگشت یک‌طرفه از داده</td> <td>در حالت استاندارد خیر</td> <td>ذخیره امن Password</td> </tr> <tr> <td>Encoding</td> <td>تغییر نمایش داده برای انتقال یا سازگاری</td> <td>بله</td> <td>Base64 یا URL Encoding</td> </tr> </tbody> </table>

Encryption چیست؟

Encryption داده قابل خواندن یا Plaintext را با استفاده از یک Algorithm و Key به Ciphertext تبدیل می‌کند.

فرد یا سیستمی که Key مناسب را در اختیار داشته باشد می‌تواند اطلاعات را Decrypt کند.

بنابراین Encryption برای اطلاعاتی مناسب است که برنامه بعداً دوباره به محتوای اصلی آن‌ها نیاز دارد.

Hashing چیست؟

Hashing معمولاً فرآیندی یک‌طرفه است.

برای مثال هنگام ذخیره Password قرار نیست برنامه Password اصلی را بازیابی کند. برنامه باید ورودی کاربر هنگام Login را پردازش و نتیجه را با مقدار ذخیره‌شده مقایسه کند.

به همین دلیل Password عموماً باید Hash شود، نه اینکه با Encryption برگشت‌پذیر ذخیره شود.

OWASP نیز صراحتاً توصیه می‌کند Passwordها به‌جای Encryption برگشت‌پذیر با الگوریتم‌های مخصوص Password Hashing محافظت شوند.

Encoding رمزنگاری نیست

Base64 نمونه معروفی از Encoding است.

هر فردی که داده Base64 را در اختیار داشته باشد می‌تواند آن را بدون هیچ Secret Key خاصی Decode کند.

بنابراین ذخیره Password، API Key، Token یا اطلاعات محرمانه با Base64 هیچ محافظت امنیتی رمزنگاری‌شده‌ای ایجاد نمی‌کند.

داده حساس چیست؟

پیش از انتخاب Encryption Algorithm باید مشخص کنیم دقیقاً از چه چیزی می‌خواهیم محافظت کنیم.

OWASP توصیه می‌کند اطلاعاتی که برنامه پردازش، ذخیره یا منتقل می‌کند طبقه‌بندی شوند تا داده‌های حساس مشخص باشند.

بسته به نوع سایت، موارد زیر می‌توانند اطلاعات حساس باشند:

• Password کاربران
• Tokenهای Authentication
• Session Identifier
• Private Key
• API Key
• اطلاعات بانکی و مالی
• اطلاعات شخصی کاربران
• شماره تلفن و ایمیل در برخی Contextها
• اطلاعات پزشکی
• Backup Database
• Secretهای سرویس‌های خارجی
• Recovery Codeهای احراز هویت
• فایل‌های خصوصی
• اطلاعات احراز هویت OAuth
• Credentialهای Database
• Encryption Keyها

اصل مهم این است که حساس بودن داده فقط با نام آن تعیین نمی‌شود.

Business Context، قوانین حریم خصوصی، نوع سرویس و پیامد افشای اطلاعات نیز باید در Data Classification در نظر گرفته شوند.

Data at Rest و Data in Transit چه تفاوتی دارند؟

در امنیت رمزنگاری معمولاً باید دو وضعیت اصلی اطلاعات بررسی شود.

Data in Transit

Data in Transit اطلاعاتی است که در حال انتقال بین دو نقطه است.

برای مثال:

Browser به Web Server

Web Server به API

Application Server به Database

Microservice به Microservice

Server به سرویس شخص ثالث

این ارتباطات معمولاً باید توسط TLS یا مکانیزم امن مشابه محافظت شوند.

Data at Rest

Data at Rest اطلاعاتی است که در جایی ذخیره شده است.

برای مثال:

Database

Backup

Disk

Object Storage

File Server

Log Archive

Cache

OWASP توصیه می‌کند اطلاعات حساس در حالت ذخیره نیز با کنترل‌های مناسب محافظت شوند و تا جای ممکن اصلاً اطلاعات غیرضروری حساس ذخیره نشوند.

Encryption در Transit جای Encryption در Rest را نمی‌گیرد

HTTPS از ترافیک شبکه محافظت می‌کند.

اما وقتی اطلاعات به Server رسیدند و داخل Database ذخیره شدند، TLS دیگر از نسخه ذخیره‌شده اطلاعات محافظت نمی‌کند.

برعکس، رمزگذاری Database نیز از اطلاعاتی که از طریق HTTP ناامن منتقل می‌شوند محافظت نخواهد کرد.

هر دو مسیر باید جداگانه در Threat Model بررسی شوند.

HTTPS و TLS چه نقشی در جلوگیری از Cryptographic Failures دارند؟

یکی از مهم‌ترین کنترل‌های رمزنگاری برای یک Website استفاده صحیح از HTTPS است.

HTTPS در واقع HTTP روی TLS است.

TLS به حفاظت از Confidentiality، Integrity و Authenticity ارتباطات کمک می‌کند.

MDN توصیه می‌کند تمام صفحات و Subresourceهای سایت از طریق HTTPS ارائه شوند. بسیاری از Web APIهای حساس نیز فقط داخل Secure Context قابل استفاده هستند.

آیا داشتن SSL Certificate کافی است؟

خیر.

گواهی SSL/TLS فقط بخشی از ماجرا است.

یک سایت ممکن است Certificate معتبر داشته باشد اما:

بعضی صفحات هنوز از HTTP استفاده کنند.

Resourceهای خارجی از HTTP Load شوند.

نسخه‌های قدیمی TLS فعال باشند.

Configuration ضعیفی برای Cipher Suiteها وجود داشته باشد.

Cookie حساس بدون Secure Flag ارسال شود.

ارتباط Server-to-Server بدون TLS انجام شود.

HSTS فعال نباشد.

به همین دلیل وجود علامت قفل مرورگر به‌تنهایی اثبات نمی‌کند تمام معماری Cryptographic Security مناسبی دارد.

TLS 1.2 و TLS 1.3

در راهنمای فعلی MDN، TLS 1.3 نسخه فعلی TLS معرفی شده و TLS 1.2 همچنان در برخی وب‌سایت‌ها استفاده می‌شود؛ TLS 1.0 و TLS 1.1 دیگر نباید استفاده شوند.

OWASP نیز برای ارتباطات وب استفاده از پروتکل‌های مدرن TLS و Cipherهای قوی را توصیه می‌کند. برای TLS 1.3، Cipherهای استاندارد AEAD مانند AES-GCM و ChaCha20-Poly1305 در راهنمای OWASP مطرح شده‌اند.

هدف این توصیه‌ها انتخاب دستی یک Cipher به‌صورت تصادفی نیست.

در عمل باید از Configurationهای امن و به‌روز Web Server، Load Balancer، CDN یا Cloud Provider استفاده شود و پشتیبانی از پروتکل‌های منسوخ حذف گردد.

HSTS چیست و چرا اهمیت دارد؟

HSTS مخفف HTTP Strict Transport Security است.

این مکانیزم به Browser اعلام می‌کند که برای Domain موردنظر فقط باید از HTTPS استفاده شود.

در نتیجه Browser پس از دریافت Policy مربوطه تلاش نمی‌کند به شکل عادی از HTTP برای آن Domain استفاده کند.

OWASP توضیح می‌دهد HSTS می‌تواند در برابر برخی سناریوهای Downgrade یا تلاش برای هدایت کاربر به HTTP نقش دفاعی مهمی داشته باشد.

البته HSTS باید با دقت Deploy شود.

قبل از فعال‌سازی گسترده روی تمام Subdomainها باید اطمینان حاصل شود تمام سرویس‌های موردنیاز واقعاً HTTPS را پشتیبانی می‌کنند.

ذخیره Password یکی از مهم‌ترین نقاط Cryptographic Failures

ذخیره Password یکی از واضح‌ترین مثال‌های کاربرد اشتباه رمزنگاری است.

هدف سیستم این نیست که Password اصلی کاربر را بعداً بازیابی کند.

به همین دلیل Password نباید Plaintext ذخیره شود و در اکثر سیستم‌ها نباید با Encryption برگشت‌پذیر نگهداری شود.

چرا SHA-256 ساده برای Password کافی نیست؟

SHA-256 یک Hash قدرتمند برای بسیاری از کاربردها است، اما برای Password Storage به‌تنهایی انتخاب مناسبی نیست.

دلیل اصلی این است که SHA-256 برای سرعت طراحی شده است.

در Password Cracking، سرعت بالا به نفع مهاجم است زیرا می‌تواند تعداد بسیار زیادی Password احتمالی را در زمان کوتاه امتحان کند.

الگوریتم‌های Password Hashing عمداً هزینه محاسباتی بیشتری ایجاد می‌کنند تا عملیات Guess کردن گسترده گران‌تر شود.

OWASP برای سیستم‌های جدید Argon2id را گزینه اول معرفی می‌کند و در صورت در دسترس نبودن آن scrypt را پیشنهاد می‌دهد. bcrypt عمدتاً برای سیستم‌های Legacy مطرح می‌شود و PBKDF2 نیز در شرایطی مانند الزامات FIPS کاربرد دارد.

Salt چیست؟

Salt یک مقدار Random و منحصربه‌فرد است که هنگام Password Hashing استفاده می‌شود.

اگر دو کاربر Password یکسانی داشته باشند ولی Salt متفاوتی برای آن‌ها استفاده شود، Hash نهایی آن‌ها نیز متفاوت خواهد بود.

Salt باعث می‌شود استفاده از جدول‌های از پیش محاسبه‌شده مانند Rainbow Table بسیار سخت‌تر شود و مهاجم نتواند یک Hash محاسبه‌شده را مستقیماً علیه تمام کاربران استفاده کند.

الگوریتم‌های مدرن Password Hashing معمولاً مدیریت Salt را در قالب استاندارد خود پشتیبانی می‌کنند.

Pepper چیست؟

Pepper یک Secret اضافی است که می‌تواند در کنار Password Hashing برای Defense in Depth استفاده شود.

برخلاف Salt، Pepper باید Secret باقی بماند و معمولاً نباید داخل همان Database Hashها ذخیره شود.

Pepper جای الگوریتم Password Hashing مناسب را نمی‌گیرد؛ بلکه فقط یک لایه اضافی دفاعی است.

Encryption Key مهم‌تر از خود Algorithm است

گاهی تیم توسعه زمان زیادی صرف انتخاب Encryption Algorithm می‌کند اما Key را داخل Source Code قرار می‌دهد.

این اشتباه می‌تواند کل مزیت Encryption را از بین ببرد.

فرض کنید Database دارای اطلاعات AES-encrypted باشد، اما AES Key در همان Git Repository پروژه قرار گرفته باشد.

اگر مهاجم Repository و Database را در اختیار بگیرد، جدا کردن Ciphertext از Plaintext احتمالاً بسیار ساده‌تر خواهد شد.

Hard-coded Key چیست؟

Hard-coded Key یعنی Key مستقیماً داخل Source Code، Configuration عمومی یا فایل قابل انتشار قرار داده شود.

برای مثال:

Application Code

Git Repository

Docker Image

JavaScript سمت Client

فایل عمومی Configuration

Backup Source Code

این روش مدیریت Key مناسب نیست.

OWASP توصیه می‌کند Keyها در Cryptographic Vault، HSM یا سرویس‌های ایزوله مدیریت کلید نگهداری شوند و به شکل Plaintext ذخیره نشوند.

Key Management چیست؟

Key Management به کل چرخه عمر یک Cryptographic Key اشاره دارد.

موضوع فقط «کجا Key را ذخیره کنیم» نیست.

این چرخه می‌تواند شامل موارد زیر باشد:

تولید Key

توزیع

ذخیره

دسترسی

استفاده

Rotation

Backup

Recovery

Revocation

Expiration

Destruction

NIST در SP 800-57 راهنمای جامعی برای مدیریت Cryptographic Keying Material ارائه می‌کند و بر محافظت مناسب از Key در طول چرخه عمر آن تأکید دارد.

Key Rotation چرا لازم است؟

Key نباید لزوماً برای همیشه استفاده شود.

Rotation به معنی جایگزین کردن Key فعلی با Key جدید براساس Policy مشخص است.

دلایل Rotation می‌تواند شامل موارد زیر باشد:

پایان عمر تعیین‌شده Key

تغییر سیاست امنیتی

احتمال افشای Key

خروج فرد دارای دسترسی

مهاجرت زیرساخت

الزام Compliance

به‌روزرسانی Algorithm

یکی از چالش‌های Rotation این است که اطلاعات قدیمی ممکن است همچنان با Key قبلی رمزگذاری شده باشند.

بنابراین Key Rotation باید قبل از Production در معماری Data Lifecycle طراحی شود.

Secrets با Encryption Key یکسان نیستند

Secret یک مفهوم گسترده‌تر است.

مواردی مانند موارد زیر می‌توانند Secret باشند:

API Token

Database Password

OAuth Client Secret

Private Key

Signing Key

Encryption Key

Webhook Secret

Service Credential

این اطلاعات نباید در Git Repository، Ticket عمومی، Screenshot، Log یا Front-end Code قرار گیرند.

OWASP توصیه می‌کند مدیریت Secret و Encryption به‌صورت ساختاریافته انجام شود و Secretها با کنترل‌های Confidentiality و Integrity مناسب محافظت شوند.

IV و Nonce چیست و چرا استفاده مجدد از آن‌ها خطرناک است؟

برخی Encryption Modeها علاوه بر Key به مقدار دیگری مانند Initialization Vector یا IV و Nonce نیاز دارند.

هدف و الزامات دقیق این مقدار به Algorithm و Mode بستگی دارد.

یکی از اشتباهات مهم این است که توسعه‌دهنده تصور کند چون IV یا Nonce الزاماً Secret نیست، نحوه تولید آن نیز اهمیتی ندارد.

در بعضی Schemeها، تکرار Nonce با همان Key می‌تواند امنیت Encryption را به‌شدت تضعیف کند.

OWASP در A04:2025 صراحتاً به Reusing a Nonce و مشکلات مرتبط با IV اشاره می‌کند.

راهکار مناسب این نیست که توسعه‌دهنده شخصاً Algorithm جدیدی برای تولید Nonce طراحی کند.

بهتر است از Libraryهای معتبر استفاده شود که نیازهای الگوریتم را به‌درستی مدیریت می‌کنند.

Randomness و Entropy در امنیت وب

Randomness در بخش‌های بسیار زیادی از امنیت وب استفاده می‌شود.

برای مثال:

Session ID

CSRF Token

Password Reset Token

API Key

Encryption Key

Nonce

OTP Seed

Invitation Token

اگر این مقادیر قابل پیش‌بینی باشند، ممکن است مهاجم بتواند آن‌ها را حدس بزند.

تفاوت Random معمولی و Cryptographically Secure Random

Random Generatorهای عمومی برای Simulation، Game یا عملیات غیرامنیتی ممکن است مناسب باشند.

اما Token امنیتی باید با Cryptographically Secure Pseudo-Random Number Generator یا CSPRNG ساخته شود.

OWASP در Cryptographic Failures 2025 به‌طور مشخص CWEهای مرتبط با Insufficient Entropy و Weak/Predictable Random Number Generator را جزو ضعف‌های پرتکرار این دسته معرفی کرده است.

Entropy چیست؟

به زبان ساده، Entropy میزان غیرقابل پیش‌بینی بودن مقدار تولیدشده را نشان می‌دهد.

اگر Token از فضای بسیار کوچکی انتخاب شود یا الگوی قابل حدسی داشته باشد، حتی اگر ظاهراً Random به نظر برسد، امنیت کافی ندارد.

Timestamp، User ID، Incremental Counter یا ترکیب ساده این موارد نباید جایگزین Secure Random برای Secret Token شوند.

استفاده از Algorithmهای ضعیف یا منسوخ

Cryptography حوزه‌ای است که در طول زمان تغییر می‌کند.

Algorithm یا Configurationی که سال‌ها پیش قابل قبول بوده ممکن است امروز توصیه نشود.

نمونه‌های شناخته‌شده‌ای مانند MD5 و SHA-1 نباید برای کاربردهایی که نیازمند مقاومت Collision مدرن هستند استفاده شوند.

همچنین Encryption Scheme یا Protocol قدیمی ممکن است در برابر Attackهایی که هنگام طراحی آن شناخته‌شده نبودند آسیب‌پذیر باشد.

OWASP در A04:2025 استفاده از Broken or Risky Cryptographic Algorithm را یکی از CWEهای مهم این دسته معرفی کرده است.

آیا باید خودمان Algorithm رمزنگاری طراحی کنیم؟

تقریباً همیشه خیر.

OWASP در Cryptographic Storage Cheat Sheet درباره Custom Cryptographic Algorithm توصیه بسیار روشنی دارد: این کار انجام نشود.

Cryptography از حوزه‌هایی است که یک طراحی ممکن است از نظر ظاهری کاملاً منطقی باشد اما ضعف ریاضی یا Implementation بسیار جدی داشته باشد.

از Primitiveها، Libraryها و Protocolهای شناخته‌شده و بررسی‌شده استفاده کنید.

Authenticated Encryption چیست؟

Encryption به‌تنهایی الزاماً تضمین نمی‌کند داده تغییر نکرده است.

در بسیاری از کاربردها علاوه بر Confidentiality به Integrity و Authenticity نیز نیاز داریم.

Authenticated Encryption Modeها این قابلیت‌ها را در یک طراحی استاندارد ترکیب می‌کنند.

OWASP استفاده از Modeهای احراز هویت‌شده را ترجیح می‌دهد و GCM و CCM را از نمونه‌های رایج معرفی می‌کند. برای TLS مدرن نیز AES-GCM و ChaCha20-Poly1305 از گزینه‌های استاندارد AEAD هستند.

نکته مهم این است که انتخاب Algorithm باید براساس Library استاندارد، Environment، Compliance Requirement و Threat Model انجام شود؛ نه صرفاً براساس یک مقاله اینترنتی.

AES چیست و چه زمانی استفاده می‌شود؟

AES یک Symmetric Encryption Algorithm بسیار شناخته‌شده است.

Symmetric به این معنی است که معمولاً Key مشترکی برای Encryption و Decryption استفاده می‌شود.

OWASP برای Symmetric Encryption، AES با Key حداقل ۱۲۸ بیت و ترجیحاً ۲۵۶ بیت را در راهنمای Cryptographic Storage مطرح می‌کند.

اما عبارت «ما از AES استفاده می‌کنیم» به‌تنهایی اطلاعات کافی درباره امنیت سیستم نمی‌دهد.

موارد زیر نیز باید بررسی شوند:

Mode استفاده‌شده

Key Generation

Key Storage

Nonce/IV

Authentication

Rotation

Library

Error Handling

Access Control

حتی بهترین Algorithm نیز با مدیریت Key ضعیف می‌تواند بی‌اثر شود.

رمزنگاری نامتقارن چیست؟

در Asymmetric Cryptography معمولاً یک Key Pair شامل Public Key و Private Key وجود دارد.

Public Key می‌تواند منتشر شود، اما Private Key باید محافظت شود.

این نوع Cryptography در کاربردهایی مانند:

TLS

Digital Signature

Key Agreement

Certificate

Software Signing

استفاده می‌شود.

انتخاب Algorithm و Key Size مناسب باید از استانداردهای معتبر و Libraryهای به‌روز پیروی کند.

OWASP در راهنمای Storage خود ECC با Curve امن مانند Curve25519 را در بسیاری از کاربردها ترجیح می‌دهد و اگر RSA موردنیاز باشد، حداقل Key Size مناسب را توصیه می‌کند.

یکی از اشتباهات مهم: رمزگذاری همه چیز بدون Threat Model

رمزنگاری همیشه راه‌حل خودکار هر مشکل امنیتی نیست.

قبل از Encryption باید سؤال کرد:

از چه مهاجمی محافظت می‌کنیم؟

اگر Web Server کاملاً Compromise شود چه اتفاقی می‌افتد؟

Key کجاست؟

چه کسی به Key دسترسی دارد؟

چه داده‌ای واقعاً نیازمند Encryption است؟

آیا برنامه باید بعداً Plaintext را بازیابی کند؟

Data Retention چقدر است؟

اگر Key گم شود چه اتفاقی می‌افتد؟

OWASP توصیه می‌کند طراحی Cryptographic Storage با Threat Model آغاز شود.

برای مثال اگر Application و Encryption Key و Database همگی در یک محیط با دسترسی یکسان قرار داشته باشند، Encryption ممکن است در برابر بعضی Threatها مفید باشد ولی در برابر Full Application Compromise محافظت محدودی ایجاد کند.

این موضوع به معنی بی‌فایده بودن Encryption نیست؛ بلکه نشان می‌دهد Threat Model باید مشخص کند Encryption قرار است چه ریسکی را کاهش دهد.

اصل Data Minimization؛ بهترین داده برای محافظت، داده‌ای است که ذخیره نشده

یکی از مهم‌ترین اصول امنیت اطلاعات این است که اطلاعات حساس غیرضروری را نگهداری نکنیم.

اگر Application برای انجام وظیفه خود نیازی به ذخیره اطلاعات حساس ندارد، حذف آن اغلب کنترل قدرتمندتری نسبت به ساخت یک Encryption Layer پیچیده است.

OWASP نیز توصیه می‌کند داده حساس غیرضروری ذخیره نشود و در صورت امکان از Tokenization، Truncation یا حذف داده استفاده شود.

این اصل خصوصاً برای موارد زیر مهم است:

اطلاعات کارت پرداخت

Tokenهای قدیمی

Backupهای بدون استفاده

فایل‌های Export

Logهای طولانی‌مدت

Credentialهای منقضی

اطلاعات شخصی‌ای که دیگر Business Need ندارند

Backup فراموش‌شده؛ یکی از نقاط مهم Cryptographic Failure

بسیاری از تیم‌ها Database اصلی را به‌خوبی محافظت می‌کنند اما Backup آن را روی Storage دیگری بدون همان سطح امنیت قرار می‌دهند.

از دید مهاجم، Backup می‌تواند همان اطلاعات Database اصلی یا حتی اطلاعات بیشتری را شامل شود.

Backup باید در Data Classification قرار بگیرد.

موارد زیر باید بررسی شوند:

Encryption at Rest

Access Control

Retention

Key Management

نسخه‌های قدیمی

Off-site Backup

Cloud Permission

Deletion Policy

Audit Log

اگر Backup حساس روی Public Storage قرار بگیرد، Encrypt بودن Database Production مشکل را حل نمی‌کند.

Logها می‌توانند Encryption را دور بزنند

فرض کنید اطلاعات حساس در Database رمزگذاری شده است اما Application همان اطلاعات را هنگام Error به‌صورت Plaintext داخل Log ثبت می‌کند.

در این حالت Log به مسیر جانبی افشای اطلاعات تبدیل شده است.

مواردی مانند Password، Full Session Token، Private Key، Encryption Key و Credential نباید بدون ضرورت در Log نوشته شوند.

همچنین Debug Log در Production می‌تواند اطلاعاتی نمایش دهد که برای مهاجم ارزشمند است.

Cryptographic Design باید Data Flow را به‌طور کامل بررسی کند، نه فقط Database Schema را.

Client-side Encryption و محدودیت‌های آن

گاهی برنامه اطلاعات را در Browser Encrypt می‌کند.

این روش در برخی معماری‌های خاص می‌تواند مفید باشد، اما باید مشخص باشد Key در کجا قرار دارد و از چه Threatی محافظت می‌کند.

اگر Secret Key مستقیماً داخل JavaScript ارسال‌شده به همه کاربران قرار گرفته باشد، Secret واقعی محسوب نمی‌شود.

هر چیزی که Browser کاربر دریافت کند باید بالقوه قابل مشاهده در نظر گرفته شود.

بنابراین API Key خصوصی، Master Encryption Key یا Server Secret نباید داخل Front-end Bundle قرار گیرد.

رمزنگاری در WordPress چگونه مطرح می‌شود؟

سایت‌های WordPress نیز می‌توانند در معرض Cryptographic Failures باشند.

برخی سناریوهای قابل بررسی عبارت‌اند از:

استفاده از HTTP در بخش‌هایی از سایت

Mixed Content

Plugin اختصاصی با رمزنگاری دست‌ساز

قرار دادن API Secret داخل JavaScript

Backup بدون حفاظت مناسب

ارسال Credential از طریق Channel نامناسب

ذخیره Token سرویس خارجی به‌شکل Plaintext بدون بررسی نیاز امنیتی

نگهداری فایل Configuration با Permission نامناسب

استفاده از Plugin قدیمی با Library رمزنگاری منسوخ

مدیریت نامناسب Cookie یا Session در کد سفارشی

آیا WordPress Password را Plaintext ذخیره می‌کند؟

WordPress Core برای Password کاربران از مکانیزم Hashing استفاده می‌کند و Password را به شکل Plaintext نگهداری نمی‌کند.

اما Pluginها و Applicationهای جانبی ممکن است داده‌های حساس دیگری تولید کنند.

بنابراین امنیت Cryptographic یک سایت WordPress فقط به مکانیزم Login خود WordPress محدود نیست.

Pluginهای اختصاصی، اتصال به Payment Gateway، CRM، APIهای خارجی و سیستم‌های Membership نیز باید بررسی شوند.

Cryptographic Failures در APIها

APIها حجم زیادی از داده حساس را جابه‌جا می‌کنند.

مهم‌ترین بررسی‌ها شامل:

TLS برای تمام Endpointها

Secret Management

Token Generation

Token Lifetime

Key Rotation

Encryption داده حساس

Certificate Validation

Server-to-Server TLS

عدم قرار دادن Secret در URL

عدم Log کردن Token

Secure Randomness

Authentication Signature

است.

یکی از اشتباهات متداول این است که ارتباط User تا Front-end روی HTTPS باشد اما ارتباط Internal Serviceها بدون TLS یا Authentication مناسب انجام شود.

شبکه داخلی نباید به‌صورت پیش‌فرض Trusted در نظر گرفته شود.

تفاوت Cryptographic Failures و Authentication Failures

این دو دسته OWASP می‌توانند به هم مرتبط باشند اما یکسان نیستند.

Authentication Failures بیشتر روی اثبات هویت و مدیریت Login و Session تمرکز دارد.

Cryptographic Failures روی حفاظت رمزنگاری‌شده از اطلاعات، Algorithmها، Keys، Randomness و Protocolها تمرکز می‌کند.

برای مثال:

Password Policy ضعیف بیشتر Authentication Failure است.

Hash نامناسب Password بیشتر Cryptographic Failure است.

Session Token قابل پیش‌بینی می‌تواند هر دو حوزه را تحت تأثیر قرار دهد.

نبود TLS می‌تواند Credential صحیح را نیز در مسیر انتقال در معرض خطر قرار دهد.

امنیت واقعی از ترکیب چند Control حاصل می‌شود.

تفاوت Cryptographic Failures و Sensitive Data Exposure

در نسخه‌های قدیمی OWASP اصطلاح Sensitive Data Exposure بیشتر دیده می‌شد.

اما OWASP از نسخه ۲۰۲۱ تمرکز دسته را به Root Cause یعنی Cryptographic Failures منتقل کرد.

این تغییر مهم است.

«افشای اطلاعات حساس» اغلب نتیجه است.

اما «رمزنگاری نامناسب» یکی از علت‌هایی است که باعث آن نتیجه می‌شود.

تمرکز روی Root Cause کمک می‌کند تیم توسعه به جای اینکه فقط پیامد را توصیف کند، Control فنی ایجادکننده ریسک را اصلاح کند.

اشتباهات رایج در جلوگیری از Cryptographic Failures

اشتباه اول: تصور اینکه HTTPS یعنی سایت از نظر رمزنگاری امن است

HTTPS بسیار مهم است اما فقط بخشی از Data Flow را پوشش می‌دهد.

Password Hashing، Encryption at Rest، Key Management و Secret Storage مسائل جداگانه‌ای هستند.

اشتباه دوم: ذخیره Password با Encryption

Password معمولاً باید با الگوریتم Password Hashing مناسب ذخیره شود، نه Encryption برگشت‌پذیر.

اشتباه سوم: استفاده از SHA-256 ساده برای Password

SHA-256 برای Password Storage تخصصی طراحی نشده است.

برای این کاربرد باید از الگوریتم‌هایی مانند Argon2id و راهکارهای استاندارد Password Hashing استفاده شود.

اشتباه چهارم: قرار دادن Key در Source Code

Encryption Key نباید در همان Repositoryی باشد که Code عمومی Application در آن نگهداری می‌شود.

اشتباه پنجم: ساخت Algorithm اختصاصی

Crypto سفارشی بدون بررسی گسترده متخصصان می‌تواند ضعف‌هایی داشته باشد که حتی توسعه‌دهنده باتجربه نیز متوجه آن‌ها نشود.

اشتباه ششم: استفاده از Random معمولی برای Token امنیتی

Password Reset Token، Session Identifier و Secretهای مشابه باید از Secure Random Generator مناسب تولید شوند.

اشتباه هفتم: Encryption بدون Integrity Protection

فقط محرمانه کردن اطلاعات همیشه کافی نیست.

در بسیاری از کاربردها باید بتوان تغییر غیرمجاز Ciphertext را نیز تشخیص داد.

اشتباه هشتم: عدم Rotation کلید

استفاده دائمی از یک Key بدون Lifecycle مشخص، مدیریت Incident و Key Compromise را سخت می‌کند.

اشتباه نهم: Encrypt کردن Data ولی ذخیره Key کنار همان Data

اگر مهاجم هم Ciphertext و هم Key را به‌سادگی از یک محل دریافت کند، حفاظت عملی کاهش می‌یابد.

اشتباه دهم: نادیده گرفتن Error Handling

Crypto Libraryها ممکن است Error تولید کنند.

Application نباید هنگام Failure رمزنگاری به حالت ناامن Fail Open شود یا اطلاعات حساس داخلی را در Error Message نمایش دهد.

آیا Quantum Computing رمزنگاری سایت‌ها را تهدید می‌کند؟

رمزنگاری Post-Quantum در سال‌های اخیر از موضوعی پژوهشی به مسئله‌ای عملی‌تر برای برنامه‌ریزی بلندمدت تبدیل شده است.

NIST در اوت ۲۰۲۴ سه استاندارد اصلی Post-Quantum شامل FIPS 203، FIPS 204 و FIPS 205 را منتشر کرد. این استانداردها برای Key Establishment و Digital Signatureهایی طراحی شده‌اند که هدفشان مقاومت در برابر حملات رایانه‌های کوانتومی قدرتمند آینده است.

این موضوع به معنی آن نیست که هر مدیر سایت باید امروز تمام TLS Stack خود را شخصاً به الگوریتم جدید تبدیل کند.

مهم‌تر این است که سازمان‌ها Crypto Inventory داشته باشند و بدانند در کجا از Public-key Cryptography استفاده می‌کنند تا هنگام Migrationهای استاندارد بتوانند برنامه‌ریزی کنند.

OWASP Top 10 2025 نیز آمادگی برای Post-Quantum Cryptography را در توصیه‌های Cryptographic Failures مطرح کرده است.

Crypto Agility چیست؟

Crypto Agility یعنی سیستم طوری طراحی شود که Algorithm، Key Size، Certificate یا Cryptographic Provider بدون بازنویسی اساسی تمام Application قابل تغییر باشد.

فرض کنید Algorithm به‌کاررفته امروز امن است اما پنج سال دیگر Recommendation تغییر می‌کند.

اگر نام Algorithm و Key Handling در صدها قسمت Source Code Hard-code شده باشد، Migration بسیار پرهزینه خواهد شد.

اما اگر Cryptographic Layer مرکزی و قابل مدیریت باشد، تغییر ساده‌تر خواهد بود.

Crypto Agility مخصوصاً برای سیستم‌هایی که عمر طولانی دارند اهمیت بیشتری پیدا می‌کند.

چگونه Cryptographic Failures را در یک سایت بررسی کنیم؟

بررسی این ریسک باید با Data Inventory آغاز شود.

ابتدا مشخص کنید:

چه اطلاعات حساسی وجود دارد؟

کجا ذخیره می‌شود؟

از چه مسیرهایی منتقل می‌شود؟

چه Serviceهایی آن را دریافت می‌کنند؟

چه افرادی دسترسی دارند؟

چه Keyهایی استفاده می‌شوند؟

Keyها کجا نگهداری می‌شوند؟

Passwordها چگونه Hash می‌شوند؟

Tokenها چگونه تولید می‌شوند؟

TLS کجا Terminate می‌شود؟

Backupها کجا هستند؟

سپس Data Flow Diagram می‌تواند مسیر انتقال اطلاعات را نشان دهد.

این بررسی به تیم امنیت کمک می‌کند نقاطی را پیدا کند که Data از حالت Protected به Unprotected تغییر می‌کند.

Code Review برای ضعف‌های رمزنگاری

در Secure Code Review باید دنبال الگوهای پرریسک بود.

برای مثال:

استفاده از Random Generator غیرامن

Algorithm قدیمی

Key Hard-coded

Password Encryption

Hash سریع Password

Custom Crypto

استفاده اشتباه از IV یا Nonce

Secret داخل Repository

غیرفعال کردن Certificate Validation

استفاده از HTTP

Secret داخل Client Code

Key بدون Rotation Mechanism

ثبت Plaintext Data در Log

هدف Review نباید فقط پیدا کردن نام Algorithm باشد.

Context استفاده مهم‌تر است.

SAST و DAST چقدر به کشف Cryptographic Failures کمک می‌کنند؟

SAST می‌تواند برخی Patternهای ناامن را در Code پیدا کند.

برای مثال:

Algorithm قدیمی

Hard-coded Secret

استفاده نادرست از بعضی APIها

Random Generator نامناسب

DAST نیز می‌تواند مواردی مانند TLS Configuration یا رفتار Application در زمان اجرا را بررسی کند.

اما هیچ اسکنری به‌تنهایی نمی‌تواند تمام معماری Key Management یا Threat Model را درک کند.

بنابراین Tool باید مکمل Code Review و Architecture Review باشد، نه جایگزین آن.

راهکارهای اصلی جلوگیری از Cryptographic Failures

برای کاهش ریسک، رویکرد لایه‌ای لازم است.

۱. اطلاعات حساس را شناسایی کنید

بدون Data Classification نمی‌توان تصمیم گرفت چه اطلاعاتی نیازمند Encryption هستند.

۲. داده غیرضروری را ذخیره نکنید

Data Minimization سطح حمله و پیامد Data Breach را کاهش می‌دهد.

۳. تمام ارتباطات حساس را با TLS محافظت کنید

ارتباط Browser، API، Microservice و Backend باید براساس Threat Model بررسی شود.

۴. Password را با Algorithm مخصوص Password Hashing ذخیره کنید

برای Application جدید، Recommendation فعلی OWASP استفاده از Argon2id در صورت امکان است.

۵. Key و Secret را از Code جدا کنید

از Secret Manager، Key Vault، HSM یا راهکارهای استاندارد Platform استفاده شود.

۶. از Algorithm و Library معتبر استفاده کنید

پیاده‌سازی Cryptography سفارشی ایجاد نکنید مگر در شرایط پژوهشی تخصصی و با Review مناسب.

۷. از CSPRNG برای Tokenهای امنیتی استفاده کنید

Randomness باید متناسب با کاربرد امنیتی باشد.

۸. Key Lifecycle تعریف کنید

Generation، Storage، Rotation، Revocation و Destruction باید Policy داشته باشند.

۹. از Authenticated Encryption استفاده کنید

در کاربردهای مناسب Confidentiality و Integrity را همزمان در نظر بگیرید.

۱۰. Crypto Inventory ایجاد کنید

بدانید Application در چه جاهایی از Algorithm، Key، Certificate و Protocol رمزنگاری استفاده می‌کند.

چک‌لیست امنیتی Cryptographic Failures برای مدیر سایت

<table> <thead> <tr> <th>کنترل</th> <th>سؤال امنیتی</th> </tr> </thead> <tbody> <tr> <td>HTTPS</td> <td>آیا تمام صفحات و ارتباطات حساس از HTTPS استفاده می‌کنند؟</td> </tr> <tr> <td>TLS</td> <td>آیا Protocolها و Configurationهای قدیمی حذف شده‌اند؟</td> </tr> <tr> <td>HSTS</td> <td>آیا استفاده از HTTPS در سطح Browser به‌درستی enforce می‌شود؟</td> </tr> <tr> <td>Password Storage</td> <td>آیا Passwordها با Password Hashing مناسب ذخیره می‌شوند؟</td> </tr> <tr> <td>Key Storage</td> <td>آیا Keyها خارج از Source Code و در محل امن نگهداری می‌شوند؟</td> </tr> <tr> <td>Secret Management</td> <td>آیا API Key و Tokenهای حساس تحت مدیریت مرکزی هستند؟</td> </tr> <tr> <td>Randomness</td> <td>آیا Tokenهای امنیتی با CSPRNG تولید می‌شوند؟</td> </tr> <tr> <td>Encryption at Rest</td> <td>آیا داده حساس ذخیره‌شده متناسب با Threat Model محافظت می‌شود؟</td> </tr> <tr> <td>Backup</td> <td>آیا Backupها نیز سطح حفاظتی مناسب دارند؟</td> </tr> <tr> <td>Logging</td> <td>آیا Secret و اطلاعات حساس وارد Log نمی‌شوند؟</td> </tr> <tr> <td>Key Rotation</td> <td>آیا برای Keyها Lifecycle و Rotation تعریف شده است؟</td> </tr> <tr> <td>Algorithm</td> <td>آیا از Algorithmها و Libraryهای استاندارد و پشتیبانی‌شده استفاده می‌شود؟</td> </tr> <tr> <td>Repository</td> <td>آیا Secret Scan و کنترل دسترسی روی Repository وجود دارد؟</td> </tr> <tr> <td>Crypto Agility</td> <td>آیا امکان Migration از Algorithm یا Key قدیمی وجود دارد؟</td> </tr> <tr> <td>Monitoring</td> <td>آیا تغییرات Key و Secret قابل Audit هستند؟</td> </tr> </tbody> </table>

Cryptographic Failures را چه زمانی باید تست کنیم؟

بررسی رمزنگاری نباید فقط یک مرحله قبل از Launch باشد.

زمان‌های مهم عبارت‌اند از:

هنگام طراحی Architecture

هنگام اضافه کردن Login

هنگام ساخت Password Reset

هنگام اتصال Payment Gateway

هنگام اضافه شدن API جدید

هنگام مهاجرت Cloud

هنگام تغییر Database

هنگام تغییر Certificate

هنگام اضافه شدن Secret جدید

پس از Incident

هنگام Upgrade Framework

هنگام تغییر Encryption Library

هنگام تغییر Compliance Requirement

و به شکل دوره‌ای در Security Review.

Security Lifecycle باید دائمی باشد.

پاسخ به یک سؤال مهم: آیا Encryption همیشه از Data Breach جلوگیری می‌کند؟

خیر.

Encryption یکی از کنترل‌های بسیار مهم است اما نمی‌تواند جای Access Control، Authentication، Secure Design و Server Hardening را بگیرد.

اگر مهاجم از طریق Application قانونی به Plaintext Data دسترسی پیدا کند، Encryption at Rest لزوماً مانع مشاهده اطلاعات نمی‌شود، زیرا Application خودش Key موردنیاز برای Decryption را دارد.

Encryption باید در کنار کنترل‌های دیگری مانند:

Least Privilege

Authorization

Segmentation

Logging

Monitoring

Secret Management

Hardening

Secure Coding

استفاده شود.

امنیت وب نتیجه یک Control منفرد نیست.

سوالات متداول درباره Cryptographic Failures

Cryptographic Failures چیست؟

Cryptographic Failures مجموعه‌ای از ضعف‌های امنیتی ناشی از نبود یا استفاده نادرست از رمزنگاری است. این ضعف‌ها شامل Algorithm ضعیف، Password Hashing نامناسب، Key Management ضعیف، TLS ناامن، Randomness قابل پیش‌بینی و نگهداری نادرست Secretها می‌شوند.

Cryptographic Failures در OWASP Top 10 2025 چه رتبه‌ای دارد؟

Cryptographic Failures در OWASP Top 10 2025 با شناسه A04 در رتبه چهارم قرار دارد. این دسته نسبت به نسخه ۲۰۲۱ دو رتبه پایین‌تر آمده است.

آیا MD5 امن است؟

MD5 برای کاربردهای امنیتی مدرنی که به Collision Resistance نیاز دارند مناسب محسوب نمی‌شود. همچنین نباید از MD5 برای Password Storage استفاده کرد.

آیا SHA-256 برای ذخیره Password مناسب است؟

SHA-256 ساده برای Password Storage توصیه نمی‌شود زیرا یک Hash سریع عمومی است. Password باید با الگوریتم‌های اختصاصی Password Hashing مانند Argon2id یا گزینه‌های استاندارد متناسب با محیط ذخیره شود.

بهترین روش ذخیره Password چیست؟

Recommendation فعلی OWASP برای سیستم‌های جدید استفاده از Argon2id در صورت پشتیبانی Platform است. OWASP همچنین scrypt و برای برخی سناریوها bcrypt یا PBKDF2 را مطرح می‌کند.

تفاوت Hash و Encryption چیست؟

Encryption برگشت‌پذیر است و با Key مناسب می‌توان Plaintext را بازیابی کرد. Hashing استاندارد یک‌طرفه است و برای کاربردهایی مانند Password Verification استفاده می‌شود.

Base64 رمزنگاری است؟

خیر. Base64 فقط Encoding است و هر فردی می‌تواند داده را Decode کند.

آیا HTTPS جلوی Cryptographic Failures را می‌گیرد؟

HTTPS فقط بخش مهمی از حفاظت داده در Transit است. Password Storage، Key Management، Encryption at Rest، Secure Randomness و Secret Management همچنان باید جداگانه بررسی شوند.

TLS 1.3 چیست؟

TLS 1.3 نسخه مدرن TLS برای حفاظت از ارتباطات شبکه است. TLS 1.2 نیز همچنان در بسیاری از محیط‌ها استفاده می‌شود، اما نسخه‌های قدیمی TLS نباید برای وب مدرن استفاده شوند.

HSTS چه کاری انجام می‌دهد؟

HSTS به Browser اعلام می‌کند Domain باید فقط از طریق HTTPS در دسترس قرار گیرد و به کاهش برخی سناریوهای Downgrade از HTTPS به HTTP کمک می‌کند.

آیا Encryption Key را می‌توان داخل Database ذخیره کرد؟

بسته به Architecture ممکن است Key Material در سیستم‌های مختلف ذخیره شود، اما Master Key نباید بدون حفاظت مناسب در همان محل و همان سطح دسترسی Data رمزگذاری‌شده قرار گیرد. استفاده از HSM، Key Vault یا سرویس مدیریت Key می‌تواند جداسازی و کنترل بهتری فراهم کند.

HSM چیست؟

Hardware Security Module یک سخت‌افزار تخصصی برای نگهداری و اجرای عملیات رمزنگاری روی Keyهای حساس است. هدف آن کاهش Exposure مستقیم Key Material به Application و سیستم‌های عمومی است.

آیا API Key باید رمزگذاری شود؟

API Key یک Secret است و باید براساس Threat Model، نوع Storage و نیاز Application محافظت شود. قرار دادن آن در Front-end Code یا Repository عمومی روش امنی نیست.

آیا استفاده از AES به معنی امن بودن Encryption است؟

خیر. Mode، Key Management، IV/Nonce، Library، Authentication و نحوه استفاده از Algorithm نیز تعیین‌کننده امنیت هستند.

CSPRNG چیست؟

CSPRNG یا Cryptographically Secure Pseudo-Random Number Generator مولدی برای ایجاد مقادیر غیرقابل پیش‌بینی در کاربردهای امنیتی مانند Token و Key است.

چرا Random Token قابل پیش‌بینی خطرناک است؟

اگر مهاجم بتواند الگوی Token را حدس بزند، ممکن است Tokenهای Password Reset، Session یا عملیات حساس قابل پیش‌بینی شوند.

آیا Encryption سفارشی امن است؟

طراحی Algorithm رمزنگاری اختصاصی عموماً توصیه نمی‌شود. استفاده از Primitiveها و Libraryهای استاندارد و بررسی‌شده گزینه بسیار امن‌تری است.

Post-Quantum Cryptography چیست؟

Post-Quantum Cryptography مجموعه Algorithmهایی است که برای مقاومت در برابر حملات بالقوه رایانه‌های کوانتومی آینده طراحی شده‌اند. NIST در سال ۲۰۲۴ اولین استانداردهای اصلی این حوزه شامل FIPS 203، FIPS 204 و FIPS 205 را منتشر کرد.

جمع‌بندی

Cryptographic Failures یکی از بنیادی‌ترین ریسک‌های امنیت برنامه‌های وب است، زیرا تقریباً تمام سرویس‌های مدرن برای محافظت از Password، Session، Token، Credential، اطلاعات کاربران و ارتباطات شبکه به Cryptography وابسته‌اند.

اما رمزنگاری زمانی مؤثر است که تمام اجزای آن درست طراحی شده باشند.

قرار دادن HTTPS روی سایت کافی نیست.

استفاده از AES به‌تنهایی کافی نیست.

Hash کردن Password با هر Algorithmی کافی نیست.

حتی داشتن Secret Manager نیز در صورتی که دسترسی‌ها درست طراحی نشده باشند تضمین امنیت ایجاد نمی‌کند.

یک سیستم امن باید ابتدا اطلاعات حساس خود را شناسایی کند، Data Flow و Threat Model داشته باشد و مشخص کند هر Data در حالت Transit و Rest چگونه محافظت می‌شود.

Password باید با الگوریتم مخصوص Password Hashing ذخیره شود.

Encryption Key و Secret نباید در Source Code قرار بگیرند.

Key باید Lifecycle مشخص داشته باشد.

Tokenهای امنیتی باید با Random Generator رمزنگاری‌شده مناسب تولید شوند.

TLS باید به‌روز باشد و ارتباطات حساس نباید به HTTP یا Protocolهای منسوخ وابسته باشند.

Backup، Log، API، Microservice و سرویس‌های شخص ثالث نیز باید بخشی از همان ارزیابی باشند.

از طرف دیگر، تیم توسعه باید از طراحی Cryptography اختصاصی خودداری کند و به Libraryها، استانداردها و Implementationهای شناخته‌شده متکی باشد.

Cryptographic Failures در OWASP Top 10 2025 فقط یک هشدار درباره «Encryption ضعیف» نیست؛ بلکه یادآوری می‌کند حفاظت از داده یک زنجیره کامل است.

اگر یک حلقه از این زنجیره، مانند Password Storage، Key Management، Randomness، TLS یا Secret Handling شکست بخورد، ممکن است امنیت کل سیستم تحت تأثیر قرار گیرد.

در نهایت بهترین رویکرد برای مقابله با Cryptographic Failures این است که Cryptography از یک قابلیت پراکنده در Code به یک بخش مدیریت‌شده از معماری امنیت تبدیل شود.

Data Classification، Threat Modeling، استانداردهای مدرن، Key Management، Secure Password Storage، TLS مناسب، Crypto Agility و بررسی دوره‌ای باید همزمان اجرا شوند.

به این ترتیب رمزنگاری به‌جای یک لایه ظاهری، واقعاً نقش خود را در حفاظت از اطلاعات حساس کاربران و زیرساخت سایت ایفا خواهد کرد.