टेस्टर के लिए क्रिप्टोग्राफ़ी

Mutqan Soft QA टीम द्वारा · अपडेट 6 अक्टूबर 2026 · 21 मिनट · मध्यम

Cryptography उन गणितीय tools का समूह है जो data की रक्षा करते हैं: hashing एक fixed-length fingerprint बनाती है जिसे उलटा नहीं किया जा सकता, encryption data को ऐसा छिपाती है कि सिर्फ़ key वाला ही पढ़ सके, और HMAC साबित करता है कि message उसी पक्ष से आया है जिसके पास shared secret है और रास्ते में बदला नहीं गया। Base64 जैसी encoding सुरक्षा का tool है ही नहीं, भले ही वह वैसी दिखे: वह सिर्फ़ data का रूप बदलती है, और कोई भी उसे उलटा कर सकता है।

उदाहरण: एक sign-up form password password123 को cGFzc3dvcmQxMjM= के रूप में store करता है। Value "encrypted" दिखती है, पर यह सिर्फ़ Base64 है और कोई भी decoder इसे एक second में वापस खोल देता है। सही value Argon2id जैसी धीमी, salted password hash का output होती, जिसे वापस password में बदला नहीं जा सकता। जो tester दोनों में फ़र्क़ पहचानता है, वह ऐसा defect पकड़ता है जो हर functional test से छूट जाता है।

यह क्यों ज़रूरी है

कोई product अपने सभी passwords, card numbers या session tokens खो सकता है जबकि हर feature "काम करती" हो: बस values reversible encoding में या बिना salt वाली fast hash से store हों, या कोई जाली webhook इसलिए स्वीकार हो जाए क्योंकि किसी ने उसकी signature verify नहीं की। OWASP Top 10 इन मामलों को A04:2025 Cryptographic Failures के अंतर्गत रखती है, और functional testing इन्हें नहीं पकड़ती, क्योंकि user की अपनी journey सफल रहती है।

Tester को गणित नहीं चाहिए। Tester को तीन चीज़ें चाहिए: सामने दिखी value की किस्म उसके रूप से पहचानना; जानना कि कौन-सा tool किस मक़सद के लिए है (encoding transport के लिए, hashing integrity और passwords के लिए, HMAC origin साबित करने के लिए, encryption confidentiality के लिए); और सही सवाल पूछना: key कहाँ है, verify कौन करता है, और leak हो जाए तो क्या होगा?

Encoding, hashing और encryption तीन अलग चीज़ें हैं

Encoding data का representation एक सार्वजनिक नियम से बदलती है जिसमें कोई secret नहीं होता। Base64 (RFC 4648) हर 3 bytes को 64-character alphabet के 4 characters में बदलती है और ज़रूरत पड़ने पर output के अंत को = से pad करती है; hex हर byte को दो digits में लिखता है। मक़सद bytes को text, URL या HTTP header के अंदर सुरक्षित ढंग से ले जाना है, जैसे HTTP headers और Authentication and authorization वाले पाठों में Basic Authorization header करता था। जिसके पास output है, उसके पास input है।

Hashing किसी भी input को fixed-length fingerprint में बदलती है: SHA-256 में 64 hex characters, SHA-1 में 40, MD5 में 32। एक ही input हमेशा एक ही hash देता है, hash से input वापस नहीं निकाला जा सकता, और एक character बदलने से पूरा hash बदल जाता है। Systems इसे यह जाँचने के लिए इस्तेमाल करते हैं कि file सही-सलामत है और data को store किए बिना उसकी तुलना करने के लिए। जहाँ security इन पर निर्भर हो, वहाँ MD5 और SHA-1 इस्तेमाल नहीं होने चाहिए: दोनों के लिए एक ही hash वाले दो अलग inputs (collision) बनाने के व्यावहारिक तरीक़े प्रकाशित हो चुके हैं।

Encryption data को ऐसे छिपाती है कि वह सिर्फ़ key से वापस मिले। Symmetric encryption (जैसे AES) में encrypt और decrypt की key एक ही होती है; asymmetric encryption (RSA और elliptic curves) में key pair होता है, जहाँ जो public key से encrypt हुआ, उसे सिर्फ़ private key decrypt कर सकती है। TLS दोनों इस्तेमाल करता है: server की पहचान और keys तय करने के लिए asymmetric, और data के लिए symmetric। तीनों को अलग करने वाला सवाल यह है: क्या इसे उलटा किया जा सकता है, और उलटने के लिए ज़रूरी चीज़ किसके पास है?

Encoding को कोई भी उलटा कर सकता है, hash को कोई नहीं, HMAC hash में key जोड़कर साबित करता है कि message किसने भेजा, और सिर्फ़ encryption ही reversible और key से सुरक्षित दोनों है।

EncodingBase64 · RFC 4648

Bytes के लिखने का तरीक़ा बदलती है, एक सार्वजनिक नियम से, बिना secret

cGFzc3dvcmQxMjM=

Key चाहिए:: नहीं
Reversible:: हाँ, कोई भी
क्या बचाता है:: कुछ नहीं: सिर्फ़ transport
कहाँ मिलता है:: Basic header, JWT के हिस्से, data URLs
Tester पूछता है:: क्या इसे सुरक्षा समझा जा रहा है?

HashingSHA-256 · FIPS 180-4

Input का fixed-length fingerprint; एक ही input हमेशा एक ही hash देता है

ef92b778bafe771e…

Key चाहिए:: नहीं
Reversible:: नहीं
क्या बचाता है:: Integrity: कोई भी बदलाव दिख जाता है
कहाँ मिलता है:: File checksums, commit ids, fingerprints
Tester पूछता है:: क्या यह MD5 या SHA-1 है? क्या passwords के लिए बिना salt और work factor इस्तेमाल हो रही है?

HMACRFC 2104

Shared secret key से बनाई गई hash

2b46560cfc07e738…

Key चाहिए:: हाँ, दोनों पक्षों के पास साझा
Reversible:: नहीं
क्या बचाता है:: Integrity और origin
कहाँ मिलता है:: Webhook signatures, HS256 JWTs, signed cookies
Tester पूछता है:: क्या गलत और गायब signature reject होती है? Replay handle होता है?

EncryptionAES · RSA · TLS

Data को छिपाती है; ciphertext हर बार अलग होता है और सिर्फ़ key उसे वापस लाती है

Key चाहिए:: हाँ: एक shared key, या public और private pair
Reversible:: हाँ, key से
क्या बचाता है:: Confidentiality
कहाँ मिलता है:: TLS, data at rest, encrypted backups
Tester पूछता है:: Key किसके पास है? कौन-से TLS versions? Key rotate कैसे होती है?

Values input password123 के लिए Base64, SHA-256 और HMAC-SHA256 के असली outputs हैं, test key test-secret के साथ; दोनों digests छोटे किए गए हैं।

पाठ संस्करण

Input: password123

Encoding    Base64       cGFzc3dvcmQxMjM=
                         anyone can decode it: no key, no secret
Hashing     SHA-256      ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f
                         one way, fixed length, same input -> same output
            MD5 (legacy) 482c811da5d5b4bc6d497ffa98491e38
                         32 hex characters; not for anything security-related
HMAC        HMAC-SHA256  2b46560cfc07e738b1b40765b282308026cdd5b9d2aae58be8a347b1293a82e7
                         key: test-secret; only a key holder can compute or check it
Encryption  AES-256-GCM  <ciphertext + nonce>, different on every run
                         reversible only with the key

आज़माएँ: Base64 डिकोडर आज़माएँ: SHA-256 जनरेटर आज़माएँ: MD5 जनरेटर

HMAC और signatures: key वाली hash जो origin साबित करती है

अकेली hash बदलाव पकड़ती है पर origin साबित नहीं करती: जो message बदले, वह उसकी नई hash भी निकाल सकता है। HMAC (RFC 2104) गणना में एक secret key मिलाकर इसे हल करता है: HMAC-SHA256(key, message)। सही value सिर्फ़ key वाला ही बना या जाँच सकता है, इसलिए value दो बातें एक साथ साबित करती है: message बदला नहीं गया, और वह उसी से आया जिसके पास secret है। HMAC message को छिपाता नहीं; यह encryption नहीं है।

यह आपको webhook signatures (X-Signature-256 जैसा header), HS256 से signed JWTs (जो HMAC-SHA256 ही है) और signed links व cookies में मिलेगा। Digital signature (जैसे RS256 या ES256) वही काम asymmetric keys से करती है: private key sign करती है और public key verify करती है, इसलिए verifier को कोई secret नहीं चाहिए। दोनों मामलों में token decode करना एक बात है और उसकी signature verify करना दूसरी, जैसा JWT guide समझाता है।

वही body, सही signature: स्वीकार हो। Body का एक character बदलें और signature वही रखें: reject होना चाहिए।
गलत secret से बनी signature, या signature header ही नहीं: दोनों reject होने चाहिए। जो server header के बिना request स्वीकार करता है, वह verify ही नहीं कर रहा।
पुराना, valid request दोबारा भेजना: अकेला HMAC इसे नहीं रोकता। पूछें कि signed material में timestamp शामिल है या नहीं और पुराने reject होते हैं या नहीं।
Developer से पूछें कि दो values की तुलना कैसे होती है: आम सिफ़ारिश constant-time comparison है, जिसमें समय उतना ही लगता है चाहे कितने भी characters मेल खाएँ, ताकि response time किसी अनुमान के बारे में कुछ न बताए। यह बाहर से दिखती नहीं।

Partner -> your server

POST /webhooks/payments HTTP/1.1
Host: shop.example.com
Content-Type: application/json
X-Signature-256: sha256=ff40b419851351c2ed7966278bc1d026ecbac717fbbbfebfb068715b3860c4d7

{"event":"order.paid","orderId":"ORD-1042","amount":"249.00"}

Check on your server: HMAC-SHA256(secret, raw body) == the value after "sha256="?
  yes -> process the event      no -> reject it (for example with 401)
Secret for this example: whsec_test_key. Change one byte of the body, or the secret,
and the computed value no longer matches.

आज़माएँ: HMAC जनरेटर आज़माएँ: Webhook सिग्नेचर एनालाइज़र

Password hashing एक विशेष मामला है

Passwords कमज़ोर inputs हैं: छोटे, अनुमान-योग्य और बार-बार दोहराए गए। इसलिए SHA-256 जैसी fast hash काफ़ी नहीं, क्योंकि database हासिल करने वाला attacker अरबों आम passwords की hashes निकालकर तुलना कर सकता है। हल के दो हिस्से हैं: हर user के लिए अलग random salt, ताकि एक ही password चुनने वाले दो users की stored values अलग हों और precomputed tables बेकार हो जाएँ; और ऐसी function जो जान-बूझकर धीमी बनाई गई हो (Argon2id और scrypt में memory-महँगी भी), जिसकी देरी एक login सह लेता है पर एक अरब अनुमान नहीं सह सकते।

OWASP की Password Storage cheat sheet पहले Argon2id, फिर scrypt, legacy systems के लिए bcrypt और जहाँ FIPS-140 compliance (cryptographic modules के लिए अमेरिकी सरकार का standard) ज़रूरी हो वहाँ PBKDF2 की सिफ़ारिश करती है। ये algorithms salt खुद बनाते हैं और उसे value के अंदर, algorithm के नाम और उसके parameters के साथ store करते हैं; salt कोई secret नहीं है, उसका काम सिर्फ़ हर stored value को अलग बनाना है। इसलिए आप इन values को उनके रूप से पहचान सकते हैं, जैसे उदाहरण में।

एक ही password से दो accounts बनाएँ: stored values अलग होनी चाहिए (हर user के लिए salt)।
Forgot password: reset link आना चाहिए, मौजूदा password कभी नहीं। जो system उसे भेज सकता है, वह उसे reversible रूप में store करता है।
bcrypt हो तो याद रखें कि यह 72 bytes के बाद का सब कुछ छोड़ देता है: 80 characters का password रखें, फिर आख़िरी character बदलकर login करें। Login हो जाए तो length limit के बारे में पूछें।
Value देखें, नाम नहीं: password_hash नाम के column में Base64 या MD5 भी हो सकता है।

Two users, both chose password123

Unsalted SHA-256 (defect): identical values, and easy to look up in precomputed tables
  user A  ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f
  user B  ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f

Argon2id (accepted): algorithm, parameters, random salt and hash; different per user
  user A  $argon2id$v=19$m=19456,t=2,p=1$<salt A>$<hash A>
  user B  $argon2id$v=19$m=19456,t=2,p=1$<salt B>$<hash B>

bcrypt (accepted): $2b$<cost>$<22-character salt><31-character hash>, 60 characters

TLS और keys: जहाँ ये tools system से मिलते हैं

HTTP और HTTPS पाठ ने handshake, certificates और chain of trust समझाई थी। इस पाठ के नज़रिए से TLS (version 1.3 के लिए RFC 8446) वह सबसे आम जगह है जहाँ ये tools साथ काम करते हैं: server की पहचान के लिए certificate और digital signature, keys तय करने के लिए asymmetric cryptography, उन keys को derive करने और handshake की पुष्टि के लिए hashes और HMAC, फिर गुज़रने वाले हर byte पर integrity check के साथ symmetric encryption। इसलिए plain HTTP पर भेजा गया हर password, token और card number इन सभी सुरक्षाओं के बिना जाता है।

स्वीकार्य versions: सिर्फ़ TLS 1.2 और 1.3; पुराने versions और पूरा SSL deprecated है। इसे हर environment पर जाँचें, सिर्फ़ production पर नहीं। API Endpoint Tester किसी public endpoint का TLS और HSTS दिखाता है; server अब भी कौन-कौन से versions स्वीकार करता है, यह list करने के लिए TLS scanner चाहिए, जैसे nmap --script ssl-enum-ciphers -p 443 <host>, जिसे सिर्फ़ उन hosts पर चलाएँ जिन्हें test करने की आपको अनुमति है।
हर entry point: API, web app, mobile app, आपके server से partner को जाने वाला webhook और services के बीच internal calls, सिर्फ़ home page नहीं।
Test clients certificates वैसे ही verify करें जैसे असली users करते हैं; verification को "अभी के लिए" बंद करना test setup का ही defect है।
Keys और secrets: front-end bundle या mobile app में embedded key असल में public है; Math.random() से बना secret पर्याप्त random नहीं; और पूछें कि leak होने पर key rotate कैसे होती है।
यहाँ "encrypted at rest" का मतलब क्या है? पूछें कि key किसके पास है: अगर application server सब कुछ decrypt कर सकता है, तो उसे compromise करने वाला भी कर सकता है।

आज़माएँ: API एंडपॉइंट टेस्टर

Worked example: payment और webhook feature की समीक्षा

आप एक नई feature test कर रहे हैं: customer account बनाता है, card save करता है, और payment partner हर payment की सूचना webhook से आपके server को देता है। Design और data review के दौरान आपको चार values दिखती हैं:

users.password में cGFzc3dvcmQxMjM= है: Base64, यानी database पढ़ने वाले हर व्यक्ति के लिए plain password। Defect; report में test environment की decoded value लगाएँ, किसी असली user का password कभी नहीं।
cards.pan_masked **** 4242 दिखाता है, पर /profile response में Base64 वाला cardRef है जो पूरे card number में decode होता है। Sensitive data exposure का defect, जिसकी root cause encoding को encryption समझना है।
Webhook में X-Signature-256 है, फिर भी वही request header के बिना 200 के साथ स्वीकार हो जाता है। Server verify नहीं कर रहा; URL जानने वाला कोई भी "payment received" घोषित कर सकता है। Defect।
api-staging पर TLS check दिखाता है कि TLS 1.0 स्वीकार होता है। Platform team के लिए finding, एक सवाल के साथ: क्या production भी ऐसे ही configured है?

आम गलतियाँ

Base64, hex या URL encoding को सुरक्षा समझना: "card number encoded है" का मतलब है कि वह पढ़ा जा सकता है।
Bug report या requirement में "encrypted" लिखना जब मतलब "hashed" हो, या developers से किसी hash को "decrypt" करने को कहना: गलत शब्द गलत fix की ओर ले जाता है।
"Passwords hashed हैं" को यह पूछे बिना मान लेना कि algorithm कौन-सी है और salt है या नहीं; password storage के लिए अकेली SHA-256 defect है।
JWT या webhook decode करके उसकी सामग्री जाँचना और signature verify किए बिना उस पर भरोसा करना, या signature check का सिर्फ़ happy path test करना और कभी गलत signature न भेजना।
Value को उसके दिखावे से आँकना: 64 characters की random-सी दिखने वाली string किसी password की unsalted SHA-256 या encoded, predictable identifier हो सकती है।
Algorithms को ही तोड़ने की कोशिश करना, या ऐसे systems पर कोशिश करना जो आपके नहीं: tester जाँचता है कि सही tool सही तरीक़े से इस्तेमाल हुआ, और सिर्फ़ उन systems पर जिन्हें test करने की उसके पास लिखित अनुमति है।

QA का नज़रिया

व्यवहार में यह पाठ तीन मौकों पर सामने आता है: किसी भी ऐसी feature की requirements और design review के दौरान जो कोई secret (password, token, card, partner key) store या transmit करती है, जहाँ आप पूछते हैं "इस value को ठीक-ठीक क्या बचा रहा है, key किसके पास है, और leak हो जाए तो क्या होगा?"; API या webhook integration के दौरान, जहाँ आप signature verification को सिर्फ़ सही नहीं, गलत requests से भी test करते हैं; और authentication या infrastructure बदलने वाली किसी भी release से पहले, जब TLS दोबारा जाँचा जाता है। साथी हैं storage algorithms के लिए developers, certificates और keys के लिए platform team, और security team जहाँ हो।

Report में देखी गई value का रूप (length, alphabet, prefix), उसकी जगह (column, field, header), वह कारण जिससे वह अपने मक़सद पर खरी नहीं उतरती, और वह test जो इसे साबित करता है, लिखें। Report में कभी असली secret या असली user का password न रखें: test accounts इस्तेमाल करें और बाक़ी सब mask करें। Tool और algorithm का सही नाम developer को सीधे fix तक पहुँचा देता है।

अभ्यास

Values को classify करें और तय करें कि क्या test करना है

आपका काम

एक shop application की staging environment test करते समय आपको database export और requests में नीचे की पाँच values दिखीं। हर value के लिए तय करें: यह encoding है, hashing, HMAC, encryption या TLS setting? क्या यह अपने मक़सद पर खरी उतरती है? अगला test या सवाल क्या है?

जहाँ मदद मिले वहाँ Mutqan tools के Base64 Decoder, MD5 और SHA-256 generators और Webhook Signature Analyzer का इस्तेमाल करें, और सिर्फ़ test data के साथ काम करें।

सामग्री

1. users.password            cGFzc3dvcmQxMjM=
2. legacy_users.pwd          482c811da5d5b4bc6d497ffa98491e38
3. users.password_hash       $2b$12$<22-character salt><31-character hash>
4. incoming webhook header   X-Signature-256: sha256=<64 hex characters>
5. api-staging.example.com   TLS check: accepts TLS 1.0, 1.2 and 1.3

चरण

रूप देखें: length, alphabet, prefix और अंत में =।
तय करें: क्या इसे उलटा किया जा सकता है, और क्या इसके लिए key चाहिए?
इसे उस मक़सद से मिलाएँ जिसके लिए यह इस्तेमाल हो रही है।
वह test या सवाल लिखें जो defect साबित करे या ख़ारिज करे।

मॉडल उत्तर दिखाएँ

मॉडल उत्तर

Value 1: Base64 (= पर ख़त्म, password123 में decode होती है)। Password reversible रूप में store है, जो plain text जितना ही बुरा है। Defect; test यही है कि आप खुद decode करें, और report में column लिखें और यह कि database पढ़ने वाले हर व्यक्ति के पास सारे passwords हैं।

Value 2: 32 hex characters, यानी MD5 hash की length। password123 (value 1 से decode हुआ password) को MD5 Generator से hash करें: नतीजा ठीक यही value है, यानी बिना salt का MD5। Defect: fast, deprecated function, बिना salt, इसलिए एक ही password चुनने वाले हर user की value एक जैसी है। सिर्फ़ length से MD5 का अंदाज़ा लगता है; किसी ज्ञात password से मेल इसे साबित करता है।

Value 3: cost 12 वाला bcrypt, स्वीकार्य (OWASP कम से कम 10 का work factor माँगती है)। Tests: एक ही password वाले दो accounts की values अलग हों; forgot password link भेजे, password नहीं; 80 characters का password आख़िरी character बदलने पर login न हो, वरना 72-byte limit के बारे में पूछें।

Value 4: sha256= के बाद 64 hex characters HMAC-SHA256 पर फिट होते हैं, पर body की सादी SHA-256 पर भी; रूप से दोनों में फ़र्क़ नहीं दिखता। किसी captured request की raw body की SHA-256 निकालें: अगर वह value के बराबर है, तो कोई key नहीं और कोई भी इसे forge कर सकता है (defect)। अगर Webhook Signature Analyzer test secret के साथ HMAC-SHA256 की पुष्टि करे, तो design सही है; फिर test करें कि एक character बदली body, गलत secret और गायब header, तीनों reject हों, और पूछें कि क्या कोई timestamp पुराने valid request को दोबारा भेजने से रोकता है।

Value 5: TLS setting, algorithm नहीं; TLS 1.0 स्वीकार होना platform team के लिए finding है: सिर्फ़ 1.2 और 1.3 की अनुमति हो। पूछें कि production की setting भी यही है या नहीं, और HTTP और HTTPS पाठ की तरह certificate और HTTP से HTTPS redirect की जाँच पूरी करें।

अक्सर पूछे जाने वाले सवाल

क्या hashing encryption की ही एक किस्म है?

नहीं। Encryption key से reversible है और उसका मक़सद confidentiality है; hashing one-way है, बिना key, और उसका मक़सद integrity और तुलना है। Requirement या report में दोनों को गड़बड़ करना गलत design की ओर ले जाता है, इसलिए सटीक शब्द इस्तेमाल करें।

हमारे passwords SHA-256 से hashed हैं। क्या यह काफ़ी है?

नहीं। SHA-256 बहुत तेज़ है, और बिना salt एक ही password चुनने वाले हर user को एक ही value देती है। Password storage को एक समर्पित धीमी, salted algorithm चाहिए: पहले Argon2id, या scrypt या bcrypt, या जहाँ FIPS compliance ज़रूरी हो वहाँ PBKDF2।

क्या मैं secret के बिना webhook signature या JWT verify कर सकता हूँ?

HMAC के मामले में नहीं: आप decode करके सामग्री पढ़ सकते हैं, पर HMAC verify करने के लिए shared secret चाहिए। RS256 और ES256 signatures को कोई secret नहीं चाहिए, सिर्फ़ public key, जिसे खुलकर share किया जा सकता है। Test environment का अपना test secret होना चाहिए, production का कभी नहीं।

क्या मुझे इन algorithms के पीछे का गणित समझना ज़रूरी है?

नहीं। Tester को value के रूप से tool पहचानना, यह जानना कि कौन-सा tool किस मक़सद के लिए है, और key, verification और rotation के बारे में पूछना आना चाहिए। Algorithms की अपनी सुरक्षा विशेषज्ञों का विषय है, और उसे ऐसे systems पर तोड़ने की कोशिश कभी न करें जो आपके नहीं।

संदर्भ

OWASP Cheat Sheet Series: Cryptographic StorageOWASP Foundationस्टोर किए गए डेटा के लिए कौन-सी एल्गोरिद्म और की-लंबाई इस्तेमाल करें, और की व रैंडमनेस कैसे प्रबंधित करें।
OWASP Cheat Sheet Series: Password StorageOWASP Foundationपासवर्ड कैसे स्टोर करें: Argon2id, scrypt या bcrypt सॉल्ट के साथ — कभी MD5, SHA-1 या बिना सॉल्ट के हैश नहीं।
RFC 2104: HMAC: Keyed-Hashing for Message AuthenticationIETF · 1997HMAC संरचना: एक सीक्रेट की और हैश फ़ंक्शन मिलकर मैसेज ऑथेंटिकेशन कोड कैसे बनाते हैं।
RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3IETF · 2018TLS 1.3 हैंडशेक और रिकॉर्ड प्रोटोकॉल जो HTTPS ट्रैफ़िक की रक्षा करते हैं।

टूल्स

और गहराई से

इस topic में आपकी प्रगति

इस topic से पहले

संवेदनशील डेटा एक्सपोज़र

अगले topics

वेब सिक्योरिटी टेस्टिंग इन प्रैक्टिस

टेस्टर के लिए क्रिप्टोग्राफ़ी

यह क्यों ज़रूरी है

Encoding, hashing और encryption तीन अलग चीज़ें हैं

HMAC और signatures: key वाली hash जो origin साबित करती है

Password hashing एक विशेष मामला है

TLS और keys: जहाँ ये tools system से मिलते हैं

Worked example: payment और webhook feature की समीक्षा

आम गलतियाँ

QA का नज़रिया

अभ्यास

Values को classify करें और तय करें कि क्या test करना है

अक्सर पूछे जाने वाले सवाल

संदर्भ

Mutqan tools से अभ्यास करें

SHA-256 जनरेटर

MD5 जनरेटर

HMAC जनरेटर

Webhook सिग्नेचर एनालाइज़र

Base64 डिकोडर

API एंडपॉइंट टेस्टर

और गहराई से

इस topic में आपकी प्रगति

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

यह क्यों ज़रूरी है

Encoding, hashing और encryption तीन अलग चीज़ें हैं

HMAC और signatures: key वाली hash जो origin साबित करती है

Password hashing एक विशेष मामला है

TLS और keys: जहाँ ये tools system से मिलते हैं

Worked example: payment और webhook feature की समीक्षा

आम गलतियाँ

QA का नज़रिया

अभ्यास

Values को classify करें और तय करें कि क्या test करना है

अक्सर पूछे जाने वाले सवाल

संदर्भ

Mutqan tools से अभ्यास करें

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics