Withdraw-सक्षम API keys को कठोरता से अस्वीकार करना: तकनीकी गहराई

अधिकांश trading platforms withdraw permission सक्षम के साथ API keys स्वीकार करते हैं। वे एक पीली चेतावनी banner दिखाते हैं, आपको "मैं समझता हूँ" टाइप करने के लिए कहते हैं, और फिर भी key को store कर देते हैं। हम ऐसा नहीं करते। यदि आपकी key के पास withdraw permission है, तो हम इसे onboarding पर अस्वीकार करते हैं और इसे कभी store नहीं करते। यह पोस्ट बताता है कि क्यों, कैसे, और विकल्प वास्तव में आपको क्या कीमत पर आता है।

Threat model एक अनुच्छेद में

कोई भी system जो एक withdraw-सक्षम API key रखता है, वह एक credential leak की दूरी पर है user accounts को खाली करने से। Leak को database breach होना जरूरी नहीं है — यह एक compromised employee laptop हो सकता है, एक misconfigured backup, एक third-party dependency में side-channel, या एक process-memory dump जो एक unencrypted log में आ सकता है। इन सभी चीजों ने हमसे बड़ी companies के साथ हो चुकी हैं। एकमात्र टिकाऊ defense है: किसी के भी funds की keys पहली जगह में न रखना।

Detection कैसे काम करता है

User द्वारा एक key paste करने के बाद पहली authenticated call पर, हम एक exchange-specific permission-introspection call करते हैं। अधिकांश major venues निम्नलिखित में से कोई एक expose करते हैं:

• एक dedicated "query API key info" endpoint जो permission set को एक structured field के रूप में return करता है, या
• एक account-info endpoint जहाँ key की permission scope response payload के हिस्से के रूप में included है।

हम किसी भी flag को देखते हैं जो withdraw, internal transfer, sub-account transfer out, या universal transfer out को grant करता है — venues एक ही विचार के लिए अलग-अलग नाम उपयोग करते हैं। यदि इनमें से कोई भी present है, तो हम secret को memory में तुरंत discard करते हैं, UI को एक structured error return करते हैं, और कभी भी key को हमारे database में नहीं लिखते।

Warn करने के बजाय hard-reject क्यों करें

Warnings को click through किया जाता है। हम कई products में साल भर इस data को देख रहे हैं। उपयोगकर्ताओं द्वारा "मैं समझता हूँ" टाइप करने का base rate बिना एक भी शब्द पढ़े 80% से अधिक है। एक warning जिसे 80% users ignore करते हैं, एक security control नहीं है; यह एक liability shield है।

Hard rejection विपरीत है। यह friction को सही जगह पर रखता है: user exchange पर वापस जाता है, trade permission only के साथ एक नई key बनाता है, वापस आता है, और वह paste करता है। पूरे loop की कीमत user को शायद दो मिनट है। Attacker को — worst-case credential leak scenario में — पूरे account की कीमत है।

Warn-instead-of-reject path आपको वास्तव में क्या कीमत पर आता है

Warn-and-store pattern user-friendly दिखता है जब तक आप न पूछें: worst-case क्या दिखता है? आपको एक hostile employee, एक supply-chain compromise, एक transitive dependency में एक side-channel, एक mis-scoped log मिलता है, और उत्तर यह है कि withdraw-सक्षम keys उन सभी कमजोर लोगों और कमजोर code के समान ही अच्छी हैं जिन्होंने कभी उन्हें छुआ है।

Hard-rejecting उस calculus को flip करता है। यहाँ तक कि एक worst-case full database compromise में भी, attacker read+trade keys के साथ चला जाता है। Trade-only keys नुकसान कर सकते हैं — वे positions को blow कर सकते हैं, fees को churn कर सकते हैं, open positions को illiquid pairs में dump कर सकते हैं — लेकिन वे withdraw नहीं कर सकते। Funds exchange पर ही रहते हैं। यह zero risk नहीं है, लेकिन यह वह risk है जिसके लिए आप sign up किए थे जब आपने एक automated trading agent को connect किया था।

हम अभी भी क्या defend नहीं कर सकते

हम pretend नहीं कर रहे कि hard rejection एक complete security posture है। यह एक control है। पूरा set हमारे security page पर documented है: KMS envelope encryption with per-user data keys, decrypted secrets जो केवल process memory में रहते हैं और केवल एक API call की अवधि के लिए, append-only hash-chained audit log, CI-tested cross-user isolation, और एक vulnerability disclosure program। Hard-rejecting withdraw permission सिर्फ उस stack का सबसे visible piece है — और सबसे आसान जो आप स्वयं verify कर सकते हैं, क्योंकि आप देख सकते हैं कि हम onboarding के दौरान real time में एक withdraw-सक्षम key को अस्वीकार करते हैं।