પાસવર્ડ ઈમેલ ઉલટાવી શકાય તેવી ક્ષમતા સાબિત કરે છે, સ્કીમા નહીં

એક સેવા જે વપરાશકર્તાનો વર્તમાન પાસવર્ડ ઈમેલ કરે છે, તેણે એક વાત સાબિત કરી છે: તે એ રહસ્ય એવા સ્વરૂપમાં મેળવી શકે છે જે તે મોકલી શકે. તેણે એ સાબિત કર્યું નથી કે કયો કૉલમ, અલ્ગોરિધમ કે લાઇબ્રેરી તેને બનાવી. આ ફરક મહત્વનો છે, કારણ કે શોધ સાચી છે અને લોકો તેમાંથી જે નિષ્કર્ષ કાઢે છે તે સામાન્ય રીતે વધુ પડતો ચોક્કસ હોય છે. માર્ગમાં ક્યાંક ઉલટાવી શકાય તેવી ક્ષમતા એ જ મિકેનિઝમ છે; અનુમાનિત સંગ્રહ ફોર્મેટ નહીં.

પુરાવાને એ સ્તરે રાખો, અને સમીક્ષાનો બાકીનો ભાગ સચોટ રહેશે.

જૂનું રહસ્ય પાછું મોકલવું શું સાબિત કરે છે

એકમાર્ગી ચકાસણી કરનાર મૂળ પાસવર્ડ બનાવી શકતો નથી, કારણ કે તેને ઉલટાવી ન શકાય તે રીતે ડિઝાઇન કરવામાં આવ્યો છે. જો સેવા પાસવર્ડ ઈમેલ કરી શકે છે, તો તે ક્ષણે તે એવી સામગ્રી રાખે છે જેમાંથી પાસવર્ડ પુનઃપ્રાપ્ત થઈ શકે છે, અથવા તે હેશ કરતાં પહેલાં સાદું લખાણ પકડીને સંગ્રહે છે. બંને રીતે પુનઃપ્રાપ્તિનો માર્ગ ઉલટાવી શકાય તેવો છે, અને તે સાચી સુરક્ષા શોધ છે. તે એ વિશે કંઈ કહેતું નથી કે એ જ ડેટાબેઝ અન્ય કૉલમ માટે ખર્ચાળ હેશ વાપરે છે કે નહીં.

વચગાળાના કિસ્સા પર પણ ધ્યાન આપો: એપ્લિકેશન પાસેની ચાવી સાથે સંગ્રહિત એન્ક્રિપ્ટેડ બ્લોબ વ્યવહારમાં ઉલટાવી શકાય તેવો છે, જોકે એન્ક્રિપ્ટેડ શબ્દ અહેવાલમાં દિલાસો આપતો સંભળાય છે.

આ ડિઝાઇન શોધ કેમ છે, સંગ્રહનો નકશો નહીં

ઈમેલ પુનઃપ્રાપ્તિક્ષમતા સાબિત કરે છે અને ચોક્કસ સ્કીમા ઓળખતું નથી. તે સાદું લખાણ, નિર્ધારિત એન્ક્રિપ્શન, વિક્રેતાની અસ્પષ્ટીકરણ રૂટિન, અથવા ફક્ત પુનઃપ્રાપ્તિ માટે વપરાતો અલગ ક્રેડેન્શિયલ સ્ટોર હોઈ શકે છે. ઉત્પાદનના જુદા જુદા ભાગો ઘણી વાર જુદો સંગ્રહ વાપરે છે. એક ઈમેલના આધારે અલ્ગોરિધમ નક્કી કરવું એ એવો દાવો છે જે આગલી બેઠકમાં ધરાશાયી થાય છે.

તમે જે કહી શકો તે વધુ સંકુચિત અને વધુ ઉપયોગી છે: આ માર્ગ રહસ્ય પુનઃપ્રાપ્ત કરી શકે છે, તેથી ઉત્પાદન એ દાવો કરી શકતું નથી કે કોઈ પુનઃપ્રાપ્ત કરી શકાય તેવું ક્રેડેન્શિયલ નથી. તેનાથી આગળની દરેક વાત માટે ઓપરેટરના પુરાવા જોઈએ.

ઓથોરાઇઝેશનની આસપાસ રીસેટ બનાવો

રીસેટ બીજી સમસ્યા હલ કરે છે: એ સાબિત કરવું કે વિનંતી કરનાર નવો પાસવર્ડ પસંદ કરી શકે છે. આ અંગે OWASPનું માર્ગદર્શન સુરક્ષિત રીતે જનરેટ કરેલા, એકવાર વપરાતા ટોકન અથવા કોડ અને યોગ્ય સમાપ્તિ સમયનું વર્ણન કરે છે, અને વિનંતીના તબક્કાને ગણતરી અને પૂરથી બચાવવા જેવી વસ્તુ તરીકે ગણે છે. અપ્રમાણિત વિનંતીએ પોતાની રીતે ખાતું બદલવું ન જોઈએ. બદલી સ્વીકારતાં પહેલાં ઓથોરાઇઝેશન માન્ય કરો, અને એક સફળ ઉપયોગ પછી ટોકનને નકામું બનાવો.

ઈમેલ ચેનલ સુરક્ષા મોડેલનો ભાગ છે. ખાતાનું નામ ધરાવવું કંઈ સાબિત કરતું નથી, અને ખાતું અસ્તિત્વમાં છે કે નહીં તે જાહેર કરતો રીસેટ પ્રવાહ હુમલાખોરને કામ કરવા માટે નિર્દેશિકા આપે છે.

પાસવર્ડ જેનું રક્ષણ કરતો હતો તે રદ કરો

પાસવર્ડ બદલવાથી તે જે પ્રવેશ આપતો હતો તે આપોઆપ સમાપ્ત થતો નથી. સક્રિય VPN સત્રો, યાદ રાખેલા ઉપકરણો અને સર્વર દ્વારા જારી કરાયેલા ટોકન—દરેકની પોતાની રદ કરવાની વર્તણૂક હોઈ શકે છે. સભાનપણે નક્કી કરો કે કયા સમાપ્ત થવા જોઈએ, અને ચકાસો કે અમલ એમ કરે છે, કારણ કે જે વપરાશકર્તા ધારે છે કે રીસેટે તેને દરેક જગ્યાએથી લોગ આઉટ કર્યો છે તે ઘણી વાર ખોટો પડે છે. તે નિર્ણય પ્રવાહ સાથે નોંધો.

ઓપરેટરો માટે: કયો ઘટક વિનંતી ચકાસે છે, કયો ક્રેડેન્શિયલ બદલે છે અને સંબંધિત સત્રો કેવી રીતે સંભાળવામાં આવે છે તે દસ્તાવેજ કરો. વપરાશકર્તાઓ માટે: કાયદેસર પુનઃપ્રાપ્તિ ચેનલનું રક્ષણ કરો અને પાસવર્ડ પાછો મોકલતા કોઈપણ સંદેશને શંકાસ્પદ ગણો.

ચોક્કસ મૂલ્યાંકન ટૂંકું છે: સંદેશ શું સાબિત કરે છે, શું અજાણ રહે છે, અને શું પુનઃપ્રાપ્તિ નિયંત્રિત પ્રક્રિયા દ્વારા પ્રવેશનું સ્થાન લે છે.