क्या मुझे असुरक्षित कोड लिखना चाहिए, यदि मेरा नियोक्ता मुझसे ऐसा करने का अनुरोध करता है? [बन्द है]


24

मेरे नियोक्ता ने मुझे एक ऐसी सुविधा लागू करने के लिए कहा, जिसमें डेटाबेस में स्पष्ट पाठ में पासवर्ड संग्रहीत करने की आवश्यकता हो (या बाइनरी में संग्रहीत एक अस्पष्ट एन्क्रिप्ट / डिक्रिप्ट फ़ंक्शन का उपयोग करना, जो थोड़ा बेहतर है, लेकिन असुरक्षित भी है)।

मैंने जवाब दिया कि मैं इस तरह की सुविधा को लागू करने के लिए तैयार था, बशर्ते कि ग्राहक इसका इस्तेमाल करते समय सुरक्षा निहितार्थ स्वीकार करते थे।

सहकर्मियों के साथ इस समस्या पर चर्चा करते समय, किसी ने मुझसे कहा कि, एक सॉफ्टवेयर इंजीनियर के रूप में, हम सुरक्षा समस्याओं के लिए व्यक्तिगत रूप से जिम्मेदार (कानूनी मायने में) हैं जो हम अपने उत्पादों में पेश करते हैं। मैंने अपने अनुबंध में देखा, लेकिन एक समान मामले से संबंधित कुछ भी नहीं मिला।

कानूनी दृष्टिकोण से, क्या मुझे ऐसी सुविधा को लागू करने से इनकार करना चाहिए? क्या यह सच है कि मेरे नियोक्ता मुझे अदालत में ले जा सकते हैं यदि कोई ग्राहक इस सुविधा के कारण क्षति का अनुभव करता है, भले ही वह सुरक्षा चिंताओं के बारे में भी जानता हो?


संपादित करें: मैं समझता हूं कि इस प्रश्न का उत्तर केवल एक वकील से मज़बूती से दिया जा सकता है। लाइसेंसिंग प्रश्नों के लिए भी यही सच है: यहां के लोग अपनी समझ और अपने अनुभव देते हैं, कभी-कभी वकील से सलाह लेने के बाद, बिना किसी गारंटी के यह किसी अन्य अधिकार क्षेत्र में लागू होता है। लेकिन लाइसेंसिंग को यहां एक विषय के रूप में स्पष्ट रूप से स्वीकार किया जाता है, देखें कि मैं यहां किस तरह के प्रश्न पूछ सकता हूं? । मेरा मानना ​​है कि अन्य प्रोग्रामर के पास एक ही मुद्दा हो सकता है, और अन्य पहले भी इस स्थिति से सामना कर सकते हैं, और हो सकता है कि इसके लिए एक वकील से परामर्श करें।


2
आपको एक वकील से संपर्क करना चाहिए - यह उत्तर पाने के लिए सही जगह नहीं है।
ओड

11
IANAL, लेकिन ऐसा लगता नहीं है कि एक नियोक्ता सफलतापूर्वक एक कर्मचारी पर ठीक उसी तरह मुकदमा करने में सक्षम होगा जो उन्होंने उसे करने के लिए कहा था।

3
@Oded: क्लाइंट कंपनी पर मुकदमा कर सकता है, हाँ, और कंपनी अभी भी गलत तरीके से दोष लगा सकती है और कर्मचारी (एक "वसीयत" के अधिकार क्षेत्र में) में आग लगा सकती है, लेकिन मैंने ग्राहकों को व्यक्तिगत प्रोग्रामर पर मुकदमा करने में सक्षम होने के बारे में कभी नहीं सुना है। कंपनी जो बिक्री, नहीं कर्मचारी के अनुबंध किया कानूनी इकाई है, इसलिए यह कंपनी है जो उत्पाद में गुणवत्ता संबंधी समस्याओं के लिए जिम्मेदार है है।

8
सादे पाठ में पासवर्ड संग्रहीत करने से अधिक आपके ग्राहकों का आपके समाधानों पर क्या भरोसा कम हो सकता है ?! मूर्खता। यदि आपका बॉस आपसे अपनी कब्र खोदने के लिए कहने जा रहा है, तो बस इसे करें, लेकिन यह सुनिश्चित करें कि आप इसे ईमेल में लिखित रूप में प्राप्त करें कि आपने उसे अपनी असहमति की सूचना दी है और उसे संभावित परिणामों के बारे में चेतावनी दी है, और उसे भी आपको आदेश दे रहा है। इसे कैसे भी करें। उस पत्राचार को हमेशा अपने साथ रखें।
maple_shaft

3
मैं इस प्रश्न को ऑफ-टॉपिक के रूप में बंद करने के लिए मतदान कर रहा हूं क्योंकि एक कानूनी प्रश्न जो केवल एक वकील द्वारा ठीक से उत्तर दिया जा सकता है।

जवाबों:


11

आपका सहयोगी गुमराह है, खासकर जब से आप अपने अनुबंध में सुरक्षा जिम्मेदारी पर कुछ भी नहीं पा सके। यहां तक ​​कि अगर यह किया है, तो आप सिर्फ प्रबंधन से एक परस्पर विरोधी आदेश मिला है।

मुझे लगता है कि एकमात्र समय जब आप अपने आप को संभावित मुकदमेबाजी के अधीन करते हैं यदि आप जानबूझकर उत्पाद को नुकसान पहुंचाते हैं, तो अपना खुद का समय बम, अंडाणु, आदि बनाएं।

ज्यादातर मामलों में, कंपनी सॉफ्टवेयर का मालिक है, इसलिए वे मुनाफे का आनंद लेते हैं, लेकिन इसका मतलब यह भी है कि वे जोखिम उठाते हैं, व्यक्तिगत डेवलपर भी नहीं।

व्यक्तिगत रूप से, मुझे यकीन है कि प्रबंधन इस सुरक्षा सुविधा के साथ मुद्दों के बारे में पता था, ताकि यह पहले से ही प्रलेखित किया गया था, और बस अपना काम करना जारी रखें।

कहा जा रहा है, एक वकील से परामर्श करें, यादा-यदा-यदा।


34

जो कुछ भी होता है: कभी भी ईमेल या अन्य सबूत के बिना इस तरह के कोड को स्पष्ट रूप से न लिखें कि आपने अपने नियोक्ता के निर्देशों का पालन किया है।


6
और इसे प्रिंट करें / बाहर के खाते में भी भेजें।
बिल लीपर

7
CYA के रूप में जाना जाता है (कवर योर ए ..)। मैंने एक बार अपने व्यक्तिगत ईमेल खाते में आपत्तिजनक निर्देश की एक प्रति ईमेल की थी, और इसे कंपनियों को कानूनी प्रभाग में भेज दिया (हमारे पास एक नैतिक टीम थी इसलिए यह गोपनीय था)। यह इस बात पर निर्भर करता है कि आप कितनी गर्मी लेने के लिए तैयार हैं, और आपको कितनी "सुरक्षा" चाहिए। दूसरों के बारे में सोचने लायक हैं मार्केटिंग, बोर्ड (अंतिम जिम्मेदारी), मालिक / शेयरधारक। पूछें "सबसे ढीली कौन है"? यह कैरियर को सीमित करने वाला होगा, क्योंकि आपने या तो महत्वपूर्ण लोगों का बहुत समय बर्बाद किया है, या आपको बॉस को बुरा लग रहा है।
मटनज़

+1 - अपनी पीठ को कवर करें। अपनी आपत्तियों और तर्क को इस कारण से दस्तावेज दें कि आप इसे बुरा क्यों मानते हैं। अपने प्रबंधकों की प्रतिक्रिया दस्तावेज़। इसे प्रिंट करें और ध्यान से फाइल करें यदि गर्मी आपके पास वापस आती है।
क्वर्की

CYA लेकिन इसके बारे में निष्क्रिय आक्रामक मत बनो। सुनिश्चित करें कि आप अपनी आपत्तियों को आवाज देते हैं अपने नियोक्ता को वापस जाएं और उस ईमेल को भी सहेजें।
डग टी।

सादा और सरल - मुझे यह उत्तर पसंद है। यह निश्चित रूप से कानूनी रूप से जिम्मेदारी के साथ मदद करेगा, हालांकि, आपको अभी भी नैतिक निर्णय खुद करना होगा।
stringo0

6

कानूनी दृष्टिकोण से, एक वकील से परामर्श करें। मैं एक नहीं हूं, और न ही हमारे पास कोई सुराग है कि आप किस अधिकार क्षेत्र या कानून के तहत रहते हैं, जो कुछ चीजों को समझाने में मदद कर सकता है। लेकिन किसी भी मामले में एक वकील से परामर्श करें, क्या आप अपने व्यक्तिगत, पेशेवर और वित्तीय भविष्य के साथ एक इंटरनेट क्यू एंड ए साइट पर भरोसा करेंगे।

सामान्य व्यवसाय सलाह यह सुनिश्चित करती है कि आप अपने आरक्षण को लिखित रूप में प्राप्त करें और अपने नियोक्ता के सीधे आदेश को लिखित रूप में सुरक्षा चिंताओं को जारी रखें। यदि चीजें दक्षिण में जाती हैं और पंखे से टकराती हैं, तो आपको वापस गिरना पड़ेगा।

इसके आस-पास एक और तरीका आवश्यकताओं में गहराई से देखने का होगा - आपने उस योजना को साझा किया है जिसे आप हल नहीं कर रहे हैं। एक बिल्ली की त्वचा के लिए एक से अधिक तरीके हैं, या पासवर्ड लुकअप आवश्यकताओं को संभालना है।


3

मैं इसके बारे में चिंता नहीं करूंगा - यह ऐसा नहीं है कि आप दुर्भावनापूर्ण रूप से खुद को असुरक्षित सुविधा में डालने का फैसला कर रहे हैं और बाद में खुद इसका फायदा उठा सकते हैं, या इसे सिर्फ इसलिए डाल सकते हैं क्योंकि आप लापरवाही कर रहे हैं। कंपनी यह चाहती है, किसी ने विकास के समय के बीच व्यापार बंद का फैसला किया है और उपयोगकर्ता की अपेक्षाएं स्वीकार्य हैं (हमेशा की तरह) और इसलिए आपको इसके साथ मिलना चाहिए। यदि आप वास्तव में किसी भी वापसी के बारे में चिंतित हैं, तो अपने बॉस को एक ईमेल भेजें और प्रतिक्रिया दें। एक बार जब आप एक कर्मचारी के रूप में ऐसा कर लेते हैं, तो आप कवर हो जाते हैं।

कभी-कभी ऐसे कारण होते हैं कि यह स्वीकार्य क्यों होता है - उदाहरण के लिए, मुझे कुछ बहुत ही महत्वपूर्ण आलोचनात्मक समाधानों के बारे में पता है जो सादे पाठ पासवर्डों को संग्रहीत करते हैं, लेकिन बाकी सिस्टम को सुरक्षित किया जाता है ताकि यह समस्या न बने। यह प्रणाली उदाहरण के लिए एक अलग नेटवर्क पर है। यदि आप बाकी की कहानी (अधिकांश कंपनियों में एक सामान्य स्थिति) नहीं जानते हैं, तो आप यथोचित उम्मीद कर सकते हैं कि किसी और ने इस पर विचार किया है। इसी तरह, यदि आपके पास आपके बॉस का वह ईमेल है, तो आप उम्मीद कर सकते हैं कि वह जानता है कि वह क्या कर रहा है।

संयोग से ... क्या यह एक उत्पाद है जो मैं (एक उपभोक्ता के रूप में) उपयोग कर सकता हूं? अगर हां .. तो क्या है, इसलिए मैं इससे बच सकता हूं? :)


1

क्या हम महसूस करते हैं कि डेवलपर्स द्वारा कई बग जोड़े जाते हैं जो लाइव ऑपरेशन के दौरान ग्राहकों को समान रूप से महान संपत्ति को नुकसान पहुंचाते हैं। हमें नहीं लगता कि वे जानबूझकर हैं लेकिन यह अभी भी हमारे कुछ ठोस कामों का परिणाम है और अभी भी निशान के लिए नहीं है। इसलिए आपके द्वारा किया गया उदाहरण एक अलग मामला नहीं है, जहां डेवलपर (या उच्चतर) निर्णय ग्राहक को प्रभावित करते हैं।

यहाँ मेरा सुझाव है:

  1. सबसे पहले, हर तरह से - यह वह कंपनी है जो दूसरी कंपनी को सॉफ्टवेयर वितरित कर रही है। किसी व्यक्ति को प्रत्यक्ष क्रेडिट नहीं दिया जाता (टीम के भीतर तालियाँ से परे और अधिकांश में पेचेक) और काम का स्वामित्व। तो जबकि यह हमारी डिलीवरी के एक हिस्से के रूप में अच्छी बात नहीं है, लेकिन आप यहाँ अपराधी नहीं हैं - जब तक कि निर्णय आपका नहीं है।

  2. एक पेशेवर प्रोग्रामर के रूप में - आप स्पष्ट रूप से कोड की सीमाओं और खतरों को दर्शाते हैं कि कैसे README फाइल या प्रलेखन के भाग के रूप में चीजों को बनाए रखना है। यदि कोई आवश्यकता दस्तावेज है - सुझाई गई परीक्षण रिपोर्ट आदि में स्पष्ट रूप से सीमाओं का उल्लेख होना चाहिए।

  3. सही निर्णय लेने वाले को ज़िम्मेदार ठहराने के लिए- मैं उच्चतर से अनुरोध करूंगा कि वह ऐसे किसी भी दस्तावेज़ के ईमेल में अपनी सोच की पुष्टि करें।

  4. जोखिम को सही ढंग से तौलें। मेरा डेटा कार्ड सॉफ़्टवेयर प्लान टेक्स्ट में पासवर्ड स्टोर करता है लेकिन यह महत्वपूर्ण नहीं है। लेकिन अगर बैंक पासवर्ड या डेटाबेस या सर्वर तक पहुंच हो, तो यह स्वीकार्य नहीं है। इसलिए वास्तविक जोखिम के आधार पर, आपको इस मुद्दे को अधिक से अधिक बढ़ाना चाहिए।


1

जब तक आप अपने काम को एक निष्ठुर तरीके से नहीं करते हैं, तब तक आपके द्वारा पूछे गए कार्यों को करने के लिए थोड़ा कानूनी उल्टा होता है। आपके पास रोजगार का एक अनुबंध होगा जो आपकी देनदारियों को बताएगा, आप तकनीकी पर एक वकील से परामर्श कर सकते हैं। यदि आप वास्तव में उजागर महसूस करते हैं तो प्लेनटेक्स्ट पासवर्ड पर डिज़ाइन निर्णय की लिखित स्वीकृति प्राप्त करें।

मैं प्रकट नहीं करूंगा कि यह कौन सा सॉफ्टवेयर है, जब तक कि मुझे यकीन नहीं है कि यह सुविधा इसे अंतिम रिलीज़ में बनाती है। मुझे अभी भी उम्मीद है कि हम ग्राहकों को इस तरह से सूचित करने का प्रबंधन करेंगे कि मुझे यह स्वीकार्य लगे।

थोड़ी अधिक चिंता का विषय है 'ग्राहकों को सूचित करना'। यदि आप अपनी कंपनियों को खड़े होने, प्रतिष्ठा आदि (एक क्लॉज़ जिसके बारे में आपके अनुबंध में होंगे) को नुकसान पहुंचाते हैं, तो आपकी कंपनी आप पर मुकदमा कर सकती है - और 'व्हिसिलब्लोअर' की रक्षा आपको संदर्भ या किसी अन्य नौकरी की आवश्यकता होने पर आपकी मदद नहीं कर सकती है।

यदि आप सुरक्षा छिद्रों के निहितार्थ से नाखुश हैं, तो अपना रिज्यूमे ब्रश करें और आगे बढ़ें, लेकिन यदि यह आपका निर्णय नहीं था और आपकी कंपनी नहीं है, तो मैं यह नहीं देख सकता कि यह (कानूनी रूप से) आप पर क्यों होगा? ।


1
आपके उत्तर के लिए धन्यवाद। मैंने अपनी टिप्पणी में बुरा व्यक्त किया। मैं इस विशेष निर्णय से खुश नहीं होगा, लेकिन यह मुझे कंपनी या किसी के खिलाफ गुस्सा नहीं करता है। एक प्रश्नोत्तर साइट में सार्वजनिक करना निश्चित रूप से एक बुरा विचार होगा। यह नकारात्मक विज्ञापन होगा और बहुत कम संभावना है कि यह किसी की मदद करेगा।
एंटोनी

यह अच्छा है कि आपके लिए वेंट करने के लिए इस तरह का एक मंच है - मुझे आशा है कि सब कुछ ठीक हो जाएगा।
एमल्विन

1

आपकी कंपनी को आपके द्वारा नियोजित किए जाने पर व्यावसायिक क्षतिपूर्ति बीमा का एक रूप लेना चाहिए । यह सॉफ़्टवेयर के साथ कुछ भी गलत होने, या सॉफ़्टवेयर के दुरुपयोग या सॉफ़्टवेयर में पाई जा रही खामियों (जैसे अनएन्क्रिप्टेड पासवर्ड) के मामले में अपने सभी कर्मचारियों के लिए पर्याप्त कानूनी सुरक्षा प्रदान करना चाहिए

एक कर्मचारी के रूप में आप उनसे वही करते हैं जो वे पूछते हैं, और उन्हें वह करना चाहिए जो ग्राहक चाहते हैं, जब तक कि न तो पार्टी कानून तोड़ रही हो, कोई समस्या नहीं है, लेकिन यदि आप वह करते हैं जो कंपनी चाहती है, और तब ऐसा पाया जाता है कि ग्राहक जो चाहता / चाहता था, वह उनके बीच नहीं है, और पेशेवर क्षतिपूर्ति बीमा आपको किसी भी व्यक्तिगत दोष / दायित्व से कवर करना चाहिए।

IANAL, लेकिन मैं अपने स्वयं के वकीलों के साथ जाँच करने के अलावा, कंपनियों की कानूनी टीम के साथ इसे ले जाऊंगा।

पुनश्च, यदि आप इसे गंभीरता से देखते हैं, तो इलेक्ट्रॉनिक और हार्ड कॉपी में सभी प्रासंगिक ईमेल को ऑफ-साइट पर सहेजें यदि संभव हो तो।


1

नई नौकरी के लिए समय है। इसे लागू करना भूल जाइए। यह स्थानांतरित करने का समय है। यदि वे इस बात से भड़के हुए हैं और धोखेबाज हैं, तो वे आपको बस के नीचे फेंकने से नहीं डरेंगे।

इसके अलावा, एक बार गुमनाम रूप से जाने से डरो मत, ऐसे कई समूहों में से एक से संपर्क करें जो लोगों के सॉफ्टवेयर में सुरक्षा छेद को इंगित करते हैं। यह एक आपदा होने की प्रतीक्षा है। इन्हें संग्रहीत करने के लिए कोई ध्वनि कारण नहीं है। क्या आपके बॉस ने आपको कोई कारण दिया? क्या वे उपयोगकर्ताओं के रूप में लॉगिन करना चाहते हैं? क्या वे पासवर्ड पुनः प्राप्त करना आसान बनाना चाहते हैं? जब तक आपको इनमें से किसी एक का जवाब नहीं मिलता है कि आप अधिक सुरक्षित तरीके से संबोधित कर सकते हैं, तो यह आगे बढ़ने का समय है। जब आप निकलते हैं, तो उन्हें क्यों नहीं बताना सबसे अच्छा होगा।


आपको पता चलता है कि Google भी पासवर्ड को सही में स्टोर करता है? यदि आप किसी साइट के व्यवस्थापक हैं तो आप खातों के पासवर्ड देख सकते हैं।
apscience

1
उम, मुझे ऐसा नहीं लगता। आप पासवर्ड स्टोर नहीं करते हैं। आप एक तरह से हैश करते हैं जिसे उलटा नहीं किया जा सकता है और स्टोर किया जा सकता है। यह करने का मानक तरीका है। यहां तक ​​कि हाल ही में हैक जहां खातों से छेड़छाड़ की गई थी, उस तरह से किया। मुख्य मुद्दा यह है कि अगर कोई हैश हो जाता है और जानता है कि वे कैसे उत्पन्न हुए थे तो उन्होंने इसे एक शब्दकोश के साथ मारा। लेकिन NO NO NO, आप कभी भी, कभी नहीं, कभी नहीं, कभी भी खुद को एन्क्रिप्टेड पासवर्ड स्टोर न करें। बस उस एक से परेशानी पूछ रहा हूं। अधिक जानना चाहते हैं। यहां जाएं: Owasp.org/index.php/Main_Page
बिल लीपर

मुझे पूरा यकीन है कि गूगल करता है। यदि आप ऐप्स हैं तो आप अपने सभी उपयोगकर्ता के पासवर्ड देख सकते हैं। Google.com/support/forum/p/Google%20Apps/… , उत्तर # 4 देखें ।
अप्सराएं

1
RTFA। क्षमा करें, यह कहता है कि आप एक उपयोगकर्ता के रूप में लॉगिन कर सकते हैं। यह एक ऐसी विधि है जहाँ कुछ निजीकरण वाला उपयोगकर्ता किसी अन्य उपयोगकर्ता को प्रतिरूपित कर सकता है। किसी भी बिंदु पर Google आपको दूसरे व्यक्ति का पासवर्ड नहीं देता है। आप अपने स्वयं के क्रेडेंशियल्स के साथ लॉग इन कर रहे हैं और फिर दूसरे उपयोगकर्ता को प्रतिरूपण कर रहे हैं। यह बहुत आम है और मेरी मूल टिप्पणी का एक समाधान है जहां बॉस किसी विशेष उपयोगकर्ता के रूप में लॉगिन करना चाहता है।
बिल लीपर

0

पासवर्ड को पुनर्प्राप्त करने के लिए स्टोर करने के लिए निर्देशों का पालन करने के लिए आप क्या कर सकते हैं, जबकि अभी भी पुनर्प्राप्त करना असंभव है यदि आपके पास प्रोग्राम तक पूरी पहुंच है, तो असममित एन्क्रिप्शन का उपयोग कर रहे हैं

आप बाइनरी में संग्रहीत सार्वजनिक कुंजी के साथ (हमेशा की तरह नमकीन) को एन्क्रिप्ट करते हैं

और जब पासवर्ड सादे-पाठ में आवश्यक होते हैं तो मानव को निजी कुंजी प्रदान करने की आवश्यकता होती है जो अन्यथा सर्वर से सुरक्षित रखी जाती है


मांग के कारण के आधार पर, यह ओपी के वरिष्ठों को संतुष्ट करने के लिए कहीं भी नहीं आ सकता है।
बजे एक सीवीएन

0

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

कानून आपको यह भी नहीं बताते हैं कि आपको क्या करना चाहिए, लेकिन आप क्या कर सकते हैं / नहीं कर सकते। आप इस बात का उल्लेख नहीं करते हैं कि आप किस उद्योग में हैं, लेकिन कुछ के पास कानून, नियम, और नियम हैं कि कैसे विशिष्ट प्रकार के डेटा को संभालना है - क्या एन्क्रिप्ट किया जाना है, एन्क्रिप्शन के न्यूनतम स्तर, एक्सेस को प्रबंधित / नियंत्रित करने की आवश्यकताएं, इत्यादि। यदि आपके क्षेत्र (देश, राज्य) में सुरक्षा के बारे में नियम नहीं हैं, तो आपके उद्योग में सुरक्षा के बारे में नियम नहीं हैं, और सॉफ़्टवेयर आवश्यकताएं सुरक्षा आवश्यकताओं या मानकों को नहीं बताती हैं, यह एक नैतिक मुद्दे से अधिक हो सकता है कानूनी मुद्दे।

जब सॉफ्टवेयर विकास में नैतिक मुद्दों की बात आती है, तो मैं सॉफ्टवेयर इंजीनियरिंग कोड ऑफ एथिक्स एंड प्रोफेशनल प्रैक्टिस की सदस्यता लेता हूं । अंततः, यह आपकी कॉल है। हालाँकि, मुझे लगता है कि प्लेटेक्स्ट में या एक प्रारूप में पासवर्ड को डिक्रिप्ट किया जा सकता है, अनैतिक है।


-3

बस अपनी परियोजना की विकास प्रक्रिया के अनुरूप: यदि यह सुविधा आवश्यकता दस्तावेज़ में लिखी गई है, तो आप इसे लागू करेंगे।


बस निम्नलिखित आदेश श्रीमान। मुझे ऐसा नहीं लगता। प्रोग्रामर को सोचने, सवाल पूछने, रचनात्मक होने के लिए काम पर रखा जाता है। यह इस तरह का भद्दा सॉफ्टवेयर है जो उद्योग को एक बुरा नाम देता है और हमारी व्यक्तिगत जानकारी को खतरे में डालता है।
बिल लीपर

मेरा उत्तर ठीक इसके विपरीत बताता है: यदि आपका बॉस आवश्यकताओं के विपरीत है, तो आप बॉस को सुरक्षित रूप से बायपास कर सकते हैं। मुझे संदेह है कि उजागर होने वाले मामले में, बॉस स्वीकार करेगा कि उसका आदेश आवश्यकताओं में लिखा गया है।
मौविसील
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.