Önce EAP yöntemi: VPN hangi parola karmasını kullanabilir
VPN gizli değeri doğrular, web karmasını değil. Yöntemi okuyun, sonra aynı parolaların çalışmaya devam edeceğini vaat etmeden önce deponun ne tuttuğunu denetleyin.
Birçok ekibin çalışan bir web oturum açması ve aynı tablodan gelen her parolayı reddeden bir VPN'i vardır. Web uygulaması kendi hesapladığı karmayı karşılaştırırken tünel, istemciden bir sırrın sahipliğini sunucunun denetleyebileceği biçimde kanıtlamasını ister. Bunlar saklanan malzeme üzerinde farklı gereksinimlerdir. Bu projelerin çoğu tam da ikisi arasındaki boşlukta tıkanır.
Önce yöntem, sonra şema
Herhangi bir şemaya bakmadan önce seçilen yöntemin hangi kanıtı istediğini yazın. Bir meydan okuma-yanıt yöntemi, sunucunun beklenen yanıtı hesaplayabileceği malzemeye ihtiyaç duyar; bu da pratikte parolanın kendisi ya da uyumlu türetilmiş bir biçim demektir. Parolayı korumalı bir tünelin içinde taşıyan yöntem ise doğrulayıcıda parolanın kendisine ihtiyaç duyar. Yöntem belgelerini istemci yapılandırması için değil, doğrulayıcı gereksinimi için okuyun, çünkü istemci gereksinimleri genellikle kolay kısımdır.
Modern bir web çerçevesinin ürettiği tuzlu karma ikisini de sağlamaz. Tek bir belirli karşılaştırmayı doğrular ve geldiği sırra geri döndürülemez.
Meydan okuma-yanıt tuzlu karma kullanamaz
MSCHAPv2 bir meydan okuma-yanıt alışverişidir, bu yüzden sunucu parolayı hiçbir zaman almaz ve saklanan bir dizeyi karşılaştıramaz. Beklenen yanıtı zaten sahip olduğu malzemeden türetmek zorundadır; uyumlu saklanan biçimlerin bu kadar dar olmasının nedeni budur. Kullanıcı başına tuzlu bir bcrypt veya Argon2 değeri, alışverişi tamamen dışlayacak biçimde tek yönlüdür. Aşağıdaki tablo yöntem adından değil saklama biçiminden başlar, çünkü yanıtı belirleyen saklama biçimidir.
| 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 |
strongSwan için SQL eklentisi belgeleri yapılandırma ve kimlik bilgileri için kendi şemasını tanımlar ve proje bu eklentiyi hâlâ deneysel olarak işaretler. Belgede hiçbir şey bir uygulamanın kullanıcı tablosuna uyum sağlamaz ya da saklanan bir değeri hangi karma düzeninin ürettiğini tahmin etmez. Bu yüzden gerçekçi seçenekler, ağ geçidinin kullanabileceği bir depoya geçiş ya da mevcut deponun önünde alışverişi yapabilecek bir kimlik doğrulama hizmetidir. Bunun dışındaki her şey, içinde gizli bir varsayım taşıyan bir bağlayıcıdır.
RADIUS işi taşır, gereksinimi taşımaz
EAP'yi bir RADIUS sunucusuna devretmek doğrulamanın yerini değiştirir ve genellikle denetim izini iyileştirir. Tek yönlü bir karmadan parola geri kazanmaz, bu yüzden kimlik doğrulama hizmeti yine de sonlandırdığı yöntemle uyumlu malzemeye ihtiyaç duyar. Ekipler bunu RADIUS yolunu kurup öbür uçta aynı duvarla karşılaştıktan sonra öğrenir.
RADIUS sunucusunun uyumlu kimlik bilgisi tutan bir dizini okuyabildiği yerde tasarım çalışır ve VPN ağ geçidi sade kalır. Okuyamadığı yerde dürüst yanıt bir bağlayıcı daha değil, kayıt değişikliğidir. Sağlama ve iptal, kimliğe sahip olana aittir; bu yüzden desteklenen bir eşitleme süreci olmadan kopyalanan tablo, tek oturum açma değil ikinci bir kimlik bilgisi yaşam döngüsüdür. Biri yalnızca tek bir yerde parola sıfırladığında ilk kez kayar ve bu kayma, iki sistemde de bulunan bir hesap her birinde farklı davranana kadar sessiz kalır.
Dizini okuyan hesabı yalnızca o okumayla sınırlayın ve ağ geçidinin kendi yapılandırması için kullandığı hesaptan ayrı tutun. Paylaşılan bir yönetici hesabı, salt okunur bir tasarımı çok daha geniş bir etki yarıçapına dönüştürür.
Hesap nerede yaşamalı
Malzeme sorusu çözüldüğünde iki mimari kalır. Ağ geçidi yalnızca kendisinin okuduğu küçük bir kimlik bilgisi deposuna sahip olabilir ya da kurumsal dizinin önünde duran bir kimlik doğrulama hizmetine devredebilir.
Birincisini düşünmek daha kolaydır ve kullanıcı için daha kötüdür, çünkü ona bakımı yapılacak ikinci bir parola kalır. İkincisi tek bir kimliği korur ve artık birinin bağlanabilmesi için çalışır durumda olması gereken bir hizmete bağımlılık ekler. İkisi de yanlış değildir, ancak seçim ağ geçidi yapılandırmasının yanına kaydedilmelidir, yoksa sonraki mühendis diğerinin seçildiğini varsayar. Hangisini seçerseniz seçin, aşağıdaki iki komut değiştirmeden önceki mevcut durumu gösterenlerdir.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsHesap kimlik doğrulaması yetkilendirmeyi de çözmez. Grup üyeliği, cihaz durumu ve ağ izni, kullanıcı gereken kimliği kanıtladıktan sonra hâlâ açık bir eşleme gerektirir. Kusursuz kimlik doğrulayıp hiçbir şeye yetki vermeyen bir bağlantı bir ilke sonucudur, yöntemdeki bir hata değildir.