सुरक्षा पॉलिसी

1. दृष्टिकोण

VERA आपकी ओर से पोस्ट कर सकता है, मैसेज भेज सकता है और खर्च कर सकता है, इसलिए सबसे अहम सुरक्षा गुण क्रिप्टोग्राफ़िक नहीं है: वह यह है कि VERA आपके बिना कोई कार्रवाई नहीं करता। बाहरी कार्रवाइयाँ प्रस्तावों के रूप में दर्ज की जाती हैं और केवल आपकी मंज़ूरी के बाद, या आपके द्वारा खुद कॉन्फ़िगर किए गए ऑटोमेशन नियम के तहत ही लागू की जाती हैं। मंज़ूरी की यह शर्त उसी कोड पाथ में लागू की गई है जो कार्रवाइयों को अंजाम देता है, यह सिर्फ़ पॉलिसी में लिखी बात नहीं है।

दूसरा सिद्धांत यह है कि क्रेडेंशियल सबसे कीमती ख़ज़ाना हैं। VERA ऐसे प्लेटफ़ॉर्म के टोकन रखता है जो पैसे ट्रांसफ़र कर सकते हैं, दर्शकों के लिए पब्लिश कर सकते हैं और किसी व्यवसाय के खाते पढ़ सकते हैं। इन्हें एक ऐसी key से एन्क्रिप्ट किया जाता है जो बाकी सब चीज़ों से अलग है, और इन्हें न कभी इंटरफ़ेस पर वापस दिखाया जाता है, न लॉग में लिखा जाता है।

2. क्या व्यवस्था मौजूद है

नीचे दी गई हर चीज़ आज प्रोडक्ट में लागू है।

• ट्रांज़िट में एन्क्रिप्शन। सारा ट्रैफ़िक HTTPS पर दिया जाता है। प्रोडक्शन में, सामान्य HTTP अनुरोध एज पर स्थायी रूप से HTTPS पर रीडायरेक्ट किए जाते हैं, और HTTP Strict Transport Security दो साल के max-age, includeSubDomains और preload के साथ लागू किया जाता है।
• संग्रहीत सीक्रेट्स का एन्क्रिप्शन। कनेक्टर क्रेडेंशियल और API कुंजियाँ AES-256-GCM से एन्क्रिप्ट की जाती हैं, जो एक ऑथेंटिकेटेड सिफ़र है, इसलिए छेड़छाड़ किया गया सिफ़रटेक्स्ट बदला हुआ डेटा देने के बजाय डिक्रिप्ट ही नहीं होता। एन्क्रिप्शन कुंजी एक अलग, समर्पित वैल्यू है, जिसके लिए प्रोडक्शन स्टार्टअप वैलिडेशन यह ज़रूरी करता है कि वह मौजूद हो, बाकी वैल्यू से अलग हो और पर्याप्त लंबाई की हो।
• पासवर्ड सुरक्षा। पासवर्ड को 12 के वर्क फ़ैक्टर पर bcrypt से हैश किया जाता है और उन्हें कभी भी पढ़ने योग्य रूप में स्टोर या लॉग नहीं किया जाता। न्यूनतम लंबाई लागू की जाती है। पासवर्ड अकाउंट से साइन इन करने से पहले ईमेल वेरिफ़िकेशन ज़रूरी है।
• सेशन मैनेजमेंट। सेशन साइन किए गए JSON Web Token होते हैं जिनमें एक रिवोकेशन काउंटर होता है, जिसे हर प्रमाणित अनुरोध पर डेटाबेस से जाँचा जाता है। इस काउंटर को बढ़ाने से जारी किए गए सभी सेशन एक साथ अमान्य हो जाते हैं, और इसी वजह से पासवर्ड रीसेट, “सभी डिवाइस से साइन आउट करें” और अकाउंट निलंबन सिर्फ़ नए सेशन को रोकने के बजाय चालू सेशन को वाकई बाहर कर देते हैं।
• पासवर्ड रीसेट और वेरिफ़िकेशन। रीसेट लिंक केवल एक बार उपयोग किए जा सकते हैं, 1 घंटे बाद समाप्त हो जाते हैं, भेजने के बीच कूलडाउन से उनकी दर सीमित रहती है, और उपयोग होते ही सभी सेशन रद्द कर देते हैं। वेरिफ़िकेशन लिंक 24 घंटे बाद समाप्त हो जाते हैं। रीसेट अनुरोध कभी यह नहीं बताता कि कोई खाता मौजूद है या नहीं।
• रेट लिमिटिंग। साइन-इन, साइन-अप, पासवर्ड रीसेट और AI कार्रवाइयों पर रेट लिमिट लागू है, जिसके लिए डेटाबेस में रखे गए टिकाऊ फ़िक्स्ड-विंडो काउंटर इस्तेमाल होते हैं, ताकि प्रोसेस रीस्टार्ट होने पर भी लिमिट बनी रहें और सिर्फ़ एक इंस्टेंस में नहीं, बल्कि सभी इंस्टेंस पर लागू हों।
• टेनेंट आइसोलेशन। हर क्वेरी केवल प्रमाणित (authenticated) अकाउंट तक सीमित होती है। ओनरशिप जाँच में विफलता को भी अपने आप में एक सुरक्षा घटना के रूप में दर्ज किया जाता है।
• टीम रोल और सीटें। एक बिज़नेस अकाउंट में कई लोग हो सकते हैं। हर सदस्य को अकाउंट होल्डर आमंत्रित करता है, सदस्य किसी साझा लॉगिन के बजाय अपने स्वयं के क्रेडेंशियल से आमंत्रण स्वीकार करता है, और उसे एक भूमिका दी जाती है जिसकी अनुमतियाँ केवल इंटरफ़ेस में दिखाई ही नहीं जातीं, बल्कि सर्वर पर जाँची जाती हैं। सदस्यों को निष्क्रिय किया जा सकता है, जिससे उनकी पहुँच बंद हो जाती है लेकिन उनके द्वारा दर्ज किए गए रिकॉर्ड पर उनका नाम बना रहता है। कर्मचारियों द्वारा जमा की गई प्रविष्टियाँ, जैसे खर्च और माइलेज, उसी अकाउंट के नाम दर्ज होती हैं जिससे वे भेजी गई थीं।
• प्रशासनिक एक्सेस नियंत्रण। आंतरिक ऑपरेशंस कंसोल केवल उन ऑपरेटरों तक सीमित है जो एनवायरनमेंट में कॉन्फ़िगर की गई एक स्पष्ट अनुमति-सूची (allowlist) में शामिल हैं। हर ऑपरेटर कार्रवाई एक केवल-जोड़ने-योग्य (append-only) प्रशासनिक ऑडिट लॉग में लिखी जाती है, जो दर्ज करता है कि किसने किस अकाउंट के साथ क्या किया।
• ऑडिट ट्रेल। हर प्रस्ताव, मंज़ूरी, बदलाव, अस्वीकृति, अमल और विफलता हर अकाउंट के अलग append-only ऑडिट लॉग में दर्ज की जाती है, साथ ही पासवर्ड बदलना, सेशन रद्द करना, निलंबन और एस्टिमेट लिंक रोटेशन जैसी सुरक्षा घटनाएँ भी। सीक्रेट्स, टोकन और पासवर्ड हैश को डिज़ाइन के स्तर पर ही इससे बाहर रखा गया है।
• HTTP सिक्योरिटी हेडर। एक Content Security Policy, जो scripts, styles, frames और form targets को सीमित करती है; clickjacking से बचाव के लिए X-Frame-Options DENY और frame-ancestors none; X-Content-Type-Options nosniff; strict-origin-when-cross-origin referrer policy; और camera=(), microphone=(self), geolocation=(self) पर सेट Permissions-Policy। माइक्रोफ़ोन और लोकेशन की अनुमति केवल VERA के अपने पेजों को है, किसी embedded third party को कभी नहीं। ये तभी लागू होती हैं जब आप उस फ़ीचर के लिए ब्राउज़र को अनुमति देते हैं जो इसे माँगता है।
• वेबहुक इंटीग्रिटी। इनबाउंड वेबहुक को प्रोसेस करने से पहले हर प्रोवाइडर की साइनिंग स्कीम के अनुसार सत्यापित किया जाता है, जिसमें Stripe सिग्नेचर, Meta का HMAC हेडर, Jobber का HMAC, Square की सिग्नेचर की और QuickBooks का समर्पित वेरिफ़ायर टोकन शामिल हैं। डिलीवरी के डुप्लिकेट इवेंट id के आधार पर हटाए जाते हैं, ताकि दोबारा भेजी गई डिलीवरी कोई असर दो बार लागू न कर सके।
• सर्वर-साइड रिक्वेस्ट फ़ोर्जरी से सुरक्षा। जहाँ प्रोडक्ट आपके दिए गए किसी URL को फ़ेच करता है, जैसे कोई स्टोर डोमेन या विश्लेषण के लिए कोई वेबसाइट, वहाँ पते को स्कीम और पोर्ट के आधार पर, तथा वह जिन-जिन IP की ओर इंगित करता है उन सभी को रिज़ॉल्व करके सत्यापित किया जाता है, और लूपबैक, प्राइवेट, लिंक-लोकल, carrier-grade NAT और क्लाउड मेटाडेटा रेंज को अस्वीकार कर दिया जाता है। रीडायरेक्ट इस तरह संभाले जाते हैं कि कोई पब्लिक होस्ट किसी अनुरोध को किसी इंटरनल होस्ट की ओर न मोड़ सके।
• सार्वजनिक लिंक की सुरक्षा। ग्राहकों को भेजे जाने वाले एस्टिमेट लिंक में 256 बिट की क्रिप्टोग्राफ़िक रूप से सुरक्षित रैंडमनेस का इस्तेमाल होता है। मालिक किसी लिंक को दोबारा जनरेट कर सकते हैं, जिससे पुराना लिंक तुरंत अमान्य हो जाता है और ऑडिट के लिए उसका एक ऐसा फ़िंगरप्रिंट दर्ज हो जाता है जिसे वापस मूल रूप में नहीं बदला जा सकता। टोकन खोजने की असफल कोशिशों को सीमित (थ्रॉटल) किया जाता है ताकि एंडपॉइंट पर बार-बार कोशिश करके टोकन न खोजे जा सकें, और जहाँ भी टोकन लॉग या एडमिन व्यू में दिख सकते हैं, वहाँ उन्हें छिपा (मास्क) दिया जाता है।
• न्यूनतम आवश्यक अनुमतियों वाले इंटीग्रेशन स्कोप। इंटीग्रेशन केवल वही स्कोप माँगते हैं जिनकी उनके फ़ीचर्स को ज़रूरत होती है, और कई इंटीग्रेशन डिज़ाइन से ही read-only हैं, जिनमें QuickBooks Online और Jobber शामिल हैं। बिलिंग एनालिटिक्स एक अलग, प्रतिबंधित, read-only पेमेंट प्रोवाइडर key का उपयोग करते हैं, ताकि कोई भी एनालिटिक्स व्यू कभी भी बिलिंग स्थिति में बदलाव न कर सके।
• पेमेंट डेटा का अलगाव। कार्ड नंबर कभी VERA तक नहीं पहुँचते। पेमेंट Stripe के होस्टेड चेकआउट पर लिया जाता है और Stripe के बिलिंग पोर्टल से मैनेज होता है, इसलिए VERA के सिस्टम कार्डधारक डेटा के रास्ते में नहीं आते।
• डिफ़ॉल्ट रूप से सुरक्षित कॉन्फ़िगरेशन। स्टार्टअप वैलिडेशन प्रोडक्शन में चलने से इनकार कर देता है अगर डेवलपमेंट सेशन सीक्रेट इस्तेमाल हो रहा हो, सेशन सीक्रेट न हो, या सीक्रेट्स के लिए अलग एन्क्रिप्शन की न हो, और आधे-अधूरे कॉन्फ़िगर किए गए उन इंटीग्रेशन पर चेतावनी देता है जो बिना बताए फ़ेल हो जाते।
• रोज़ाना एन्क्रिप्टेड बैकअप। प्रोडक्शन डेटाबेस का दिन में एक बार डंप लिया जाता है, उसे बनाने वाली मशीन से बाहर जाने से पहले AES256 से एन्क्रिप्ट किया जाता है, और डेटाबेस प्रोवाइडर से अलग स्टोर किया जाता है। इसके बाद हर रन अभी-अभी बनी एन्क्रिप्टेड कॉपी को एक अस्थायी डेटाबेस में रीस्टोर करता है, और अगर रीस्टोर विफल हो जाए या खाली निकले तो रन फ़ेल हो जाता है, इसलिए किसी बैकअप को तभी गिना जाता है जब वह रीस्टोर हो चुका हो। बैकअप 30 दिनों तक रखे जाते हैं, और उनके बीच के घंटों को डेटाबेस प्रोवाइडर की अपनी पॉइंट-इन-टाइम रिकवरी कवर करती है।
• खाता निलंबन। किसी हैक हुए या दुरुपयोग करने वाले अकाउंट को निलंबित किया जा सकता है। इससे हर प्रमाणित एंट्री पॉइंट बंद हो जाता है और चालू सेशन रद्द हो जाते हैं। इसमें कोई डेटा नहीं हटता और यह कदम वापस भी लिया जा सकता है।

3. क्या अभी मौजूद नहीं है

ये ऐसे नियंत्रण हैं जिनके बारे में कोई सुरक्षा समीक्षक उचित रूप से पूछ सकता है। VERA के पास आज ये नहीं हैं। हम इन्हें सूचीबद्ध कर रहे हैं ताकि पाठक ऊपर वाले सेक्शन से इनके मौजूद होने का अनुमान न लगाए।

• कोई सर्टिफ़िकेशन नहीं। VERA ने SOC 2 Type I या Type II ऑडिट पूरा नहीं किया है, वह ISO 27001 सर्टिफ़ाइड नहीं है, उसका कोई HIPAA बिज़नेस एसोसिएट प्रोग्राम नहीं है, और स्वयं उसका PCI DSS मूल्यांकन नहीं हुआ है। पेमेंट कार्ड से जुड़ा सारा काम पूरी तरह Stripe को सौंपा गया है।
• मल्टी-फ़ैक्टर ऑथेंटिकेशन नहीं। VERA फ़िलहाल two-factor authentication, authenticator ऐप, हार्डवेयर कीज़ या पासकी की सुविधा नहीं देता। Google से साइन इन करने पर आपके Google खाते पर जो भी मल्टी-फ़ैक्टर सुरक्षा है, वह अपने आप लागू होती है, और फ़िलहाल यही उपलब्ध सबसे मज़बूत विकल्प है।
• सिंगल साइन-ऑन नहीं। कोई SAML या OIDC एंटरप्राइज़ SSO नहीं है, और न ही SCIM प्रोविज़निंग।
• डायरेक्टरी-आधारित यूज़र मैनेजमेंट नहीं। टीम सदस्यों को VERA के अंदर ही आमंत्रित और मैनेज किया जाता है। किसी identity provider से अपने-आप प्रोविज़निंग या डीप्रोविज़निंग नहीं होती, इसलिए अपनी डायरेक्टरी से किसी को हटाने पर उसका VERA एक्सेस नहीं हटता; आपको उसे VERA में भी निष्क्रिय करना होगा।
• कोई स्वतंत्र पेनिट्रेशन टेस्ट या बग बाउंटी नहीं। VERA ने किसी तीसरे पक्ष से पेनिट्रेशन टेस्ट नहीं करवाया है और कोई पेड बग बाउंटी प्रोग्राम नहीं चलाती।
• ग्राहक-प्रबंधित एन्क्रिप्शन कुंजियाँ नहीं। एन्क्रिप्शन कुंजियाँ VERA द्वारा मैनेज की जाती हैं। अपनी खुद की कुंजी (Bring-your-own-key) की सुविधा उपलब्ध नहीं है।
• डेटा रेज़िडेंसी चुनने का विकल्प नहीं। डेटा की प्रोसेसिंग संयुक्त राज्य अमेरिका में होती है। EU या किसी क्षेत्रीय होस्टिंग का विकल्प उपलब्ध नहीं है।
• लंबी अवधि का बैकअप आर्काइव नहीं। रोज़ाना के बैकअप 30 दिनों तक रखे जाते हैं। कोई मासिक या वार्षिक आर्काइव नहीं है, कोई ऑफ़साइट तीसरी कॉपी नहीं है, और बैकअप से किसी एक अकाउंट को रिस्टोर करने की सुविधा नहीं है: रिस्टोर करने पर पूरा डेटाबेस वापस आता है, इसलिए यह एक इंसिडेंट रिस्पॉन्स है, ग्राहकों के लिए रिकवरी सेवा नहीं।
• 24/7 सिक्योरिटी ऑपरेशन नहीं। चौबीसों घंटे स्टाफ़ से संचालित कोई सुरक्षा ऑपरेशन सेंटर नहीं है, ग्राहकों के लिए प्रकाशित कोई औपचारिक ऑन-कॉल रोटेशन नहीं है, और ऊपर बताए गए एप्लिकेशन-स्तर के नियंत्रणों के अलावा कोई इंट्रूज़न डिटेक्शन प्रोडक्ट नहीं है।
• अपटाइम की कोई प्रतिबद्धता नहीं। VERA कोई सर्विस लेवल एग्रीमेंट नहीं देता। सेवा की शर्तें देखें।

4. इंफ्रास्ट्रक्चर

VERA, Node.js पर एक कंटेनराइज़्ड Next.js एप्लिकेशन के रूप में, एक मैनेज्ड PostgreSQL डेटाबेस के साथ चलता है। इसे मल्टी-स्टेज बिल्ड से डिप्लॉय किया जाता है, जो एक सेल्फ़-कंटेन्ड रनटाइम इमेज बनाता है। प्लेटफ़ॉर्म मॉनिटरिंग के लिए एक हेल्थ एंडपॉइंट उपलब्ध है।

अपलोड की गई तस्वीरें, जनरेट की गई इमेज और इम्पोर्ट किए गए दस्तावेज़ किसी अलग ऑब्जेक्ट स्टोरेज सेवा में नहीं, बल्कि एप्लिकेशन डेटाबेस में एन्कोडेड डेटा के रूप में स्टोर किए जाते हैं। इसका मतलब है कि ऐसा कोई अलग से कॉन्फ़िगर किया गया बकेट नहीं है जो सार्वजनिक रूप से पढ़ने योग्य छूट जाए, और इसका यह भी मतलब है कि फ़ाइल स्टोरेज पर वही एन्क्रिप्शन एट रेस्ट लागू होता है जो डेटाबेस प्रदाता लागू करता है।

होस्टिंग, नेटवर्क-स्तर की सुरक्षा और भौतिक सुरक्षा सबप्रोसेसर सूची में नामित प्लेटफ़ॉर्म प्रदाताओं द्वारा उनके अपने सुरक्षा कार्यक्रमों के तहत प्रदान की जाती है। VERA अपने खुद के डेटा सेंटर संचालित नहीं करता।

5. निगरानी और घटना प्रतिक्रिया

प्रोडक्शन में एप्लिकेशन और एरर लॉगिंग चलती है, और आंतरिक ऑपरेशंस कंसोल सिस्टम की स्थिति, बैकग्राउंड जॉब की स्थिति, इंटीग्रेशन की विफलताएँ और एक सुरक्षा पैनल दिखाता है, जो ऐसी चीज़ों की रिपोर्ट करता है जैसे पुराने टोकन फ़ॉर्मेट पर अभी भी चल रहे एस्टिमेट लिंक का बैकलॉग।

यदि हमें ग्राहक डेटा को प्रभावित करने वाली किसी सुरक्षा घटना का पता चलता है, तो हम उसकी जाँच करते हैं, उसे नियंत्रित करते हैं, और आकलन करते हैं कि कौन-सा डेटा शामिल था। किसी बिज़नेस ग्राहक की ओर से प्रोसेस किए गए व्यक्तिगत डेटा के लिए, VERA डेटा प्रोसेसिंग एडेंडम की अपेक्षा के अनुसार प्रभावित ग्राहक को बिना अनुचित देरी के और जानकारी मिलने के 72 घंटों के भीतर सूचित करता है। नियामकों और व्यक्तियों को सूचना देना कंट्रोलर की ज़िम्मेदारी है, और हम इसमें सहायता करते हैं।

VERA फ़िलहाल कोई स्टेटस पेज या सार्वजनिक इंसिडेंट हिस्ट्री प्रकाशित नहीं करता।

6. कमज़ोरी की रिपोर्ट करना

सुरक्षा समस्याओं की रिपोर्ट support@meetmyvera.com पर “Security report” विषय पंक्ति के साथ करें। समस्या को दोहराने के लिए पर्याप्त विवरण दें: प्रभावित URL या फ़ीचर, चरण, और आपके अनुसार उसका प्रभाव। एन्क्रिप्टेड पत्राचार का स्वागत है; पूछें और हम इसकी व्यवस्था करेंगे।

हमारा लक्ष्य किसी रिपोर्ट के मिलने की पुष्टि 3 कार्य दिवसों के भीतर करना और 10 कार्य दिवसों के भीतर आकलन देना है। फ़िक्स पर काम करते समय हम आपको अपडेट देते रहेंगे और फ़िक्स जारी होने पर आपको बताएँगे। अगर आप चाहें, तो हमें आपको सार्वजनिक रूप से श्रेय देने में खुशी होगी।

7. ज़िम्मेदार डिस्क्लोज़र और सेफ़ हार्बर

यदि आप नीचे दी गई सीमाओं के भीतर रहकर, नेक नीयत से VERA की सुरक्षा पर रिसर्च करते हैं, तो हम आपके विरुद्ध कोई कानूनी कार्रवाई नहीं करेंगे और लागू कंप्यूटर दुरुपयोग कानून के तहत आपकी रिसर्च को अधिकृत मानेंगे। हमारा आपसे अनुरोध है कि:

• केवल अपने ही खाते पर टेस्ट करें। वही खाता इस्तेमाल करें जो आपने बनाया है। किसी दूसरे ग्राहक के डेटा को एक्सेस, संशोधित या अपने पास न रखें। अगर अनजाने में आपके सामने किसी और का डेटा आ जाए, तो वहीं रुक जाएँ, उसे सेव न करें, और हमें बताएँ कि क्या हुआ।
• नुकसान से बचें। कोई डिनायल ऑफ़ सर्विस नहीं, कोई लोड या स्ट्रेस टेस्टिंग नहीं, कोई स्पैम नहीं, हमारे स्टाफ़ या ग्राहकों पर कोई सोशल इंजीनियरिंग नहीं, और कोई भौतिक हमला नहीं।
• बड़ी मात्रा में ऑटोमेटेड स्कैनर का उपयोग न करें। आक्रामक ऑटोमेटेड स्कैनिंग और हमले में कोई फ़र्क नहीं किया जा सकता, और ऐसा करने पर आप पर रेट लिमिट लगा दी जाएगी या आपको ब्लॉक कर दिया जाएगा।
• हमें समय दें। निजी तौर पर रिपोर्ट करें और सार्वजनिक करने से पहले हमें समस्या ठीक करने के लिए उचित समय दें। हमारी सामान्य अपेक्षा 90 दिन है; हम आमतौर पर इससे कहीं जल्दी ठीक कर देते हैं, और अगर किसी चीज़ में ज़्यादा समय लगे तो आपको बताएँगे।
• जबरन वसूली न करें। भुगतान मिलने तक जानकारी रोककर रखना सुरक्षा रिपोर्ट नहीं है। VERA कोई पेड बाउंटी प्रोग्राम नहीं चलाता और कोई इनाम नहीं दे सकता।

8. आपकी भूमिका

एक मज़बूत, यूनिक पासवर्ड इस्तेमाल करें, और अगर आपके Google खाते में मल्टी-फ़ैक्टर ऑथेंटिकेशन चालू है तो Google साइन-इन को प्राथमिकता दें, क्योंकि VERA अभी अपना खुद का मल्टी-फ़ैक्टर ऑथेंटिकेशन नहीं देता।

अपने क्रेडेंशियल शेयर न करें। जिस भी व्यक्ति को VERA की ज़रूरत है, उसे लॉगिन देने के बजाय इनवाइट करके और रोल असाइन करके उसका अपना अधिकृत अकाउंट दें: अकाउंट होल्डर का लॉगिन शेयर करने पर उसमें पूरा एक्सेस होता है, जिसमें बिलिंग और हर कनेक्टेड प्लेटफ़ॉर्म शामिल है, और इससे एक्टिविटी ट्रेल यह नहीं बता पाती कि असल में किसने क्या किया। जैसे ही किसी सदस्य को एक्सेस की ज़रूरत न रहे, उसे डीएक्टिवेट कर दें।

इंटीग्रेशन की अनुमति तभी दें जब आपको उस फ़ीचर की ज़रूरत हो, और जिनका इस्तेमाल बंद कर दें उन्हें डिस्कनेक्ट करें। अगर कोई एस्टिमेट लिंक ऐसी जगह फ़ॉरवर्ड हो गया है जहाँ आप नहीं चाहते थे, तो उसे दोबारा जनरेट करें। कुछ गड़बड़ लगे तो अपना ऑडिट ट्रेल देखें, और अगर आपको अनधिकृत पहुँच का शक हो तो हमें support@meetmyvera.com पर बताएँ।