क्यों एक कमजोर mysql उपयोगकर्ता पासवर्ड होना बुरा है?

23

मुझे इस तर्क के साथ प्रस्तुत किया गया था कि "आपको एक मजबूत mysql उपयोगकर्ता पासवर्ड की आवश्यकता नहीं है क्योंकि इसका उपयोग करने के लिए, उन्हें पहले से ही आपके सर्वर तक पहुंच प्राप्त होगी।" हम 4 अंकों के पासवर्ड के बारे में बात कर रहे हैं जो एक लाइव व्यापार वेबसाइट पर एक मानक अंग्रेजी शब्दकोष है।

अपने खुद के ज्ञान और अनुभव के साथ जवाबों को प्रभावित किए बिना, मैं उन्हें 3 जी स्रोत से उदासीन कुछ प्रतिक्रियाएं दिखाना चाहता हूं। किसी को भी इस पर झंकार करने के लिए परवाह है? प्रोग्रामिंग / व्यावहारिक जवाब की सराहना की जाएगी।

— नागरिक
स्रोत

7

इन root:rootलॉगिन में से एक की तरह लगता है ।

3

चार अंकों का पासवर्ड? पसंद है 1337?

— गमबो

39

जो कोई भी यह तर्क दे रहा था, वह कह रहा है कि "किसी के द्वार पर पैर रखने के बाद, आप उन्हें पूरा उपयोग दे सकते हैं"। उस तर्क से, एक फ़ायरवॉल आपके आंतरिक नेटवर्क पर सभी पासवर्डों की आवश्यकता को नकार देता है।

मजबूत पासवर्ड नेटवर्क घुसपैठ से हुए नुकसान को सीमित करने की दिशा में एक कदम है। अपने हाथों को हार में फेंकने का कोई कारण नहीं है क्योंकि आपके नेटवर्क का एक छोटा हिस्सा समझौता किया गया था।

— meagar
स्रोत

13

Dep डिफेंस इन डेप्थ ’दिन का आदर्श वाक्य है।

— स्कॉट पैक

3

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

— लोटस नोट्स

2

@Lotus PHP और MySQL सर्वर को एक ही मशीन मानता है।

— 18

2

@ लोटस नोट्स, आपको रूट उपयोगकर्ता को किसी भी एप्लिकेशन में उपयोग नहीं करना चाहिए। एक अच्छी तरह से डिज़ाइन किया गया एप्लिकेशन केवल उस एक्सेस की अनुमति देता है जो आवश्यक है। अधिकांश समय, इसमें डेटा तक पहुंच शामिल है, लेकिन हमेशा सभी डेटा नहीं होते हैं, और कुछ मामलों में, यह केवल-पढ़ने के लिए भी हो सकता है।

— ब्रैडलीस

1

@ लोटस नोट्स: कई साझा होस्ट suPHP को नियोजित करते हैं जो संवेदनशील PHP फ़ाइलों में से chmod-ing 660 को चिपकाता है।

— webbiedave

14

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

— पावर सांकेतिक शब्दों में बदलनेवाला
स्रोत

मैं किसी के लिए एक कुंजी / दरवाजा सादृश्य के साथ आने की प्रतीक्षा कर रहा था: |

— 16

लेकिन आपके घर में हर दरवाजे के लिए एक अलग कुंजी शायद ओवरबोर्ड है। आपने पंक्ति को कहां खींचा था?

— दान

4

@ दान: लेकिन एक सुरक्षित सुविधा में, आप हर दरवाजे के लिए एक अलग कुंजी की उम्मीद करेंगे, है ना? एकल-परिवार के घर में - आप सभी ताले को एक ही कुंजी का उपयोग करने की उम्मीद करेंगे। लेकिन एक साझा घर में (जैसे रूममेट्स के साथ), यह घरेलू दर्शन पर निर्भर करेगा: या तो अनलॉक किए गए दरवाजे (शायद सभी समान कुंजी का उपयोग करके दरवाजे), या प्रति रूममेट की अलग-अलग चाबियाँ।

— वॉल्क

5

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

— स्टीफन वाटकिंस

6

यह बहुत कुछ इस बात पर निर्भर करता है कि आपका MySQL सर्वर कैसे सेटअप है। यदि यह केवल घर (127.0.0.1) आईपी से अनुरोध स्वीकार करता है, तो यह इसे और अधिक सुरक्षित बनाता है।

ऐसे परिदृश्य को देखते हुए जहां आप दूरस्थ आईपी की अनुमति देते हैं यह बहुत बड़ा सौदा बन जाता है।

इसके अलावा, घुसपैठ के मामले में मजबूत सुरक्षा के लिए हमेशा अच्छा है - बेहतर है कि वे जितना संभव हो उतना कम चले।

— DivinusVox
स्रोत

6

क्या लेखांकन में पेटीएम कैश बॉक्स पर ताला है? यदि हां, तो क्यों? क्या भवन में भौतिक सुरक्षा नहीं है?

— JohnFx
स्रोत

5

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

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

— डेनिस बायोडिक
स्रोत

5

वास्तव में यह दूसरा तरीका हो सकता है: यदि उनके पास mysql तक पहुंच है, तो वे स्वयं सर्वर ओएस तक पहुंचने में सक्षम हो सकते हैं।

MySQL LOAD_FILE और SELECT ... इनओट्यूट क्वेरीज़ mysql उपयोगकर्ताओं को अंतर्निहित फ़ाइल सिस्टम पर फ़ाइलों को पढ़ने और लिखने में सक्षम बनाती हैं। किसी भी फ़ाइल जो mysql उपयोगकर्ता के पास भी पहुँच है (क्या आपका MySQL रूट के रूप में चल रहा है?)। यदि linux / UNIX के अंतर्गत केवल LOAD_FILE का चयन करें ('/ etc / passwd') और उन्हें देखें। यदि mysqld रूट के रूप में चल रहा है तो आप SELECT LOAD_FILE ('/ etc / shadow') आज़मा सकते हैं और अपने sysadmin को रोते हुए देख सकते हैं।
कई बार linux के अंतर्गत mysql उपयोगकर्ता "root" सर्वर के "mysql" उपयोगकर्ता (जो mysqld चलाता है) के समान पासवर्ड होता है। फिर यदि यह पासवर्ड तुच्छ है (या मेडुसा / हाइड्रा जैसे स्वचालित टूल द्वारा खोजा जा सकता है) तो आप बस एसएसएच / टेलनेट को सीधे डेटाबेस सर्वर और चारों ओर मूर्ख बना सकते हैं।

— Renik
स्रोत

4

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

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

— rustyx
स्रोत

4

ऐसा कुछ लगता है जिसे यहां अनदेखा किया गया है, क्या आप अपने उपयोगकर्ताओं को विश्वसनीय नेटवर्क पर भरोसा करते हैं?

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

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

मजबूत पासवर्ड ऐसा करने के लिए सरल हैं और पासवर्ड को सुरक्षित रखने के लिए बहुत सारे पासवर्ड प्रबंधन उपकरण हैं, इसलिए ऐसा करने के लिए वास्तव में कोई बहाना नहीं है।

— मार्क हेंडरसन
स्रोत

बात आप MySQL में दूरस्थ कनेक्शन अनुमति नहीं देनी चाहिए, या अगर आप की जरूरत है, तो निर्दिष्ट करते हैं, है localhost/ 127.0.0.1मेजबान के रूप में। इस तरह, कोई भी बाहर डेटाबेस (यहां तक कि एक ही नेटवर्क में भी) का उपयोग नहीं कर सकता है।

— चेजी चेज़

2

एह। यदि आपका सर्वर आईपी लॉक है, और आपका उपयोगकर्ता उन तालिकाओं के एक सेट पर चयन करने के लिए प्रतिबंधित है, जहां आप जानकारी के बारे में परवाह नहीं करते हैं, तो यह बहुत बड़ी बात नहीं है।

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

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

— SatanicPuppy
स्रोत

2

mySQLs खाते / पहुंच की जानकारी वास्तविक डेटाबेस से एक अलग फ़ाइल में संग्रहीत की जाती है। इस प्रकार आप बस एक अलग फाइल को उसके स्थान पर खींच और छोड़ सकते हैं। MySQL के साथ यदि उनके पास आपके फाइल सिस्टम के प्रासंगिक हिस्से तक पहुंच है, तो खेल खत्म हो गया है।

— जॉन रॉबर्टसन
स्रोत

2

क्योंकि आवश्यकताएं बदल जाती हैं ...

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

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

लेकिन @meagar ने जो कहा उसे भी पढ़ें।

— सीन रिफ़्शिनडर
स्रोत

1

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

इसके अलावा, यदि सर्वर एक लाइव उत्पादन सर्वर है, तो आप इंटरनेट से खुद को विज्ञापन कर रहे हैं। इसका मतलब है कि किसी बिंदु पर, कोई उस सर्वर पर एक क्रूर बल हमले की कोशिश करेगा , जिसमें mysql, पोर्ट और उपयोगकर्ता खाता दोनों शामिल हैं।

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

एक सस्ते सस्ते कंप्यूटर पर 4 कैरेक्टर का पासवर्ड मिनटों में हैक किया जा सकता है।

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

— weismanm
स्रोत

1

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

अब एक कमजोर पासवर्ड का उपयोग कर रहे हैं क्योंकि आप mysql केवल 127.0.0.1 पर चलते हैं और केवल रूट उपयोगकर्ता के पास इसका उपयोग यह दर्शाता है कि आप आगे की सोचते हैं। यदि एक दिन आपको अपने mysql को ओवर-नेटवर्क एक्सेस देने की आवश्यकता होगी तो क्या होगा। क्या आपको अपने द्वारा छोड़ी गई सभी सुरक्षा पूर्णता को कवर करना याद होगा?

एक अच्छा व्यवस्थापक सबसे खराब परिदृश्य को व्यामोह के बिंदु पर रखता है।

— क्रिस्टियन व्राबी
स्रोत

1

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

— ddcruver
स्रोत

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

— चेज़ी चेज़

1

Mysql में किसी और को प्रतिरूपण करना बहुत आसान है। बिना किसी पासवर्ड (सबसे कमजोर सुरक्षा) वाली यूजर आईडी को देखते हुए उपयोग करें mysql -u userid। यदि इसका पासवर्ड है तो यह थोड़ा अधिक कठिन है, लेकिन कमजोर पासवर्ड इसे आसान बनाता है। अगर रूट का कोई पासवर्ड नहीं है, तो मैं रूट को एक्सेस कर सकता हूं mysql -u root। मैं तो रूट कर सकते हैं कि डेटाबेस के अंदर कुछ भी कर सकते हैं।

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

फ़ाइलों में पासवर्ड कुछ हद तक अनुमतियों द्वारा सुरक्षित किए जा सकते हैं। रूट द्वारा पहुंच, या पासवर्ड फ़ाइल का मालिक तुच्छ है। यदि डिस्क पर पासवर्ड के संभावित एन्क्रिप्शन का उपयोग किया जाना चाहिए। इससे इसे एक्सेस करना थोड़ा मुश्किल हो जाता है, लेकिन फिर भी यह कमजोर है।

— BillThor
स्रोत

0

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

— जॉन
स्रोत

मेह! यदि कोई सर्वर तक पहुंच प्राप्त करता है तो वे PHP फ़ाइलों से उपयोगकर्ता / पासवर्ड पढ़ सकते हैं ... कृपया इस उत्तर को अपडेट करें या हटाएं।

— चेज़ चेज़