பாதுகாப்பான கடவுச்சொல் மீட்டமைப்பு அம்சம் எவ்வாறு செயல்பட வேண்டும் என்பதைப் பற்றி மீண்டும் சிந்திக்க எனக்கு சமீபத்தில் நேரம் கிடைத்தது, முதலில் நான் இந்த செயல்பாட்டை உருவாக்கும்போது , பின்னர் அவர் மற்றொரு நபருக்கு இதேபோன்ற ஒன்றைச் செய்ய உதவியது. இரண்டாவது வழக்கில், மீட்டமைப்பு செயல்பாட்டை எவ்வாறு பாதுகாப்பாக செயல்படுத்துவது என்பது பற்றிய அனைத்து விவரங்களுடனும் ஒரு நியமன ஆதாரத்திற்கான இணைப்பை அவருக்கு வழங்க விரும்பினேன். இருப்பினும், பிரச்சனை என்னவென்றால், அத்தகைய ஆதாரம் இல்லை, குறைந்தபட்சம் எனக்கு முக்கியமானதாக தோன்றும் அனைத்தையும் விவரிக்கவில்லை. அதனால் நானே எழுத முடிவு செய்தேன்.
நீங்கள் பார்க்கிறீர்கள், மறந்துபோன கடவுச்சொற்களின் உலகம் உண்மையில் மிகவும் மர்மமானது. பல வேறுபட்ட, முற்றிலும் ஏற்றுக்கொள்ளக்கூடிய கருத்துக்கள் மற்றும் பல ஆபத்தானவை உள்ளன. இறுதிப் பயனராக நீங்கள் ஒவ்வொருவரையும் பலமுறை சந்தித்திருக்க வாய்ப்புகள் உள்ளன; எனவே, யார் அதைச் சரியாகச் செய்கிறார்கள், யார் செய்யவில்லை, உங்கள் பயன்பாட்டில் அம்சத்தை சரியாகப் பெறுவதற்கு நீங்கள் கவனம் செலுத்த வேண்டியவை ஆகியவற்றைக் காட்ட இந்த எடுத்துக்காட்டுகளைப் பயன்படுத்த முயற்சிக்கிறேன்.
கடவுச்சொல் சேமிப்பு: ஹாஷிங், என்க்ரிப்ஷன் மற்றும் (காஸ்ப்!) எளிய உரை
மறந்து போன கடவுச்சொற்களை எப்படி சேமிப்பது என்று விவாதிப்பதற்கு முன் அவற்றை என்ன செய்வது என்று விவாதிக்க முடியாது. கடவுச்சொற்கள் மூன்று முக்கிய வகைகளில் ஒன்றில் தரவுத்தளத்தில் சேமிக்கப்படுகின்றன:
- எளிய உரை. கடவுச்சொல் நெடுவரிசை உள்ளது, இது எளிய உரை வடிவத்தில் சேமிக்கப்படுகிறது.
- குறியாக்கம் செய்யப்பட்டது. பொதுவாக சமச்சீர் குறியாக்கத்தைப் பயன்படுத்துதல் (குறியாக்கம் மற்றும் மறைகுறியாக்கம் ஆகிய இரண்டிற்கும் ஒரு விசை பயன்படுத்தப்படுகிறது), மேலும் மறைகுறியாக்கப்பட்ட கடவுச்சொற்களும் அதே நெடுவரிசையில் சேமிக்கப்படும்.
- ஹாஷ். ஒரு வழி செயல்முறை (கடவுச்சொல்லை ஹேஷ் செய்யலாம், ஆனால் நீக்க முடியாது); கடவுச்சொல், நான் நம்ப விரும்புகிறேன், ஒரு உப்பு தொடர்ந்து, மற்றும் ஒவ்வொரு அதன் சொந்த பத்தியில் உள்ளது.
எளிமையான கேள்விக்கு நேராக வருவோம்: கடவுச்சொற்களை ஒருபோதும் எளிய உரையில் சேமிக்க வேண்டாம்! ஒருபோதும் இல்லை. ஒரே ஒரு பாதிப்பு , ஒரு கவனக்குறைவான காப்புப்பிரதி, அல்லது டஜன் கணக்கான பிற எளிய தவறுகளில் ஒன்று - அவ்வளவுதான், கேம்ஓவர், உங்களின் அனைத்து கடவுச்சொற்களும் - அதாவது, மன்னிக்கவும், உங்கள் அனைத்து வாடிக்கையாளர்களின் கடவுச்சொற்கள் பொது களமாக மாறும். நிச்சயமாக, இது ஒரு பெரிய வாய்ப்பைக் குறிக்கும் பிற அமைப்புகளில் உள்ள அவர்களின் அனைத்து கணக்குகளிலிருந்தும். மேலும் அது உங்கள் குற்றமாக இருக்கும்.
குறியாக்கம் சிறந்தது, ஆனால் அதன் பலவீனங்கள் உள்ளன. குறியாக்கத்தில் உள்ள சிக்கல் மறைகுறியாக்கம் ஆகும்; இந்த பைத்தியக்காரத்தனமாகத் தோன்றும் மறைக்குறியீடுகளை எடுத்து அவற்றை மீண்டும் எளிய உரைக்கு மாற்றலாம், அது நிகழும்போது நாம் மனிதர்கள் படிக்கக்கூடிய கடவுச்சொல் நிலைக்குத் திரும்புவோம். இது எப்படி நடக்கிறது? கடவுச்சொல்லை மறைகுறியாக்கும் குறியீட்டில் ஒரு சிறிய குறைபாடு உள்ளது, அது பொதுவில் கிடைக்கும் - இது ஒரு வழி. மறைகுறியாக்கப்பட்ட தரவு சேமிக்கப்பட்டுள்ள கணினிக்கான அணுகலை ஹேக்கர்கள் பெறுகின்றனர் - இது இரண்டாவது முறையாகும். மற்றொரு வழி, மீண்டும், தரவுத்தள காப்புப்பிரதியைத் திருடுவது மற்றும் யாரோ ஒரு குறியாக்க விசையைப் பெறுவார்கள், இது பெரும்பாலும் மிகவும் பாதுகாப்பற்ற முறையில் சேமிக்கப்படுகிறது.
இது நம்மை ஹாஷிங்கிற்கு கொண்டு வருகிறது. ஹாஷிங்கின் பின்னணியில் உள்ள யோசனை என்னவென்றால், அது ஒரு வழி; பயனர் உள்ளிட்ட கடவுச்சொல்லை அதன் ஹாஷ் பதிப்போடு ஒப்பிடுவதற்கான ஒரே வழி, உள்ளீட்டை ஹாஷ் செய்து அவற்றை ஒப்பிடுவதுதான். ரெயின்போ டேபிள்கள் போன்ற கருவிகளின் தாக்குதல்களைத் தடுக்க, செயல்முறையை சீரற்ற முறையில் உப்பு செய்கிறோம் (என்னைப் படிக்கவும் கிரிப்டோகிராஃபிக் சேமிப்பு பற்றி). இறுதியில், சரியாகச் செயல்படுத்தப்பட்டால், ஹாஷ் செய்யப்பட்ட கடவுச்சொற்கள் மீண்டும் ஒரு எளிய உரையாக மாறாது என்று நாம் உறுதியாக நம்பலாம் (வேறு ஹாஷிங் அல்காரிதம்களின் நன்மைகளைப் பற்றி நான் மற்றொரு இடுகையில் கூறுவேன்).
ஹேஷிங் மற்றும் என்க்ரிப்ஷன் பற்றிய விரைவான வாதம்: கடவுச்சொல்லை ஹாஷ் செய்வதை விட, நீங்கள் குறியாக்கம் செய்ய வேண்டிய ஒரே காரணம், நீங்கள் கடவுச்சொல்லை எளிய உரையில் பார்க்க வேண்டும், மற்றும் நீங்கள் இதை ஒருபோதும் விரும்பவில்லை, குறைந்தபட்சம் ஒரு நிலையான வலைத்தள சூழ்நிலையில். உங்களுக்கு இது தேவைப்பட்டால், பெரும்பாலும் நீங்கள் ஏதாவது தவறு செய்கிறீர்கள்!
எச்சரிக்கை
இடுகையின் உரையில் கீழே உள்ள ஆபாச வலைத்தளமான AlotPorn இன் ஸ்கிரீன்ஷாட்டின் ஒரு பகுதி உள்ளது. இது நேர்த்தியாக டிரிம் செய்யப்பட்டுள்ளதால், கடற்கரையில் நீங்கள் பார்க்க முடியாதது எதுவுமில்லை, ஆனால் அது இன்னும் ஏதேனும் சிக்கல்களை ஏற்படுத்தக்கூடும் என்றால், கீழே ஸ்க்ரோல் செய்ய வேண்டாம்.
உங்கள் கடவுச்சொல்லை எப்போதும் மீட்டமைக்கவும் ஒருபோதும் அவரை நினைவுபடுத்த வேண்டாம்
நீங்கள் எப்போதாவது ஒரு செயல்பாட்டை உருவாக்கும்படி கேட்கப்பட்டுள்ளீர்களா நினைவூட்டல்கள் கடவுச்சொல்? ஒரு படி பின்வாங்கி, இந்த கோரிக்கையை தலைகீழாக யோசித்துப் பாருங்கள்: இந்த "நினைவூட்டல்" ஏன் அவசியம்? ஏனெனில் பயனர் கடவுச்சொல்லை மறந்துவிட்டார். நாம் உண்மையில் என்ன செய்ய விரும்புகிறோம்? மீண்டும் உள்நுழைய அவருக்கு உதவுங்கள்.
"நினைவூட்டல்" என்ற வார்த்தையானது (பெரும்பாலும்) பேச்சுவழக்கில் பயன்படுத்தப்படுகிறது என்பதை நான் உணர்கிறேன், ஆனால் நாம் உண்மையில் என்ன செய்ய முயற்சிக்கிறோம் பயனர் மீண்டும் ஆன்லைனில் இருக்க பாதுகாப்பாக உதவுங்கள். எங்களுக்கு பாதுகாப்பு தேவை என்பதால், நினைவூட்டல் (அதாவது பயனருக்கு அவர்களின் கடவுச்சொல்லை அனுப்புவது) பொருத்தமற்றதாக இருப்பதற்கு இரண்டு காரணங்கள் உள்ளன:
- மின்னஞ்சல் ஒரு பாதுகாப்பற்ற சேனல். HTTP (HTTPSஐப் பயன்படுத்துவோம்) மூலம் உணர்திறன் வாய்ந்த எதையும் நாங்கள் அனுப்பாதது போல, அதன் போக்குவரத்து அடுக்கு பாதுகாப்பற்றதாக இருப்பதால், மின்னஞ்சலில் முக்கியமான எதையும் அனுப்பக்கூடாது. உண்மையில், பாதுகாப்பற்ற போக்குவரத்து நெறிமுறை மூலம் தகவலை அனுப்புவதை விட இது மிகவும் மோசமானது, ஏனெனில் அஞ்சல் பெரும்பாலும் சேமிப்பக சாதனத்தில் சேமிக்கப்படுகிறது, கணினி நிர்வாகிகளுக்கு அணுகக்கூடியது, அனுப்பப்பட்டு விநியோகிக்கப்படுகிறது, தீம்பொருளுக்கு அணுகக்கூடியது மற்றும் பல. மறைகுறியாக்கப்பட்ட மின்னஞ்சல் மிகவும் பாதுகாப்பற்ற சேனலாகும்.
- எப்படியும் நீங்கள் கடவுச்சொல்லை அணுகக்கூடாது. சேமிப்பகத்தின் முந்தைய பகுதியை மீண்டும் படிக்கவும் - உங்களிடம் கடவுச்சொல்லின் ஹாஷ் இருக்க வேண்டும் (நல்ல வலுவான உப்பு), அதாவது நீங்கள் எந்த வகையிலும் கடவுச்சொல்லை பிரித்தெடுத்து அஞ்சல் மூலம் அனுப்ப முடியாது.
சிக்கலை ஒரு உதாரணத்துடன் விளக்குகிறேன் : இங்கே ஒரு பொதுவான உள்நுழைவு பக்கம்:
வெளிப்படையாக, முதல் சிக்கல் என்னவென்றால், உள்நுழைவுப் பக்கம் HTTPS இல் ஏற்றப்படவில்லை, ஆனால் கடவுச்சொல்லை அனுப்பவும் தளம் உங்களைத் தூண்டுகிறது ("கடவுச்சொல்லை அனுப்பு"). மேலே குறிப்பிட்டுள்ள வார்த்தையின் பேச்சுவழக்கு பயன்பாட்டிற்கு இது ஒரு உதாரணமாக இருக்கலாம், எனவே இதை ஒரு படி மேலே எடுத்து என்ன நடக்கிறது என்பதைப் பார்ப்போம்:
துரதிருஷ்டவசமாக, இது சிறப்பாகத் தெரியவில்லை; மற்றும் ஒரு மின்னஞ்சல் ஒரு சிக்கல் இருப்பதை உறுதிப்படுத்துகிறது:
இது usoutdoor.com இன் இரண்டு முக்கிய அம்சங்களை நமக்கு சொல்கிறது:
- தளம் கடவுச்சொற்களை ஹாஷ் செய்வதில்லை. சிறந்தது, அவை குறியாக்கம் செய்யப்பட்டவை, ஆனால் அவை சாதாரண உரையில் சேமிக்கப்பட்டிருக்கலாம்; இதற்கு நேர்மாறான எந்த ஆதாரத்தையும் நாங்கள் காணவில்லை.
- இந்தத் தளம் ஒரு நீண்ட கால கடவுச்சொல்லை (நாம் திரும்பிச் சென்று மீண்டும் மீண்டும் பயன்படுத்தலாம்) பாதுகாப்பற்ற சேனலில் அனுப்புகிறது.
இது வெளியே வருவதால், மீட்டமைப்பு செயல்முறை பாதுகாப்பான முறையில் செய்யப்படுகிறதா என்பதைச் சரிபார்க்க வேண்டும். இதைச் செய்வதற்கான முதல் படி, மீட்டமைப்பைச் செய்ய கோரிக்கையாளருக்கு உரிமை உள்ளதா என்பதை உறுதிப்படுத்துவது. வேறு வார்த்தைகளில் கூறுவதானால், இதற்கு முன் நமக்கு ஒரு அடையாள சரிபார்ப்பு தேவை; கோரிக்கையாளர் உண்மையில் கணக்கு உரிமையாளர்தானா என்பதை முதலில் சரிபார்க்காமல் அடையாளம் சரிபார்க்கப்பட்டால் என்ன ஆகும் என்பதைப் பார்ப்போம்.
பயனர்பெயர்களை பட்டியலிடுதல் மற்றும் பெயர் தெரியாததில் அதன் தாக்கம்
இந்த சிக்கல் பார்வைக்கு சிறப்பாக விளக்கப்பட்டுள்ளது. பிரச்சனை:
நீ பார்க்கிறாயா? "இந்த மின்னஞ்சல் முகவரியுடன் பதிவுசெய்யப்பட்ட பயனர் யாரும் இல்லை" என்ற செய்திக்கு கவனம் செலுத்துங்கள். அத்தகைய தளம் உறுதிப்படுத்தினால் சிக்கல் வெளிப்படையாக எழுகிறது கிடைக்கும் அத்தகைய மின்னஞ்சல் முகவரியுடன் பதிவுசெய்யப்பட்ட பயனர். பிங்கோ - உங்கள் கணவர்/முதலாளி/அண்டை வீட்டாரின் ஆபாசப் பிரயோஜனத்தை நீங்கள் இப்போதுதான் கண்டுபிடித்தீர்கள்!
நிச்சயமாக, ஆபாசமானது தனியுரிமையின் முக்கியத்துவத்திற்கு மிகச் சிறந்த உதாரணம், ஆனால் ஒரு குறிப்பிட்ட இணையதளத்துடன் ஒரு தனிநபரை தொடர்புபடுத்துவதால் ஏற்படும் ஆபத்துகள் மேலே விவரிக்கப்பட்ட மோசமான சூழ்நிலையை விட மிகவும் விரிவானது. ஒரு ஆபத்து சமூக பொறியியல்; தாக்குதல் செய்பவர் ஒரு நபரை சேவையுடன் பொருத்த முடிந்தால், அவர் பயன்படுத்தத் தொடங்கும் தகவல் அவரிடம் இருக்கும். எடுத்துக்காட்டாக, அவர் ஒரு இணையதளத்தின் பிரதிநிதியாகக் காட்டிக் கொள்ளும் ஒருவரைத் தொடர்புகொண்டு அதற்கான முயற்சியில் கூடுதல் தகவலைக் கோரலாம் .
இத்தகைய நடைமுறைகள் "பயனர் பெயர் எண்ணும்" ஆபத்தையும் எழுப்புகின்றன, இதன் மூலம் குழு வினவல்களை நடத்தி அவற்றுக்கான பதில்களை ஆராய்வதன் மூலம் ஒரு இணையதளத்தில் பயனர் பெயர்கள் அல்லது மின்னஞ்சல் முகவரிகளின் முழுத் தொகுப்பின் இருப்பை ஒருவர் சரிபார்க்க முடியும். உங்களிடம் அனைத்து ஊழியர்களின் மின்னஞ்சல் முகவரிகளின் பட்டியல் மற்றும் ஸ்கிரிப்ட் எழுத சில நிமிடங்கள் உள்ளதா? அப்புறம் என்ன பிரச்சனை என்று பாருங்கள்!
மாற்று வழி என்ன? உண்மையில், இது மிகவும் எளிமையானது மற்றும் அற்புதமாக செயல்படுத்தப்படுகிறது :
இங்கே Entropay அதன் கணினியில் மின்னஞ்சல் முகவரி இருப்பதைப் பற்றி முற்றிலும் எதையும் வெளிப்படுத்தவில்லை இந்த முகவரி இல்லாத ஒருவருக்கு. நீங்கள் என்றால் சொந்தம் இந்த முகவரி மற்றும் அது கணினியில் இல்லை, பிறகு நீங்கள் இது போன்ற மின்னஞ்சலைப் பெறுவீர்கள்:
நிச்சயமாக, யாரோ ஏற்றுக்கொள்ளக்கூடிய சூழ்நிலைகள் இருக்கலாம் நினைக்கிறார்நீங்கள் இணையதளத்தில் பதிவு செய்துள்ளீர்கள் என்று. ஆனால் இது அப்படி இல்லை அல்லது வேறு மின்னஞ்சல் முகவரியில் இருந்து செய்தேன். மேலே காட்டப்பட்டுள்ள எடுத்துக்காட்டு இரண்டு சூழ்நிலைகளையும் நன்கு கையாளுகிறது. வெளிப்படையாக, முகவரி பொருந்தினால், உங்கள் கடவுச்சொல்லை மீட்டமைப்பதை எளிதாக்கும் மின்னஞ்சலைப் பெறுவீர்கள்.
என்ட்ரோபேயால் தேர்ந்தெடுக்கப்பட்ட தீர்வின் நுணுக்கம் என்னவென்றால், அடையாள சரிபார்ப்பு அதன்படி செய்யப்படுகிறது மின்னஞ்சல் எந்த ஆன்லைன் சரிபார்ப்புக்கும் முன். சில தளங்கள் பாதுகாப்புக் கேள்விக்கான பதிலைப் பயனர்களிடம் கேட்கின்றன (இதைப் பற்றி மேலும் கீழே) செய்ய மீட்டமைப்பை எவ்வாறு தொடங்கலாம்; இருப்பினும், இதில் உள்ள சிக்கல் என்னவென்றால், சில வகையான அடையாளத்தை (மின்னஞ்சல் அல்லது பயனர்பெயர்) வழங்கும் போது நீங்கள் கேள்விக்கு பதிலளிக்க வேண்டும், இது அநாமதேய பயனரின் கணக்கின் இருப்பை வெளிப்படுத்தாமல் உள்ளுணர்வாக பதிலளிக்க இயலாது.
இந்த அணுகுமுறையுடன் உள்ளது சிறிய பயன்பாட்டினைக் குறைத்தது, ஏனெனில் நீங்கள் இல்லாத கணக்கை மீட்டமைக்க முயற்சித்தால், உடனடி கருத்து எதுவும் இல்லை. நிச்சயமாக, இது ஒரு மின்னஞ்சலை அனுப்புவதற்கான முழுப் புள்ளியாகும், ஆனால் உண்மையான இறுதிப் பயனரின் கண்ணோட்டத்தில், அவர்கள் தவறான முகவரியை உள்ளிட்டால், அவர்கள் மின்னஞ்சலைப் பெறும்போது மட்டுமே அவர்களுக்குத் தெரியும். இது அவரது பங்கில் சில பதற்றத்தை ஏற்படுத்தக்கூடும், ஆனால் இது போன்ற ஒரு அரிய செயல்முறைக்கு இது ஒரு சிறிய விலை.
மற்றொரு குறிப்பு, தலைப்பிற்கு சற்று அப்பாற்பட்டது: பயனர்பெயர் அல்லது மின்னஞ்சல் முகவரி சரியானதா என்பதை வெளிப்படுத்தும் உள்நுழைவு உதவி செயல்பாடுகளிலும் இதே பிரச்சனை உள்ளது. நற்சான்றிதழ்கள் இருப்பதை வெளிப்படையாக உறுதிப்படுத்துவதற்குப் பதிலாக "உங்கள் பயனர்பெயர் மற்றும் கடவுச்சொல் சேர்க்கை தவறானது" என்ற செய்தியுடன் பயனருக்கு எப்போதும் பதிலளிக்கவும் (உதாரணமாக, "பயனர் பெயர் சரியானது, ஆனால் கடவுச்சொல் தவறானது").
மீட்டமை கடவுச்சொல்லை அனுப்புதல் vs மீட்டமை URL ஐ அனுப்புதல்
உங்கள் கடவுச்சொல்லை எவ்வாறு மீட்டமைப்பது என்பது பற்றி நாம் விவாதிக்க வேண்டிய அடுத்த கருத்து. இரண்டு பிரபலமான தீர்வுகள் உள்ளன:
- சேவையகத்தில் புதிய கடவுச்சொல்லை உருவாக்கி மின்னஞ்சல் மூலம் அனுப்புதல்
- மீட்டமைப்பு செயல்முறையை எளிதாக்க, தனிப்பட்ட URL உடன் மின்னஞ்சலை அனுப்பவும்
போதிலும் , முதல் புள்ளி ஒருபோதும் பயன்படுத்தப்படக்கூடாது. இதில் பிரச்சனை என்னவென்றால், இருக்கிறது என்று அர்த்தம் சேமிக்கப்பட்ட கடவுச்சொல், நீங்கள் எந்த நேரத்திலும் திரும்பவும் மீண்டும் பயன்படுத்தலாம்; இது ஒரு பாதுகாப்பற்ற சேனலில் அனுப்பப்பட்டது மற்றும் உங்கள் இன்பாக்ஸில் உள்ளது. மொபைல் சாதனங்கள் மற்றும் மின்னஞ்சல் கிளையண்ட் முழுவதும் இன்பாக்ஸ்கள் ஒத்திசைக்கப்படுவதற்கான வாய்ப்புகள் உள்ளன, மேலும் அவை இணைய மின்னஞ்சல் சேவையில் மிக நீண்ட காலத்திற்கு ஆன்லைனில் சேமிக்கப்படும். விஷயம் என்னவென்றால் நீண்ட கால சேமிப்பிற்கான நம்பகமான வழிமுறையாக அஞ்சல் பெட்டியை கருத முடியாது.
ஆனால் இது தவிர, முதல் புள்ளியில் மற்றொரு கடுமையான சிக்கல் உள்ளது - அது முடிந்தவரை எளிதாக்குகிறது தீங்கிழைக்கும் நோக்கத்துடன் கணக்கைத் தடுப்பது. இணையதளத்தில் கணக்கு வைத்திருக்கும் ஒருவரின் மின்னஞ்சல் முகவரி எனக்குத் தெரிந்தால், அவர்களின் கடவுச்சொல்லை மீட்டமைப்பதன் மூலம் எந்த நேரத்திலும் அவர்களைத் தடுக்கலாம்; இது வெள்ளித் தட்டில் பரிமாறப்பட்ட சேவை மறுப்புத் தாக்குதல்! அதனால்தான், கோரிக்கையாளரின் உரிமைகளை வெற்றிகரமாக சரிபார்த்த பின்னரே மீட்டமைப்பு செய்யப்பட வேண்டும்.
ரீசெட் URL பற்றிப் பேசும்போது, ஒரு இணையதளத்தின் முகவரியைக் குறிக்கிறோம் மீட்டமைப்பு செயல்முறையின் இந்த குறிப்பிட்ட நிகழ்வுக்கு தனித்துவமானது. நிச்சயமாக, இது சீரற்றதாக இருக்க வேண்டும், யூகிக்க எளிதாக இருக்கக்கூடாது, மேலும் மீட்டமைப்பதை எளிதாக்கும் கணக்கிற்கான வெளிப்புற இணைப்புகள் எதுவும் அதில் இருக்கக்கூடாது. எடுத்துக்காட்டாக, மீட்டமைப்பு URL ஆனது "Reset/?username=JohnSmith" போன்ற பாதையாக இருக்கக்கூடாது.
மீட்டமைக்கப்பட்ட URL ஆக அஞ்சல் செய்யக்கூடிய தனித்துவமான டோக்கனை நாங்கள் உருவாக்க விரும்புகிறோம், பின்னர் பயனரின் கணக்கின் சேவையகப் பதிவோடு பொருத்தப்படும், இதன் மூலம் கணக்கு உரிமையாளர், கடவுச்சொல்லை மீட்டமைக்க முயற்சிக்கும் அதே நபர்தான் என்பதை உறுதிப்படுத்துகிறோம். எடுத்துக்காட்டாக, ஒரு டோக்கன் "3ce7854015cd38c862cb9e14a1ae552b" ஆக இருக்கலாம் மற்றும் ரீசெட் செய்யும் பயனரின் ஐடி மற்றும் டோக்கன் உருவாக்கப்பட்ட நேரத்துடன் டேபிளில் சேமிக்கப்படும் (இதில் மேலும் கீழே). மின்னஞ்சல் அனுப்பப்படும் போது, அதில் “Reset/?id=3ce7854015cd38c862cb9e14a1ae552b” போன்ற URL உள்ளது, மேலும் பயனர் அதைப் பதிவிறக்கும் போது, பக்கம் டோக்கன் இருப்பதைத் தெரிவிக்கும், அதன் பிறகு அது பயனரின் தகவலை உறுதிசெய்து, அவர்களை மாற்ற அனுமதிக்கிறது. கடவுச்சொல்.
நிச்சயமாக, மேலே உள்ள செயல்முறை (வட்டம்) புதிய கடவுச்சொல்லை உருவாக்க பயனரை அனுமதிப்பதால், URL HTTPS இல் ஏற்றப்பட்டிருப்பதை உறுதி செய்ய வேண்டும். இல்லை, , இந்த டோக்கன் URL ஆனது போக்குவரத்து அடுக்கு பாதுகாப்பைப் பயன்படுத்த வேண்டும், இதனால் புதிய கடவுச்சொல் படிவத்தைத் தாக்க முடியாது மற்றும் பயனர் உருவாக்கிய கடவுச்சொல் பாதுகாப்பான இணைப்பில் அனுப்பப்பட்டது.
மீட்டமைப்பு URL க்கு நீங்கள் ஒரு டோக்கன் நேர வரம்பை சேர்க்க வேண்டும், இதனால் மீட்டமைப்பு செயல்முறை ஒரு மணி நேரத்திற்குள் முடிக்கப்படும். மீட்டமைப்பு நேர சாளரம் குறைந்தபட்சமாக வைக்கப்படுவதை இது உறுதிசெய்கிறது, இதனால் மீட்டமைப்பு URL ஐப் பெறுபவர் அந்த மிகச் சிறிய சாளரத்தில் மட்டுமே செயல்பட முடியும். நிச்சயமாக, தாக்குபவர் மீட்டமைப்பு செயல்முறையை மீண்டும் தொடங்கலாம், ஆனால் அவர்கள் மற்றொரு தனிப்பட்ட மீட்டமைப்பு URL ஐப் பெற வேண்டும்.
இறுதியாக, இந்த செயல்முறை களைந்துவிடும் என்பதை உறுதிப்படுத்த வேண்டும். மீட்டமைப்பு செயல்முறை முடிந்ததும், டோக்கன் அகற்றப்பட வேண்டும், இதனால் மீட்டமைப்பு URL செயல்படாது. தாக்குபவருக்கு மிகச் சிறிய சாளரம் இருப்பதை உறுதிசெய்ய முந்தைய புள்ளி அவசியம், அதன் போது அவர் மீட்டமைப்பு URL ஐ கையாள முடியும். கூடுதலாக, நிச்சயமாக, மீட்டமைப்பு வெற்றிகரமாக இருந்தால், டோக்கன் இனி தேவையில்லை.
இந்த படிகளில் சில அதிகப்படியான தேவையற்றதாக தோன்றலாம், ஆனால் அவை பயன்பாட்டிற்கு இடையூறு செய்யாது உண்மையில் பாதுகாப்பை மேம்படுத்துவது அரிதாக இருக்கும் என்று நாங்கள் நம்பும் சூழ்நிலைகளில். 99% வழக்குகளில், பயனர் மிகக் குறுகிய காலத்திற்குள் மீட்டமைப்பை இயக்குவார், மேலும் எதிர்காலத்தில் கடவுச்சொல்லை மீட்டமைக்க மாட்டார்.
CAPTCHA இன் பங்கு
ஓ, கேப்ட்சா, நாம் அனைவரும் வெறுக்க விரும்பும் பாதுகாப்பு அம்சம்! உண்மையில், CAPTCHA ஒரு அடையாளக் கருவியாக இருப்பதால் பாதுகாப்புக் கருவி அல்ல - நீங்கள் ஒரு நபராக இருந்தாலும் அல்லது ஒரு ரோபோவாக இருந்தாலும் (அல்லது தானியங்கு ஸ்கிரிப்ட்). தானாகவே படிவத்தை சமர்ப்பிப்பதைத் தவிர்ப்பதே இதன் நோக்கம், நிச்சயமாக, முடியும் பாதுகாப்பை உடைக்கும் முயற்சியாக பயன்படுத்தப்படும். கடவுச்சொல் மீட்டமைப்புகளின் சூழலில், CAPTCHA என்பது, பயனரை ஸ்பேம் செய்ய அல்லது கணக்குகள் இருப்பதைக் கண்டறிய முயற்சி செய்ய, மீட்டமைப்பு செயல்பாட்டை முரட்டுத்தனமாக கட்டாயப்படுத்த முடியாது. அடையாளங்களைச் சரிபார்த்தல்).
நிச்சயமாக, CAPTCHA தானே சரியானது அல்ல; அதன் மென்பொருள் "ஹேக்கிங்" மற்றும் போதுமான வெற்றி விகிதங்களை (60-70%) அடைவதற்கு பல முன்மாதிரிகள் உள்ளன. கூடுதலாக, எனது இடுகையில் ஒரு தீர்வு காட்டப்பட்டுள்ளது , ஒவ்வொரு CAPTCHA க்கும் தீர்வு காணவும், 94% வெற்றி விகிதத்தை அடையவும், ஒரு சதத்தின் பின்னங்களை மக்களுக்கு செலுத்தலாம். அதாவது, இது பாதிக்கப்படக்கூடியது, ஆனால் அது (சற்று) நுழைவதற்கான தடையை எழுப்புகிறது.
பேபால் உதாரணத்தைப் பார்ப்போம்:
இந்த வழக்கில், CAPTCHA தீர்க்கப்படும் வரை மீட்டமைப்பு செயல்முறை தொடங்க முடியாது கோட்பாட்டளவில் செயல்முறையை தானியக்கமாக்குவது சாத்தியமில்லை. கோட்பாட்டில்.
இருப்பினும், பெரும்பாலான இணைய பயன்பாடுகளுக்கு இது மிகையாக இருக்கும் மற்றும் முற்றிலும் சரி பயன்பாடு குறைவதைக் குறிக்கிறது - மக்கள் கேப்ட்சாவை விரும்புவதில்லை! கூடுதலாக, CAPTCHA என்பது தேவைப்பட்டால் நீங்கள் எளிதாக திரும்பப் பெறக்கூடிய ஒன்று. சேவையானது தாக்குதலுக்கு உள்ளாகத் தொடங்கினால் (இங்குதான் லாக்கிங் பயனுள்ளதாக இருக்கும், ஆனால் அது பின்னர் அதிகம்), பின்னர் CAPTCHA ஐச் சேர்ப்பது எளிதாக இருக்காது.
ரகசிய கேள்விகள் மற்றும் பதில்கள்
நாங்கள் கருதிய அனைத்து முறைகளிலும், மின்னஞ்சல் கணக்கை அணுகுவதன் மூலம் கடவுச்சொல்லை மீட்டமைக்க முடிந்தது. நான் "வெறும்" என்று சொல்கிறேன், ஆனால், நிச்சயமாக, வேறொருவரின் மின்னஞ்சல் கணக்கிற்கான அணுகலைப் பெறுவது சட்டவிரோதமானது. வேண்டும் ஒரு சிக்கலான செயல்முறையாக இருக்கும். எனினும் .
உண்மையில், சாரா பாலினின் Yahoo! ஹேக்கிங் பற்றி மேலே உள்ள இணைப்பு! இரண்டு நோக்கங்களுக்காக உதவுகிறது; முதலாவதாக, (சில) மின்னஞ்சல் கணக்குகளை ஹேக் செய்வது எவ்வளவு எளிது என்பதை இது விளக்குகிறது, இரண்டாவதாக, தீங்கிழைக்கும் நோக்கத்துடன் மோசமான பாதுகாப்பு கேள்விகள் எவ்வாறு பயன்படுத்தப்படலாம் என்பதை இது காட்டுகிறது. ஆனால் இதற்குப் பிறகு வருவோம்.
XNUMX% மின்னஞ்சல் அடிப்படையிலான கடவுச்சொல் மீட்டமைப்புகளில் உள்ள சிக்கல் என்னவென்றால், நீங்கள் மீட்டமைக்க முயற்சிக்கும் தளத்திற்கான கணக்கின் ஒருமைப்பாடு XNUMX% மின்னஞ்சல் கணக்கின் நேர்மையைப் பொறுத்தது. உங்கள் மின்னஞ்சலை அணுகக்கூடிய எவரும் மின்னஞ்சலைப் பெறுவதன் மூலம் மீட்டமைக்கக்கூடிய எந்தவொரு கணக்கிற்கும் அணுகல் உள்ளது. அத்தகைய கணக்குகளுக்கு, மின்னஞ்சல் என்பது உங்கள் ஆன்லைன் வாழ்க்கையின் "அனைத்து கதவுகளுக்கும் திறவுகோல்" ஆகும்.
இந்த அபாயத்தைக் குறைப்பதற்கான ஒரு வழி, பாதுகாப்பு கேள்வி மற்றும் பதில் முறையை செயல்படுத்துவதாகும். நீங்கள் ஏற்கனவே அவர்களைப் பார்த்திருப்பீர்கள் என்பதில் சந்தேகமில்லை: நீங்கள் மட்டுமே பதிலளிக்கக்கூடிய கேள்வியைத் தேர்ந்தெடுக்கவும் வேண்டும் பதில் தெரியும், பின்னர் உங்கள் கடவுச்சொல்லை மீட்டமைக்கும் போது அது உங்களிடம் கேட்கப்படும். மீட்டமைக்க முயற்சிக்கும் நபர் உண்மையில் கணக்கின் உரிமையாளர்தான் என்ற நம்பிக்கையை இது சேர்க்கிறது.
சாரா பாலினுக்குத் திரும்பு: தவறு என்னவென்றால், அவளது பாதுகாப்புக் கேள்வி/கேள்விகளுக்கான பதில்களை எளிதாகக் கண்டுபிடிக்க முடிந்தது. குறிப்பாக நீங்கள் ஒரு குறிப்பிடத்தக்க பொது நபராக இருக்கும்போது, உங்கள் தாயின் இயற்பெயர், கல்வி வரலாறு அல்லது கடந்த காலத்தில் யாரேனும் எங்கு வாழ்ந்திருக்கலாம் என்பது பற்றிய தகவல்கள் அவ்வளவு ரகசியமாக இருக்காது. உண்மையில், அதில் பெரும்பாலானவை கிட்டத்தட்ட யாராலும் கண்டுபிடிக்கப்படலாம். சாராவுக்கு நடந்தது இதுதான்:
ஹேக்கர் டேவிட் கெர்னல் பாலினின் பல்கலைக்கழகம் மற்றும் பிறந்த தேதி போன்ற அவரது பின்னணி பற்றிய விவரங்களைக் கண்டறிந்து, பின்னர் Yahoo!வின் மறந்துபோன கடவுச்சொல் மீட்பு அம்சத்தைப் பயன்படுத்தி பாலினின் கணக்கிற்கான அணுகலைப் பெற்றார்.
முதலில், இது Yahoo! - போன்ற எளிய கேள்விகளைக் குறிப்பிடுவதன் மூலம், நிறுவனம் முக்கியமாக பாதுகாப்பு கேள்வியின் மதிப்பை நாசப்படுத்தியது, எனவே அதன் அமைப்பின் பாதுகாப்பை. நிச்சயமாக, ஒரு மின்னஞ்சல் கணக்கிற்கான கடவுச்சொற்களை மீட்டமைப்பது எப்போதுமே மிகவும் கடினமாக உள்ளது, ஏனெனில் உரிமையாளருக்கு மின்னஞ்சல் அனுப்புவதன் மூலம் நீங்கள் உரிமையை நிரூபிக்க முடியாது (இரண்டாவது முகவரி இல்லாமல்), ஆனால் அதிர்ஷ்டவசமாக இன்று அத்தகைய அமைப்பை உருவாக்குவதற்கு அதிக பயன்கள் இல்லை.
பாதுகாப்பு கேள்விகளுக்கு திரும்புவோம் - பயனர் தங்கள் சொந்த கேள்விகளை உருவாக்க அனுமதிக்கும் விருப்பம் உள்ளது. பிரச்சனை என்னவென்றால், இது பயங்கரமான தெளிவான கேள்விகளை ஏற்படுத்தும்:
வானதஂதினஂ நிறமஂ எனஂன?
ஒரு பாதுகாப்பு கேள்வியை அடையாளம் காண பயன்படுத்தப்படும் போது, மக்கள் அசௌகரியத்தை ஏற்படுத்தும் கேள்விகள் மக்கள் (எடுத்துக்காட்டாக, அழைப்பு மையத்தில்):
கிறிஸ்மஸில் நான் யாருடன் தூங்கினேன்?
அல்லது வெளிப்படையாக முட்டாள் கேள்விகள்:
"கடவுச்சொல்" என்பதை எப்படி உச்சரிக்கிறீர்கள்?
பாதுகாப்பு கேள்விகள் வரும்போது, பயனர்கள் அவர்களிடமிருந்து காப்பாற்றப்பட வேண்டும்! வேறு வார்த்தைகளில் கூறுவதானால், பாதுகாப்பு கேள்வியானது தளத்தால் தீர்மானிக்கப்பட வேண்டும் அல்லது இன்னும் சிறப்பாக கேட்கப்பட வேண்டும் தொடர் பாதுகாப்பு கேள்விகளில் இருந்து பயனர் தேர்வு செய்யலாம். மேலும் தேர்வு செய்வது எளிதல்ல один; பயனர் இரண்டு அல்லது அதற்கு மேற்பட்ட பாதுகாப்பு கேள்விகளைத் தேர்ந்தெடுக்க வேண்டும் கணக்கு பதிவு நேரத்தில், இது இரண்டாவது அடையாள சேனலாகப் பயன்படுத்தப்படும். பல கேள்விகளைக் கொண்டிருப்பது சரிபார்ப்புச் செயல்பாட்டில் நம்பிக்கையை அதிகரிக்கிறது, மேலும் சீரற்ற தன்மையைச் சேர்க்கும் திறனையும் வழங்குகிறது (எப்பொழுதும் ஒரே கேள்வியைக் காட்டாது), மேலும் உண்மையான பயனர் கடவுச்சொல்லை மறந்துவிட்டால், சிறிது பணிநீக்கத்தை வழங்குகிறது.
ஒரு நல்ல பாதுகாப்பு கேள்வி என்ன? இது பல காரணிகளால் பாதிக்கப்படுகிறது:
- அவர் இருக்க வேண்டும் சுருக்கமான - கேள்வி தெளிவாகவும் தெளிவற்றதாகவும் இருக்க வேண்டும்.
- பதில் இருக்க வேண்டும் குறிப்பிட்ட - ஒருவர் வித்தியாசமாக பதிலளிக்கக்கூடிய கேள்வி எங்களுக்குத் தேவையில்லை
- சாத்தியமான பதில்கள் இருக்க வேண்டும் பலதரப்பட்ட - ஒருவரின் விருப்பமான நிறத்தைக் கேட்பது சாத்தியமான பதில்களின் மிகச் சிறிய துணைக்குழுவை அளிக்கிறது
- Поиск பதில் சிக்கலானதாக இருக்க வேண்டும் - பதிலை எளிதில் கண்டுபிடிக்க முடியுமானால் любой (உயர் பதவியில் இருப்பவர்களை நினைவில் வையுங்கள்), பிறகு அவர் கெட்டவர்
- பதில் இருக்க வேண்டும் நிரந்தர சரியான நேரத்தில் - நீங்கள் ஒருவருக்கு பிடித்த திரைப்படத்தைக் கேட்டால், ஒரு வருடம் கழித்து பதில் வித்தியாசமாக இருக்கலாம்
அது நடக்கும், என்று அழைக்கப்படும் நல்ல கேள்விகளைக் கேட்க அர்ப்பணிக்கப்பட்ட ஒரு இணையதளம் உள்ளது . சில கேள்விகள் மிகவும் நன்றாகத் தோன்றுகின்றன, மற்றவை மேலே விவரிக்கப்பட்ட சில சோதனைகளில் தேர்ச்சி பெறவில்லை, குறிப்பாக "தேடலின் எளிமை" சோதனை.
PayPal பாதுகாப்பு கேள்விகளை எவ்வாறு செயல்படுத்துகிறது மற்றும் குறிப்பாக, அங்கீகாரத்தில் தளம் எடுக்கும் முயற்சியை நான் விளக்குகிறேன். செயல்முறையைத் தொடங்குவதற்கான பக்கத்தை மேலே பார்த்தோம் (CAPTCHA உடன்), உங்கள் மின்னஞ்சல் முகவரியை உள்ளிட்டு CAPTCHA ஐத் தீர்த்த பிறகு என்ன நடக்கிறது என்பதை இங்கே காண்போம்:
இதன் விளைவாக, பயனர் பின்வரும் கடிதத்தைப் பெறுகிறார்:
இதுவரை எல்லாம் மிகவும் சாதாரணமானது, ஆனால் இந்த ரீசெட் URLக்குப் பின்னால் மறைந்திருப்பது இங்கே:
எனவே, பாதுகாப்பு கேள்விகள் செயல்படுகின்றன. உண்மையில், உங்கள் கிரெடிட் கார்டு எண்ணைச் சரிபார்ப்பதன் மூலம் உங்கள் கடவுச்சொல்லை மீட்டமைக்க PayPal உங்களை அனுமதிக்கிறது, எனவே பல தளங்களுக்கு அணுகல் இல்லாத கூடுதல் சேனல் உள்ளது. பதிலளிக்காமல் எனது கடவுச்சொல்லை மாற்ற முடியாது இருவரும் பாதுகாப்பு கேள்வி (அல்லது அட்டை எண் தெரியாமல்). எனது மின்னஞ்சலை யாரேனும் அபகரித்தாலும், என்னைப் பற்றிய இன்னும் கொஞ்சம் தனிப்பட்ட தகவல்கள் தெரிந்தால் தவிர, அவர்களால் எனது PayPal கணக்கின் கடவுச்சொல்லை மீட்டமைக்க முடியாது. என்ன தகவல்? PayPal வழங்கும் பாதுகாப்பு கேள்வி விருப்பங்கள் இங்கே:
பள்ளி மற்றும் மருத்துவமனையின் கேள்விகள் தேடலின் எளிமையின் அடிப்படையில் சிறியதாக இருக்கலாம், ஆனால் மற்றவை மிகவும் மோசமாக இல்லை. இருப்பினும், பாதுகாப்பை மேம்படுத்த, PayPal க்கு கூடுதல் அடையாளம் தேவை மாற்றங்கள் பாதுகாப்பு கேள்விகளுக்கான பதில்கள்:
பாதுகாப்பான கடவுச்சொல் மீட்டமைப்புகளுக்கு PayPal ஒரு அழகான கற்பனாவாத உதாரணம்: இது ப்ரூட்-ஃபோர்ஸ் தாக்குதல்களின் ஆபத்தை குறைக்க ஒரு CAPTCHA ஐ செயல்படுத்துகிறது, இரண்டு பாதுகாப்பு கேள்விகள் தேவை, பின்னர் பதில்களை மாற்ற மற்றொரு வகையான முற்றிலும் மாறுபட்ட அடையாளம் தேவைப்படுகிறது - இது பயனருக்குப் பிறகு ஏற்கனவே உள்நுழைந்துள்ளார். நிச்சயமாக, இதுதான் நாம் சரியாக உள்ளது எதிர்பார்க்கப்படுகிறது PayPal இலிருந்து; பெரிய தொகையை கையாளும் நிதி நிறுவனம் ஆகும். ஒவ்வொரு கடவுச்சொல் மீட்டமைப்பும் இந்த வழிமுறைகளைப் பின்பற்ற வேண்டும் என்று இது அர்த்தப்படுத்துவதில்லை-பெரும்பாலான நேரங்களில் அது ஓவர்கில்-ஆனால் பாதுகாப்பு தீவிரமான வணிகமாக இருக்கும் நிகழ்வுகளுக்கு இது ஒரு சிறந்த எடுத்துக்காட்டு.
பாதுகாப்பு கேள்வி அமைப்பின் வசதி என்னவென்றால், நீங்கள் அதை இப்போதே செயல்படுத்தவில்லை என்றால், வள பாதுகாப்பு நிலை தேவைப்பட்டால் அதை நீங்கள் பின்னர் சேர்க்கலாம். இதற்கு ஒரு சிறந்த உதாரணம் ஆப்பிள், இது சமீபத்தில் இந்த பொறிமுறையை செயல்படுத்தியது [2012 இல் எழுதப்பட்ட கட்டுரை]. எனது iPad இல் பயன்பாட்டைப் புதுப்பிக்கத் தொடங்கியவுடன், பின்வரும் கோரிக்கையைப் பார்த்தேன்:
பல ஜோடி பாதுகாப்பு கேள்விகள் மற்றும் பதில்களையும், மீட்பு மின்னஞ்சல் முகவரியையும் தேர்ந்தெடுக்கக்கூடிய திரையைப் பார்த்தேன்:
PayPal ஐப் பொறுத்தவரை, கேள்விகள் முன்பே தேர்ந்தெடுக்கப்பட்டவை மற்றும் அவற்றில் சில உண்மையில் நல்லவை:
மூன்று கேள்வி/பதில் ஜோடிகளில் ஒவ்வொன்றும் வெவ்வேறு சாத்தியமான கேள்விகளின் தொகுப்பைக் குறிக்கிறது, எனவே கணக்கை உள்ளமைக்க ஏராளமான வழிகள் உள்ளன.
உங்கள் பாதுகாப்பு கேள்விக்கு பதிலளிப்பதில் கருத்தில் கொள்ள வேண்டிய மற்றொரு அம்சம் சேமிப்பகம். தரவுத்தளத்தில் ஒரு எளிய உரை தரவுத்தளத்தை வைத்திருப்பது கடவுச்சொல்லைப் போன்ற அச்சுறுத்தல்களை ஏற்படுத்துகிறது, அதாவது தரவுத்தளத்தை உடனடியாக வெளிப்படுத்துவது மதிப்பை வெளிப்படுத்துகிறது மற்றும் பயன்பாட்டை மட்டும் ஆபத்தில் ஆழ்த்துகிறது, ஆனால் அதே பாதுகாப்பு கேள்விகளைப் பயன்படுத்தும் முற்றிலும் வேறுபட்ட பயன்பாடுகளை (மீண்டும் உள்ளது. ) பாதுகாப்பான ஹேஷிங் (வலுவான அல்காரிதம் மற்றும் கிரிப்டோகிராஃபிக் சீரற்ற உப்பு) ஒரு விருப்பம், ஆனால் பெரும்பாலான கடவுச்சொல் சேமிப்பக நிகழ்வுகளைப் போலல்லாமல், பதில் எளிய உரையாகத் தெரிவதற்கு ஒரு நல்ல காரணம் இருக்கலாம். நேரடி தொலைபேசி ஆபரேட்டரின் அடையாள சரிபார்ப்பு ஒரு பொதுவான காட்சியாகும். நிச்சயமாக, ஹாஷிங் இந்த வழக்கில் பொருந்தும் (ஆபரேட்டர் வெறுமனே கிளையன்ட் பெயரிடப்பட்ட பதிலை உள்ளிடலாம்), ஆனால் மோசமான நிலையில், ரகசிய பதில் சமச்சீர் குறியாக்கமாக இருந்தாலும் கூட, சில அளவிலான கிரிப்டோகிராஃபிக் சேமிப்பகத்தில் அமைந்திருக்க வேண்டும். . சுருக்கமாக: இரகசியங்களை இரகசியங்களைப் போல நடத்துங்கள்!
பாதுகாப்பு கேள்விகள் மற்றும் பதில்களின் இறுதி அம்சம் என்னவென்றால், அவை சமூக பொறியியலுக்கு மிகவும் பாதிக்கப்படக்கூடியவை. வேறொருவரின் கணக்கில் கடவுச்சொல்லை நேரடியாகப் பிரித்தெடுக்க முயற்சிப்பது ஒரு விஷயம், ஆனால் அதன் உருவாக்கம் (ஒரு பிரபலமான பாதுகாப்பு கேள்வி) பற்றிய உரையாடலைத் தொடங்குவது முற்றிலும் வேறுபட்டது. உண்மையில், சந்தேகத்திற்கு இடமின்றி ஒரு ரகசிய கேள்வியை எழுப்பக்கூடிய அவர்களின் வாழ்க்கையின் பல அம்சங்களைப் பற்றி நீங்கள் ஒருவருடன் நன்றாகத் தொடர்பு கொள்ளலாம். நிச்சயமாக, ஒரு பாதுகாப்பு கேள்வியின் முக்கிய அம்சம் என்னவென்றால், அது ஒருவரின் வாழ்க்கை அனுபவத்துடன் தொடர்புடையது, எனவே அது மறக்கமுடியாதது, மேலும் அங்குதான் சிக்கல் உள்ளது - மக்கள் தங்கள் வாழ்க்கை அனுபவங்களைப் பற்றி பேச விரும்புகிறார்கள்! இதுபோன்ற பாதுகாப்பு கேள்வி விருப்பங்களை நீங்கள் தேர்வுசெய்தால் மட்டுமே இதைப் பற்றி நீங்கள் செய்யக்கூடியது மிகக் குறைவு குறைவாக ஒருவேளை சமூகப் பொறியியலால் வெளியேற்றப்படலாம்.
[தொடரும்.]விளம்பரம் உரிமைகள் மீது
VDSina நம்பகமான வழங்குகிறது , ஒவ்வொரு சேவையகமும் 500 மெகாபிட் இணைய சேனலுடன் இணைக்கப்பட்டுள்ளது மற்றும் இலவசமாக DDoS தாக்குதல்களிலிருந்து பாதுகாக்கப்படுகிறது!
ஆதாரம்: www.habr.com
