Parola Formunda Kural Yığmak Yerine Uzunluğa Güvenmek

Parola alanı, kayıt formunun en çok terk edilen yeri. Suç genelde kullanıcıya ya da "kuralları yeterince net göstermedik" diye arayüz metnine yıkılır. Oysa çoğu formda asıl sorun kuralların sunumunda değil, kuralların kendisinde: büyük harf, rakam ve sembol zorunluluğu güvenliği artırdığı varsayımıyla konur ve bu varsayım hem matematiksel olarak hem sahada zayıf.

Zorunlu karakter sınıfları arama uzayını büyütmez

Sekiz karakterlik bir parola düşünün. Yazdırılabilir ASCII kümesi 95 karakter, olası dizi sayısı 95^8, kabaca 6,6 katrilyon. "En az bir büyük harf, bir rakam, bir sembol" şartını koyduğunuz anda bu kümenin tamamı değil, şartı sağlayan alt kümesi geçerli kalır. Kural, saldırganın taraması gereken uzayı büyütmez; küçültür. Küçülme oranı tek başına felaket değil ama yön yanlış ve bu ters yön nadiren dile getirilir.

Asıl kayıp insan tarafında yaşanır. Kullanıcı zorunluluğu en ucuz yoldan karşılar: ilk harfi büyütür, sonuna bir rakam ve bir ünlem ekler. Ortaya çıkan kalıplar saldırı sözlüklerinin ilk sıralarındadır, çünkü herkes aynı ucuz yoldan geçer.

Karşılaştırın: yalnızca küçük harften oluşan 16 karakterlik bir parolanın uzayı 26^16, yani 4,4 x 10^22 dizi. Sembol zorunlu sekiz karakterlik uzaydan yaklaşık altı milyon kat büyük. Uzunluk karmaşıklığı her seferinde yener. NIST SP 800-63B de 2017'den bu yana kompozisyon kurallarını ve zorunlu periyodik değiştirmeyi önermiyor; istediği şey makul bir alt sınır, 64 karaktere kadar izin ve sızmış parolaların engellenmesi.

Kuralı iyi göstermek, kötü kuralı düzeltmez

"Gereksinimleri baştan göster" tavsiyesi doğrudur, kullanıcının hata mesajıyla öğrenmesi kötüdür. Ama bu ikincil bir düzeltme. Beş maddelik canlı kontrol listesi tasarlarken sorulacak ilk soru "bunu nasıl daha okunur gösteririm" değil, "bu beş maddenin kaçı gerçekten gerekli".

Kural kalacaksa kuralı şu şekilde kur: alanın altında sabit dursun, ipucu balonunun ardına saklanmasın, kullanıcı yazarken madde madde işaretlensin. Sunum tarafında yapılacak iş bu kadar.

Bir de sessiz üst sınır meselesi var. Formunuz 16 karakterde kesiyorsa parola yöneticisi kullanan, yani en güvenli davranan kullanıcıyı cezalandırıyorsunuz demektir. Üst sınır olacaksa 64 civarında olsun ve maxlength ile sessizce kırpmak yerine açıkça söylensin.

Görünürlük evet, yapıştırma engeli asla

Göz simgesiyle parolayı görünür kılmak hatayı düşürür, özellikle mobil klavyede. Ancak mobilde parolayı varsayılan olarak görünür yapma tavsiyesine katılmıyorum: telefon çoğunlukla kişisel ortamda değil, otobüste ve ofiste açılır, omuz üstünden okunması masaüstünden kolaydır. Varsayılan gizli kalsın, geçiş tek dokunuş olsun.

Yapıştırmayı engellemek ise doğrudan zarar. Bir projede parola alanında onpaste ile yapıştırmayı bloke eden bir kayıt formu devraldım; o tek satırı silmek, aynı formda yaptığım bütün mikro kopya iyileştirmelerinden daha çok işe yaradı. Aynı şekilde autocomplete="new-password" ve autocomplete="current-password" değerlerini doğru yerlere koymak, kullanıcının yöneticisine güvenmesi anlamına gelir.

Güç ölçer neyi ölçüyor

Güç ölçerlerin kullanıcıyı daha iyi parolaya yönlendirdiği doğru, ama bu yalnızca ölçer doğru şeyi ödüllendiriyorsa geçerli. Sahadaki ölçerlerin çoğu karakter sınıfı sayar. Böyle bir ölçerde herkesin tahmin edebileceği sekiz karakterlik klasik kalıp yeşile döner, uzun ama tamamen küçük harften oluşan bir cümle turuncuda kalır. Kullanıcıya yanlış bilgi veren bir bar, hiç bar olmamasından kötüdür.

Ölçüm yapacaksanız sözlük kelimelerini, klavye dizilerini, tarihleri ve harf yerine sembol ikamesini tanıyan bir tahmin motoru kullanın; zxcvbn ve türevleri bu işi yıllardır yapıyor. Oyunlaştırma tarafında da dikkat: barı doldurma isteği yanlış metrikle birleşirse, kullanıcıyı uzun parola yerine sonuna sembol eklemeye iter.

Formun dışında kalan kısım

Parola alanının kalitesini tek başına arayüz belirlemiyor. Girilen parolayı bilinen sızıntı listesine karşı kontrol etmek, on maddelik kural listesinden daha fazla güvenlik üretir; Pwned Passwords servisi bunu k-anonymity ile yapar, yani parolanın SHA-1 özetinin yalnızca ilk beş hanesi gönderilir, tam parola sunucudan çıkmaz. Kayıt anında bu kontrolü koyduğunuzda geri kalan kuralların çoğunu rahatça kaldırabilirsiniz.

İkinci faktörü de bu tabloya ekleyin. Parolayı zorlaştırarak elde edeceğiniz kazanç sınırlı; hesaba ikinci bir kapı koymak kimlik avı dışındaki senaryoların neredeyse tamamını kapatır. Kısacası: kısıtı azaltın, uzunluğu serbest bırakın, sızıntı kontrolü ekleyin, ikinci faktörü açın. Kullanıcının formda geçirdiği süre kısalırken hesabın güvenliği artar, çünkü ikisi hiçbir zaman birbirinin zıddı değildi.