સુરક્ષિત પાસવર્ડ રીસેટ વિશે તમે ક્યારેય જાણવા માંગતા હો તે બધું. ભાગ 1

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

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

પાસવર્ડ સ્ટોરેજ: હેશિંગ, એન્ક્રિપ્શન અને (હાંફવું!) સાદો ટેક્સ્ટ

ભૂલી ગયેલા પાસવર્ડ્સ કેવી રીતે સંગ્રહિત કરવા તેની ચર્ચા કરતા પહેલા અમે તેની સાથે શું કરવું તેની ચર્ચા કરી શકતા નથી. પાસવર્ડ્સ ડેટાબેઝમાં ત્રણ મુખ્ય પ્રકારોમાંથી એકમાં સંગ્રહિત થાય છે:

1. સરળ લખાણ. ત્યાં એક પાસવર્ડ કૉલમ છે, જે સાદા ટેક્સ્ટ સ્વરૂપમાં સંગ્રહિત છે.
2. એન્ક્રિપ્ટેડ. સામાન્ય રીતે સપ્રમાણ એન્ક્રિપ્શનનો ઉપયોગ કરીને (એક કીનો ઉપયોગ એન્ક્રિપ્શન અને ડિક્રિપ્શન બંને માટે થાય છે), અને એન્ક્રિપ્ટેડ પાસવર્ડ્સ પણ સમાન કૉલમમાં સંગ્રહિત થાય છે.
3. હેશેડ. વન-વે પ્રક્રિયા (પાસવર્ડ હેશ કરી શકાય છે, પરંતુ ડિહેશ કરી શકાતો નથી); પાસવર્ડ, હું આશા રાખવા માંગુ છું, એક મીઠું દ્વારા અનુસરવામાં આવે છે, અને દરેક તેના પોતાના સ્તંભમાં છે.

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

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

અને આ આપણને હેશિંગ તરફ લાવે છે. હેશિંગ પાછળનો વિચાર એ છે કે તે વન-વે છે; વપરાશકર્તા દ્વારા દાખલ કરેલ પાસવર્ડને તેના હેશ કરેલ સંસ્કરણ સાથે સરખાવવાનો એકમાત્ર રસ્તો એ છે કે ઇનપુટને હેશ કરો અને તેની તુલના કરો. મેઘધનુષ્ય કોષ્ટકો જેવા સાધનોના હુમલાને રોકવા માટે, અમે પ્રક્રિયાને રેન્ડમનેસ સાથે મીઠું કરીએ છીએ (મારું વાંચો પોસ્ટ ક્રિપ્ટોગ્રાફિક સ્ટોરેજ વિશે). આખરે, જો યોગ્ય રીતે અમલ કરવામાં આવે તો, અમે વિશ્વાસ રાખી શકીએ છીએ કે હેશ કરેલા પાસવર્ડ્સ ફરી ક્યારેય સાદો ટેક્સ્ટ બનશે નહીં (હું બીજી પોસ્ટમાં વિવિધ હેશિંગ અલ્ગોરિધમ્સના ફાયદા વિશે વાત કરીશ).

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

સાવધાન

પોસ્ટના ટેક્સ્ટની નીચે પોર્નોગ્રાફિક વેબસાઇટ એલોટપોર્નના સ્ક્રીનશોટનો એક ભાગ છે. તે સરસ રીતે સુવ્યવસ્થિત છે તેથી તમે બીચ પર જોઈ શકતા નથી એવું કંઈ નથી, પરંતુ જો તે હજુ પણ કોઈ સમસ્યા ઊભી કરે તેવી શક્યતા છે, તો નીચે સ્ક્રોલ કરશો નહીં.

હંમેશા તમારો પાસવર્ડ રીસેટ કરો ક્યારેય નહીં તેને યાદ ન કરાવો

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

મને ખ્યાલ છે કે "રિમાઇન્ડર" શબ્દનો ઉપયોગ (ઘણી વખત) બોલચાલના અર્થમાં થાય છે, પરંતુ અમે ખરેખર શું કરવાનો પ્રયાસ કરી રહ્યા છીએ તે છે વપરાશકર્તાને ફરીથી ઑનલાઇન થવામાં સુરક્ષિત રીતે સહાય કરો. અમને સુરક્ષાની જરૂર હોવાથી, રીમાઇન્ડર (એટલે ​​​​કે વપરાશકર્તાને તેનો પાસવર્ડ મોકલવો) શા માટે યોગ્ય નથી તેના બે કારણો છે:

1. ઈમેલ એક અસુરક્ષિત ચેનલ છે. જેમ આપણે HTTP (અમે HTTPS નો ઉપયોગ કરીશું) પર કંઈપણ સંવેદનશીલ મોકલીશું નહીં તેમ, અમારે ઇમેઇલ પર કંઈપણ સંવેદનશીલ મોકલવું જોઈએ નહીં કારણ કે તેનું પરિવહન સ્તર અસુરક્ષિત છે. વાસ્તવમાં, આ ફક્ત અસુરક્ષિત ટ્રાન્સપોર્ટ પ્રોટોકોલ પર માહિતી મોકલવા કરતાં ઘણું ખરાબ છે, કારણ કે મેઇલ મોટાભાગે સ્ટોરેજ ડિવાઇસ પર સંગ્રહિત થાય છે, સિસ્ટમ એડમિનિસ્ટ્રેટર્સ માટે સુલભ, ફોરવર્ડ અને વિતરિત, માલવેર માટે સુલભ, વગેરે. અનએન્ક્રિપ્ટેડ ઈમેલ એ અત્યંત અસુરક્ષિત ચેનલ છે.
2. કોઈપણ રીતે તમારી પાસે પાસવર્ડની ઍક્સેસ હોવી જોઈએ નહીં. સ્ટોરેજ પરના પાછલા વિભાગને ફરીથી વાંચો - તમારી પાસે પાસવર્ડનો હેશ હોવો જોઈએ (સારા મજબૂત મીઠા સાથે), એટલે કે તમે કોઈપણ રીતે પાસવર્ડ કાઢીને તેને મેઇલ દ્વારા મોકલી શકતા નથી.

મને એક ઉદાહરણ સાથે સમસ્યા દર્શાવવા દો usoutdoor.comઅહીં એક સામાન્ય લૉગિન પૃષ્ઠ છે:

દેખીતી રીતે, પ્રથમ સમસ્યા એ છે કે લોગિન પૃષ્ઠ HTTPS પર લોડ થતું નથી, પરંતુ સાઇટ તમને પાસવર્ડ મોકલવા માટે પણ સંકેત આપે છે (“પાસવર્ડ મોકલો”). આ ઉપર જણાવેલ શબ્દના બોલચાલના ઉપયોગનું ઉદાહરણ હોઈ શકે છે, તેથી ચાલો તેને એક પગલું આગળ લઈએ અને જોઈએ કે શું થાય છે:

તે વધુ સારું લાગતું નથી, કમનસીબે; અને એક ઈમેલ પુષ્ટિ કરે છે કે કોઈ સમસ્યા છે:

આ અમને usoutdoor.com ના બે મહત્વપૂર્ણ પાસાઓ કહે છે:

1. સાઇટ પાસે પાસવર્ડ્સ હેશ નથી. શ્રેષ્ઠ રીતે, તેઓ એન્ક્રિપ્ટેડ છે, પરંતુ સંભવ છે કે તેઓ સાદા ટેક્સ્ટમાં સંગ્રહિત છે; અમે તેનાથી વિપરીત કોઈ પુરાવા જોતા નથી.
2. સાઇટ અસુરક્ષિત ચેનલ પર લાંબા ગાળાનો પાસવર્ડ મોકલે છે (અમે પાછા જઈ શકીએ છીએ અને તેનો વારંવાર ઉપયોગ કરી શકીએ છીએ).

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

વપરાશકર્તાનામોની સૂચિ અને અનામી પર તેની અસર

આ સમસ્યાને દૃષ્ટિની રીતે શ્રેષ્ઠ રીતે દર્શાવવામાં આવી છે. સમસ્યા:

તમે જોયું? સંદેશ પર ધ્યાન આપો "આ ઇમેઇલ સરનામાં સાથે કોઈ વપરાશકર્તા નોંધાયેલ નથી." જો આવી સાઇટ પુષ્ટિ કરે તો સમસ્યા દેખીતી રીતે ઊભી થાય છે પ્રાપ્યતા આવા ઈમેલ એડ્રેસ સાથે નોંધાયેલ વપરાશકર્તા. બિન્ગો - તમે હમણાં જ તમારા પતિ/બોસ/પાડોશીનું પોર્ન ફેટિશ શોધી કાઢ્યું છે!

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

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

વિકલ્પ શું છે? વાસ્તવમાં, તે એકદમ સરળ છે, અને અદ્ભુત રીતે અમલમાં મૂકવામાં આવ્યું છે એન્ટ્રોપે:

અહીં એન્ટ્રોપે તેની સિસ્ટમમાં ઈમેલ એડ્રેસના અસ્તિત્વ વિશે બિલકુલ કંઈપણ જાહેર કરતું નથી જે આ સરનામું ધરાવતું નથી... જો તમે પોતાના આ સરનામું અને તે સિસ્ટમમાં અસ્તિત્વમાં નથી, તો પછી તમને આના જેવું ઇમેઇલ પ્રાપ્ત થશે:

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

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

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

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

રીસેટ પાસવર્ડ મોકલવું વિ રીસેટ URL મોકલવું

હવે પછીના ખ્યાલ પર આપણે ચર્ચા કરવાની જરૂર છે કે તમારો પાસવર્ડ કેવી રીતે રીસેટ કરવો. ત્યાં બે લોકપ્રિય ઉકેલો છે:

1. સર્વર પર નવો પાસવર્ડ જનરેટ કરીને ઈમેલ દ્વારા મોકલવો
2. રીસેટ પ્રક્રિયાને સરળ બનાવવા માટે અનન્ય URL સાથે એક ઇમેઇલ મોકલો

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

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

જ્યારે આપણે રીસેટ URL વિશે વાત કરીએ છીએ, ત્યારે અમારો અર્થ એ છે કે વેબસાઇટનું સરનામું રીસેટ પ્રક્રિયાના આ ચોક્કસ કેસ માટે અનન્ય. અલબત્ત, તે રેન્ડમ હોવું જોઈએ, તેનું અનુમાન લગાવવું સરળ ન હોવું જોઈએ અને તેમાં એકાઉન્ટની કોઈપણ બાહ્ય લિંક્સ હોવી જોઈએ નહીં જે તેને રીસેટ કરવાનું સરળ બનાવે. ઉદાહરણ તરીકે, રીસેટ URL ફક્ત "રીસેટ/?username=JohnSmith" જેવો પાથ ન હોવો જોઈએ.

અમે એક અનન્ય ટોકન બનાવવા માંગીએ છીએ જે રીસેટ URL તરીકે મેઇલ કરી શકાય, અને પછી વપરાશકર્તાના એકાઉન્ટના સર્વર રેકોર્ડ સાથે મેળ ખાય, આમ પુષ્ટિ થાય છે કે એકાઉન્ટ માલિક, હકીકતમાં, તે જ વ્યક્તિ છે જે પાસવર્ડ રીસેટ કરવાનો પ્રયાસ કરી રહ્યો છે. ઉદાહરણ તરીકે, ટોકન "3ce7854015cd38c862cb9e14a1ae552b" હોઈ શકે છે અને રીસેટ કરી રહેલા વપરાશકર્તાના ID અને ટોકન જનરેટ થયાના સમય સાથે કોષ્ટકમાં સંગ્રહિત થઈ શકે છે (નીચે આના પર વધુ). જ્યારે ઈમેલ મોકલવામાં આવે છે, ત્યારે તેમાં “Reset/?id=3ce7854015cd38c862cb9e14a1ae552b” જેવું URL હોય છે, અને જ્યારે વપરાશકર્તા તેને ડાઉનલોડ કરે છે, ત્યારે પેજ ટોકનના અસ્તિત્વ માટે સંકેત આપે છે, જે પછી તે વપરાશકર્તાની માહિતીની પુષ્ટિ કરે છે અને તેને બદલવાની મંજૂરી આપે છે. પાસવર્ડ

અલબત્ત, ઉપરની પ્રક્રિયા (આસ્થાપૂર્વક) વપરાશકર્તાને નવો પાસવર્ડ બનાવવાની મંજૂરી આપે છે, તેથી અમારે ખાતરી કરવાની જરૂર છે કે URL HTTPS પર લોડ થયેલ છે. ના, તેને HTTPS પર POST વિનંતી સાથે મોકલવું પૂરતું નથી, આ ટોકન URL એ પરિવહન સ્તર સુરક્ષાનો ઉપયોગ કરવો જોઈએ જેથી કરીને નવા પાસવર્ડ ફોર્મ પર હુમલો ન કરી શકાય MITM અને વપરાશકર્તા દ્વારા બનાવેલ પાસવર્ડ સુરક્ષિત કનેક્શન પર પ્રસારિત કરવામાં આવ્યો હતો.

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

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

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

કેપ્ચાની ભૂમિકા

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

અલબત્ત, કેપ્ચા પોતે સંપૂર્ણ નથી; તેના સૉફ્ટવેર "હેકિંગ" અને પર્યાપ્ત સફળતા દર (60-70%) હાંસલ કરવા માટે ઘણા ઉદાહરણો છે. વધુમાં, મારા વિશેની પોસ્ટમાં એક ઉપાય બતાવવામાં આવ્યો છે સ્વચાલિત લોકો દ્વારા કેપ્ચા હેકિંગ, જ્યાં તમે દરેક કેપ્ચા ઉકેલવા માટે લોકોને સેન્ટના અપૂર્ણાંક ચૂકવી શકો છો અને 94%નો સફળતા દર હાંસલ કરી શકો છો. એટલે કે, તે સંવેદનશીલ છે, પરંતુ તે (સહેજ) પ્રવેશમાં અવરોધ ઊભો કરે છે.

ચાલો PayPal ઉદાહરણ પર એક નજર કરીએ:

આ કિસ્સામાં, કેપ્ચા હલ ન થાય ત્યાં સુધી રીસેટ પ્રક્રિયા ફક્ત શરૂ થઈ શકતી નથી, તેથી સૈદ્ધાંતિક રીતે પ્રક્રિયાને સ્વચાલિત કરવી અશક્ય છે. સિદ્ધાંત માં.

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

ગુપ્ત પ્રશ્નો અને જવાબો

અમે ધ્યાનમાં લીધેલ તમામ પદ્ધતિઓ સાથે, અમે ફક્ત ઇમેઇલ એકાઉન્ટની ઍક્સેસ મેળવીને પાસવર્ડ રીસેટ કરવામાં સક્ષમ હતા. હું “માત્ર” કહું છું, પરંતુ, અલબત્ત, કોઈ બીજાના ઈમેલ એકાઉન્ટની ઍક્સેસ મેળવવી ગેરકાયદેસર છે. જ જોઈએ એક જટિલ પ્રક્રિયા છે. જોકે તે હંમેશા આવું નથી.

હકીકતમાં, સારાહ પાલિનના યાહૂના હેકિંગ વિશે ઉપરની લિંક બે હેતુઓ સેવા આપે છે; પ્રથમ, તે દર્શાવે છે કે (કેટલાક) ઈમેલ એકાઉન્ટ હેક કરવું કેટલું સરળ છે, અને બીજું, તે બતાવે છે કે દૂષિત ઉદ્દેશ્ય સાથે કેવી રીતે ખરાબ સુરક્ષા પ્રશ્નોનો ઉપયોગ કરી શકાય છે. પરંતુ અમે પછીથી આ પર પાછા આવીશું.

XNUMX% ઇમેઇલ-આધારિત પાસવર્ડ રીસેટની સમસ્યા એ છે કે તમે જે સાઇટને રીસેટ કરવાનો પ્રયાસ કરી રહ્યાં છો તેના એકાઉન્ટની અખંડિતતા XNUMX% ઇમેઇલ એકાઉન્ટની અખંડિતતા પર આધારિત બની જાય છે. કોઈપણ જેની પાસે તમારા ઇમેઇલની ઍક્સેસ છે કોઈપણ એકાઉન્ટની ઍક્સેસ છે જે ફક્ત ઇમેઇલ પ્રાપ્ત કરીને રીસેટ કરી શકાય છે. આવા એકાઉન્ટ્સ માટે, ઈમેઈલ એ તમારા ઓનલાઈન જીવનના “બધા દરવાજાની ચાવી” છે.

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

સારાહ પાલિન પર પાછા જાઓ: ભૂલ એ હતી કે તેણીના સુરક્ષા પ્રશ્ન/પ્રશ્નોના જવાબો સરળતાથી મળી શકે છે. ખાસ કરીને જ્યારે તમે આટલી નોંધપાત્ર સાર્વજનિક વ્યક્તિ હો, ત્યારે તમારી માતાનું પ્રથમ નામ, શૈક્ષણિક ઈતિહાસ અથવા ભૂતકાળમાં કોઈ વ્યક્તિ ક્યાં રહી હશે તે વિશેની માહિતી એ બધું જ રહસ્ય નથી. વાસ્તવમાં, તેમાંથી મોટા ભાગના લગભગ કોઈને પણ મળી શકે છે. સારાહ સાથે આવું થયું છે:

હેકર ડેવિડ કર્નેલે તેની યુનિવર્સિટી અને જન્મતારીખ જેવી તેની પૃષ્ઠભૂમિ વિશેની વિગતો શોધીને અને પછી Yahoo!ની ભૂલી ગયેલી પાસવર્ડ પુનઃપ્રાપ્તિ સુવિધાનો ઉપયોગ કરીને તેના એકાઉન્ટમાં પ્રવેશ મેળવ્યો.

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

ચાલો સુરક્ષા પ્રશ્નો પર પાછા ફરીએ - વપરાશકર્તાને તેમના પોતાના પ્રશ્નો બનાવવા માટે પરવાનગી આપવા માટે એક વિકલ્પ છે. સમસ્યા એ છે કે આ ભયંકર સ્પષ્ટ પ્રશ્નોમાં પરિણમશે:

આકાશ કયો રંગ છે?

જ્યારે સુરક્ષા પ્રશ્નનો ઉપયોગ ઓળખવા માટે કરવામાં આવે ત્યારે એવા પ્રશ્નો જે લોકોને અસ્વસ્થતા અનુભવે છે વ્યક્તિ (ઉદાહરણ તરીકે, કોલ સેન્ટરમાં):

ક્રિસમસ પર હું કોની સાથે સૂતો હતો?

અથવા પ્રમાણિકપણે મૂર્ખ પ્રશ્નો:

તમે "પાસવર્ડ" કેવી રીતે લખો છો?

જ્યારે સુરક્ષા પ્રશ્નોની વાત આવે છે, ત્યારે વપરાશકર્તાઓને પોતાને બચાવવાની જરૂર છે! બીજા શબ્દોમાં કહીએ તો, સુરક્ષા પ્રશ્ન સાઇટ દ્વારા જ નિર્ધારિત થવો જોઈએ, અથવા હજી વધુ સારું, પૂછવામાં આવ્યું છે શ્રેણી સુરક્ષા પ્રશ્નો જેમાંથી વપરાશકર્તા પસંદ કરી શકે છે. અને તે પસંદ કરવાનું સરળ નથી один; આદર્શ રીતે વપરાશકર્તાએ બે અથવા વધુ સુરક્ષા પ્રશ્નો પસંદ કરવા જોઈએ એકાઉન્ટ રજીસ્ટ્રેશન સમયે, જે પછી બીજી ઓળખ ચેનલ તરીકે ઉપયોગમાં લેવાશે. બહુવિધ પ્રશ્નો રાખવાથી ચકાસણી પ્રક્રિયામાં આત્મવિશ્વાસ વધે છે, અને અવ્યવસ્થિતતા ઉમેરવાની ક્ષમતા પણ પૂરી પાડે છે (હંમેશા એક જ પ્રશ્ન દર્શાવતો નથી), ઉપરાંત વાસ્તવિક વપરાશકર્તા પાસવર્ડ ભૂલી ગયો હોય તેવા કિસ્સામાં થોડી રીડન્ડન્સી પૂરી પાડે છે.

સારો સુરક્ષા પ્રશ્ન શું છે? આ ઘણા પરિબળોથી પ્રભાવિત છે:

1. તેમણે હોવું જ જોઈએ સંક્ષિપ્ત - પ્રશ્ન સ્પષ્ટ અને અસ્પષ્ટ હોવો જોઈએ.
2. જવાબ હોવો જોઈએ ચોક્કસ - અમને એવા પ્રશ્નની જરૂર નથી કે જેનો જવાબ એક વ્યક્તિ અલગ રીતે આપી શકે
3. સંભવિત જવાબો હોવા જોઈએ વિવિધ - કોઈના મનપસંદ રંગને પૂછવાથી સંભવિત જવાબોનો ખૂબ જ નાનો સબસેટ મળે છે
4. Поиск જવાબ જટિલ હોવો જોઈએ - જો જવાબ સરળતાથી મળી શકે કોઈપણ (ઉચ્ચ હોદ્દા પરના લોકોને યાદ રાખો), તો તે ખરાબ છે
5. જવાબ હોવો જોઈએ કાયમી સમયસર - જો તમે કોઈની મનપસંદ મૂવી પૂછો, તો એક વર્ષ પછી જવાબ અલગ હોઈ શકે છે

જેમ જેમ તે થાય છે, ત્યાં સારા પ્રશ્નો પૂછવા માટે સમર્પિત વેબસાઇટ છે જેને કહેવાય છે GoodSecurityQuestions.com. કેટલાક પ્રશ્નો ખૂબ સારા લાગે છે, અન્ય ઉપર વર્ણવેલ કેટલાક પરીક્ષણો પાસ કરતા નથી, ખાસ કરીને "શોધની સરળતા" પરીક્ષણ.

મને દર્શાવવા દો કે કેવી રીતે પેપાલ સુરક્ષા પ્રશ્નોને અમલમાં મૂકે છે અને ખાસ કરીને, સાઇટ પ્રમાણીકરણમાં જે પ્રયત્નો કરે છે. ઉપર અમે પ્રક્રિયા શરૂ કરવા માટેનું પૃષ્ઠ જોયું (કેપ્ચા સાથે), અને અહીં અમે બતાવીશું કે તમે તમારું ઇમેઇલ સરનામું દાખલ કરો અને કેપ્ચા ઉકેલો પછી શું થાય છે:

પરિણામે, વપરાશકર્તાને નીચેનો પત્ર પ્રાપ્ત થાય છે:

અત્યાર સુધી બધું એકદમ સામાન્ય છે, પરંતુ આ રીસેટ URL પાછળ શું છુપાયેલું છે તે અહીં છે:

તેથી, સુરક્ષા પ્રશ્નો રમતમાં આવે છે. વાસ્તવમાં, PayPal તમને તમારા ક્રેડિટ કાર્ડ નંબરની ચકાસણી કરીને તમારો પાસવર્ડ રીસેટ કરવાની પણ પરવાનગી આપે છે, તેથી ત્યાં એક વધારાની ચેનલ છે જેની ઘણી સાઇટ્સની ઍક્સેસ નથી. હું જવાબ આપ્યા વિના મારો પાસવર્ડ બદલી શકતો નથી બંને સુરક્ષા પ્રશ્ન (અથવા કાર્ડ નંબર જાણતા નથી). જો કોઈએ મારો ઈમેલ હાઈજેક કર્યો હોય, તો પણ તેઓ મારા PayPal એકાઉન્ટનો પાસવર્ડ રીસેટ કરી શકશે નહીં સિવાય કે તેઓ મારા વિશે થોડી વધુ વ્યક્તિગત માહિતી જાણતા હોય. કઈ માહિતી? પેપાલ ઑફર કરે છે તે સુરક્ષા પ્રશ્ન વિકલ્પો અહીં છે:

શોધની સરળતાના સંદર્ભમાં શાળા અને હોસ્પિટલનો પ્રશ્ન થોડો અસ્પષ્ટ હોઈ શકે છે, પરંતુ અન્ય બહુ ખરાબ નથી. જો કે, સુરક્ષા વધારવા માટે, PayPal ને વધારાની ઓળખની જરૂર છે ફેરફાર સુરક્ષા પ્રશ્નોના જવાબો:

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

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

પછી મેં એક સ્ક્રીન જોયું જ્યાં હું સુરક્ષા પ્રશ્નો અને જવાબોની કેટલીક જોડી તેમજ બચાવ ઈમેલ સરનામું પસંદ કરી શકું છું:

પેપાલ માટે, પ્રશ્નો પૂર્વ-પસંદ કરેલા છે અને તેમાંથી કેટલાક ખરેખર ખૂબ સારા છે:

ત્રણમાંથી દરેક પ્રશ્ન/જવાબની જોડી સંભવિત પ્રશ્નોના અલગ-અલગ સમૂહને રજૂ કરે છે, તેથી એકાઉન્ટને ગોઠવવાની ઘણી બધી રીતો છે.

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

સુરક્ષા પ્રશ્નો અને જવાબોનું એક અંતિમ પાસું એ છે કે તેઓ સામાજિક ઇજનેરી માટે વધુ સંવેદનશીલ છે. કોઈ બીજાના ખાતામાં પાસવર્ડને સીધો કાઢવાનો પ્રયાસ કરવો એ એક બાબત છે, પરંતુ તેની રચના વિશે વાતચીત શરૂ કરવી (એક લોકપ્રિય સુરક્ષા પ્રશ્ન) સંપૂર્ણપણે અલગ છે. વાસ્તવમાં, તમે કોઈ વ્યક્તિ સાથે તેમના જીવનના ઘણા પાસાઓ વિશે ખૂબ સારી રીતે વાતચીત કરી શકો છો જે શંકાને ઉત્તેજિત કર્યા વિના ગુપ્ત પ્રશ્ન ઉભો કરી શકે છે. અલબત્ત, સુરક્ષા પ્રશ્નનો ખૂબ જ મુદ્દો એ છે કે તે કોઈના જીવનના અનુભવ સાથે સંબંધિત છે, તેથી તે યાદગાર છે, અને તે જ સમસ્યા છે - લોકો તેમના જીવનના અનુભવો વિશે વાત કરવાનું પસંદ કરે છે! તમે આ વિશે થોડું કરી શકો છો, જો તમે આવા સુરક્ષા પ્રશ્ન વિકલ્પો પસંદ કરો છો જેથી તે છે ઓછું કદાચ સામાજિક ઇજનેરી દ્વારા ખેંચી શકાય છે.

[ચાલુ રહી શકાય.]

જાહેરાતના અધિકારો પર

વીડીસીના વિશ્વસનીય ઓફર કરે છે દૈનિક ચુકવણી સાથે સર્વર્સ, દરેક સર્વર 500 Megabits ની ઇન્ટરનેટ ચેનલ સાથે જોડાયેલ છે અને DDoS હુમલાઓથી મફતમાં સુરક્ષિત છે!

સોર્સ: www.habr.com