პაროლის ელფოსტა ადასტურებს შექცევადობას და არა სქემას

სერვისმა, რომელიც მომხმარებლის მიმდინარე პაროლს ელფოსტით აგზავნის, ერთი რამ დაამტკიცა: მას შეუძლია ამ საიდუმლოს მიღება იმ ფორმით, რომლის გაგზავნაც შეუძლია. მას არ დაუმტკიცებია, რომელი სვეტი, ალგორითმი თუ ბიბლიოთეკა ქმნის მას. განსხვავება მნიშვნელოვანია, რადგან აღმოჩენა რეალურია და დასკვნა, რომელსაც ადამიანები მისგან აკეთებენ, ჩვეულებრივ ზედმეტად კონკრეტულია. გზაზე სადღაც შექცევადობა არის მექანიზმი; ნაგულისხმევი შენახვის ფორმატი არა.

შეინახეთ მტკიცებულება ამ დონეზე და მიმოხილვის დარჩენილი ნაწილი ზუსტი დარჩება.

რას ადასტურებს ძველი საიდუმლოს დაბრუნება

ერთმხრივი გადამოწმება ვერ შექმნის საწყის პაროლს, რადგან ის შექმნილია ისე, რომ შეუქცევადი იყოს. თუ სერვისს შეუძლია პაროლის ელფოსტით გაგზავნა, მაშინ იმ მომენტში ის ინახავს მასალას, საიდანაც პაროლის აღდგენა შესაძლებელია, ან ის ჩაიჭერს და ინახავს ღია ტექსტს ჰეშირებამდე. ორივე შემთხვევაში აღდგენის გზა შექცევადია და ეს ნამდვილი უსაფრთხოების აღმოჩენაა. ის არაფერს ამბობს იმაზე, იყენებს თუ არა იგივე მონაცემთა ბაზა ძვირ ჰეშს სხვა სვეტებისთვის.

ყურადღება მიაქციეთ შუალედურ შემთხვევასაც: აპლიკაციის ხელში არსებული გასაღებით შენახული დაშიფრული ბლობი პრაქტიკაში შექცევადია, თუმცა სიტყვა დაშიფრული ანგარიშში დამამშვიდებლად ჟღერს.

რატომ არის ეს დიზაინის აღმოჩენა და არა შენახვის რუკა

ელფოსტა ადასტურებს აღდგენადობას და არ იდენტიფიცირებს ზუსტ სქემას. ეს შეიძლება იყოს ღია ტექსტი, დეტერმინისტული დაშიფვრა, მომწოდებლის დაბინდვის რუტინა ან ცალკე რწმუნებების საცავი, რომელიც მხოლოდ აღდგენისთვის გამოიყენება. პროდუქტის სხვადასხვა ნაწილი ხშირად სხვადასხვა შენახვას იყენებს. ერთი ელფოსტის საფუძველზე ალგორითმის მიკუთვნება იმ ტიპის მტკიცებაა, რომელიც შემდეგ შეხვედრაზე ინგრევა.

რისი თქმაც შეგიძლიათ, უფრო ვიწრო და უფრო სასარგებლოა: ამ გზას შეუძლია საიდუმლოს აღდგენა, ამიტომ პროდუქტი ვერ ამტკიცებს, რომ აღდგენადი რწმუნებები არ არსებობს. ყველაფერი ამის მიღმა ოპერატორის მტკიცებულებას საჭიროებს.

ააგეთ განულება ავტორიზაციის გარშემო

განულება სხვა პრობლემას წყვეტს: ამტკიცოს, რომ მომთხოვნს შეუძლია აირჩიოს ახალი პაროლი. OWASP-ის სახელმძღვანელო ამის შესახებ აღწერს უსაფრთხოდ გენერირებულ, ერთჯერად ტოკენებს ან კოდებს შესაბამისი ვადის გასვლით, და მოთხოვნის ეტაპს განიხილავს როგორც რაღაცას, რაც უნდა დავიცვათ ჩამოთვლისა და წყალდიდობისგან. არაავთენტიფიცირებული მოთხოვნა თავისით არ უნდა შეცვალოს ანგარიში. ნებართვა გადაამოწმეთ ჩანაცვლების მიღებამდე და ტოკენი ერთი წარმატებული გამოყენების შემდეგ უმოქმედო გახადეთ.

ელფოსტის არხი უსაფრთხოების მოდელის ნაწილია. ანგარიშის სახელის ფლობა არაფერს ამტკიცებს და განულების ის ნაკადი, რომელიც ამხელს, არსებობს თუ არა ანგარიში, თავდამსხმელს სამუშაოდ გზამკვლევს აძლევს.

გააუქმეთ ის, რასაც პაროლი იცავდა

პაროლის შეცვლა ავტომატურად არ ამთავრებს იმ წვდომას, რომელსაც ის იძლეოდა. აქტიურ VPN სესიებს, დამახსოვრებულ მოწყობილობებს და სერვერის მიერ გაცემულ ტოკენებს შეიძლება ჰქონდეს გაუქმების საკუთარი ქცევა. განზრახ გადაწყვიტეთ, რომელი მათგანი უნდა დასრულდეს, და შეამოწმეთ, რომ იმპლემენტაცია ამას აკეთებს, რადგან მომხმარებელი, რომელიც ფიქრობს, რომ განულებამ ყველგან გაათიშა, ხშირად ცდება. ჩაწერეთ ეს გადაწყვეტილება ნაკადთან ერთად.

ოპერატორებისთვის: დაადგინეთ დოკუმენტურად, რომელი კომპონენტი ამოწმებს მოთხოვნას, რომელი ცვლის რწმუნებას და როგორ მუშავდება დაკავშირებული სესიები. მომხმარებლებისთვის: დაიცავით ლეგიტიმური აღდგენის არხი და პაროლის დამაბრუნებელი ნებისმიერი შეტყობინება საეჭვოდ მიიჩნიეთ.

ზუსტი შეფასება მოკლეა: რას ამტკიცებს შეტყობინება, რა რჩება უცნობი და ცვლის თუ არა აღდგენა წვდომას კონტროლირებული პროცესით.