ჯერ EAP მეთოდი: რომელი პაროლის ჰეში შეიძლება გამოიყენოს VPN-მა
VPN საიდუმლოს ამოწმებს და არა ვებ ჰეშს. წაიკითხეთ მეთოდი, შემდეგ შეამოწმეთ რა ინახება საცავში, სანამ დაპირდებით, რომ იგივე პაროლები გააგრძელებს მუშაობას.
ბევრ გუნდს აქვს მომუშავე ვებ შესვლა და VPN, რომელიც უარყოფს იმავე ცხრილიდან მოსულ ყველა პაროლს. ვებ აპლიკაცია ადარებს თავის მიერ გამოთვლილ ჰეშს, ხოლო გვირაბი კლიენტს სთხოვს დაამტკიცოს საიდუმლოს ფლობა ისე, რომ სერვერმა უნდა შეძლოს მისი შემოწმება. ეს სხვადასხვა მოთხოვნაა შენახულ მასალაზე. სწორედ ამ ორას შორის არსებულ ნაპრალში ჩერდება ასეთი პროექტების უმეტესობა.
ჯერ მეთოდი, შემდეგ სქემა
ჩაწერეთ რა მტკიცებულებას მოითხოვს არჩეული მეთოდი, სანამ რომელიმე სქემას შეხედავთ. გამოწვევა-პასუხის მეთოდს სჭირდება მასალა, საიდანაც სერვერს შეუძლია მოსალოდნელი პასუხის გამოთვლა, რაც პრაქტიკაში ნიშნავს პაროლს ან თავსებად წარმოებულ ფორმას. მეთოდს, რომელიც პაროლს დაცულ გვირაბში ატარებს, სჭირდება თავად პაროლი გამმოწმებელთან. წაიკითხეთ მეთოდის დოკუმენტაცია გამმოწმებელის მოთხოვნისთვის და არა კლიენტის კონფიგურაციისთვის, რადგან კლიენტის მოთხოვნები ჩვეულებრივ მარტივი ნაწილია.
თანამედროვე ვებ ჩარჩოს მიერ შექმნილი მარილიანი ჰეში არც ერთს არ იძლევა. ის ამოწმებს ერთ კონკრეტულ შედარებას და ვერ დაბრუნდება იმ საიდუმლოში, საიდანაც წარმოიშვა.
გამოწვევა-პასუხი ვერ გამოიყენებს მარილიან ჰეშს
MSCHAPv2 გამოწვევა-პასუხის გაცვლაა, ამიტომ სერვერი არასოდეს იღებს პაროლს და ვერ ადარებს შენახულ სტრიქონს. მან მოსალოდნელი პასუხი უნდა გამოიღოს უკვე არსებული მასალიდან, და ამიტომ არის თავსებადი შენახული ფორმები ასე ვიწრო. bcrypt ან Argon2 მნიშვნელობა მომხმარებლისეული მარილით ერთმიმართულებიანია ისე, რომ გაცვლას სრულად გამორიცხავს. ქვემოთ მოცემული ცხრილი შენახვის ფორმიდან იწყება და არა მეთოდის სახელიდან, რადგან სწორედ შენახვის ფორმა წყვეტს პასუხს.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
SQL დანამატის დოკუმენტაცია strongSwan-ისთვის განსაზღვრავს საკუთარ სქემას კონფიგურაციისა და სერტიფიკატებისთვის, და პროექტი კვლავ ექსპერიმენტულად აღნიშნავს ამ დანამატს. მასში არაფერი ერგება აპლიკაციის მომხმარებლების ცხრილს და არც ვარაუდობს, რომელმა ჰეშირების სქემამ შექმნა შენახული მნიშვნელობა. ამიტომ რეალური ვარიანტებია გადასვლა საცავზე, რომლის გამოყენებაც კარიბჭეს შეუძლია, ან აუთენტიფიკაციის სერვისი არსებული საცავის წინ, რომელსაც გაცვლის შესრულება შეუძლია. ყველაფერი დანარჩენი კონექტორია ფარული დაშვებით შიგნით.
RADIUS სამუშაოს გადაადგილებს და არა მოთხოვნას
EAP-ის RADIUS სერვერზე დელეგირება ცვლის სად ხდება შემოწმება და ჩვეულებრივ აუმჯობესებს აუდიტის კვალს. ის არ აღადგენს პაროლს ერთმიმართულებიანი ჰეშიდან, ამიტომ აუთენტიფიკაციის სერვისს კვლავ სჭირდება მასალა, რომელიც თავსებადია იმ მეთოდთან, რომელსაც ამთავრებს. გუნდები ამას იგებენ მას შემდეგ, რაც ააშენებენ RADIUS გზას და მეორე ბოლოში იმავე კედელს წააწყდებიან.
სადაც RADIUS სერვერს შეუძლია წაიკითხოს კატალოგი თავსებადი სერტიფიკატით, იქ გადაწყვეტა მუშაობს და VPN კარიბჭე მარტივი რჩება. სადაც არ შეუძლია, პატიოსანი პასუხი რეგისტრაციის ცვლილებაა და არა კიდევ ერთი კონექტორი. მიწოდება და გაუქმება ეკუთვნის მას, ვინც იდენტობას ფლობს, ამიტომ დაკოპირებული ცხრილი მხარდაჭერილი სინქრონიზაციის პროცესის გარეშე სერტიფიკატების მეორე სასიცოცხლო ციკლია და არა ერთიანი შესვლა. ის იშლება პირველივე ჯერზე, როცა ვინმე პაროლს მხოლოდ ერთ ადგილას აღადგენს, და ეს გაშლა ჩუმად გრძელდება მანამ, სანამ ორივე სისტემაში არსებული ანგარიში თითოეულში სხვადასხვა რამეს არ მოიქცევა.
შეზღუდეთ კატალოგის მკითხველი ანგარიში მხოლოდ ამ კითხვით და დააშორეთ იმ ანგარიშს, რომელსაც კარიბჭე საკუთარი კონფიგურაციისთვის იყენებს. საერთო ადმინისტრაციული ანგარიში მხოლოდ-კითხვით გადაწყვეტას გაცილებით ფართო ზემოქმედების რადიუსად აქცევს.
სად უნდა იცხოვროს ანგარიშმა
მასალის საკითხის გადაწყვეტის შემდეგ ორი არქიტექტურა რჩება. კარიბჭეს შეიძლება ჰქონდეს სერტიფიკატების პატარა საცავი, რომელსაც მხოლოდ ის კითხულობს, ან გადააბაროს აუთენტიფიკაციის სერვისს, რომელიც კორპორატიული კატალოგის წინ დგას.
პირველი უფრო ადვილი გასააზრებელია და უარესია მომხმარებლისთვის, რომელსაც მეორე პაროლი რჩება სარემონტოდ. მეორე ინარჩუნებს ერთ იდენტობას და ამატებს დამოკიდებულებას სერვისზე, რომელიც ახლა უნდა მუშაობდეს მანამ, სანამ ვინმე დაუკავშირდება. არც ერთი არ არის მცდარი, მაგრამ არჩევანი კარიბჭის კონფიგურაციის გვერდით უნდა ჩაიწეროს, თორემ შემდეგი ინჟინერი ჩათვლის, რომ მეორე აირჩიეს. რაც არ უნდა აირჩიოთ, ქვემოთ მოცემული ორი ბრძანებაა ის, რაც მიმდინარე მდგომარეობას აჩვენებს შეცვლამდე.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsანგარიშის აუთენტიფიკაცია ავტორიზაციასაც არ წყვეტს. ჯგუფური წევრობა, მოწყობილობის მდგომარეობა და ქსელის ნებართვა კვლავ მოითხოვს ცხად დაკავშირებას მას შემდეგ, რაც მომხმარებელმა საჭირო იდენტობა დაამტკიცა. კავშირი, რომელიც სრულყოფილად აუთენტიფიცირდება და არაფერს ავტორიზებს, პოლიტიკის შედეგია და არა მეთოდის ხარვეზი.