Şifre Maskeleme: Ne Zaman Koruma, Ne Zaman Engel

Şifre alanındaki noktalar tek bir şeye karşı işe yarar: ekranınıza bakan birine karşı. Ağdaki trafiği, tuş kaydediciyi, sunucudaki sızıntıyı ilgilendirmez. Buna rağmen maskeleme, böyle bir bakışın olmadığı ortamlarda da açık kalır ve kullanıcının yazım hatasını görmesini imkânsızlaştırır. Asıl soru maskelemenin kalkıp kalkmayacağı değil, kontrolün kimde olduğu.

Maskelemenin kapattığı risk dar

Tehdit modeli net: omuz üstünden bakan biri. Kafede, açık ofiste, uçakta, bir de ekran paylaşımı sırasında. Ekran paylaşımı bugün listenin en gerçekçi maddesi, çünkü kullanıcı orada tek başına olduğunu sanır ve karşısında kaydedilen bir toplantı vardır.

Jakob Nielsen 2009'da maskelemenin tümden kaldırılmasını önerdi. Öneri olduğu gibi uygulanmadı, ama arayüzleri göster/gizle düğmesine taşıyan tartışmayı o başlattı. Bugünkü denge de orada: maskeleme kalır, kaldırma yetkisi kullanıcıya geçer.

Maskelemenin kullanıcıyı basit şifreye ittiği iddiası ise farklı bir kategoride. Mantıklı görünüyor, çok tekrarlanıyor, sağlam bir ölçümle desteklendiğini görmedim (bu iddiayı fazla rahat tekrarlanmış buluyorum). Dahası kendi içinde çelişiyor: şifre yöneticisi kullanan biri zaten hiçbir şey yazmıyor, dolayısıyla maskeleme onun şifre seçimini etkilemiyor.

Varsayılan maskeli, kontrol kullanıcıda

Alan maskeli açılır. Göz simgesi ya da "Göster" metni alanın yanında, görünür şekilde durur. Kullanıcı bastığında şifre açılır, form gönderildiğinde veya kullanıcı başka bir alana geçtiğinde tekrar kapanır. Açık kalan bir şifre alanı, kullanıcının unuttuğu bir durumdur.

Mobilde son karakteri kısa süre gösteren davranış (Android ve iOS klavyelerinin varsayılanı) çoğu durumda yeterli. Yazarken hatayı anında yakalarsınız, ekranda bütün şifre hiç durmaz. Uzun ve karmaşık şifrelerde yine de tam görünürlük gerekir, o yüzden düğmeyi mobilde de koyun.

Düğmenin kodda karşılığı

Göster/gizle pratikte type="password" ile type="text" arasında geçiş yapar. Sorun şurada: alan artık sıradan bir metin alanıdır ve tarayıcıyla klavye ona göre davranır.

• Mobil klavye ilk harfi büyütür, otomatik düzeltme devreye girer. autocapitalize="none" autocorrect="off" eklenmezse kullanıcı yazmadığı bir şifreyi göndermeye çalışır.
• spellcheck="false" yazın. 2022'de tarayıcıların gelişmiş yazım denetimi özelliğinin, görünür hale getirilmiş şifre alanlarının içeriğini sunucuya gönderdiği raporlandı. Denetimi kapatmak üç karakterlik bir iş, atlanması pahalı.
• Tür değiştiğinde imleç konumu kayabilir; setSelectionRange ile geri koymazsanız kullanıcı kaldığı yeri kaybeder.
• Düğme gerçek bir button olsun ve type="button" taşısın. Aksi halde forma gömülü düğme, Enter'a basıldığında ya da tıklandığında formu gönderir.
• Ekran okuyucu için durumu aria-pressed ile bildirin, etiketi "göz" değil "Şifreyi göster" yapın.

Bu maddelerin hiçbiri tasarım kararı değil, hepsi uygulama borcu. Göster/gizle düğmesini makete koymak beş dakika, tarayıcı davranışlarını doğru kapatmak bir öğleden sonra.

Asıl zarar yapıştırmayı engellemekte

Şifre alanında paste olayını iptal eden siteler hâlâ var. Bu, maskelemeden çok daha somut bir zarar: şifre yöneticisini kullanılamaz hale getirir, yani kullanıcıyı elle yazabileceği kadar kısa ve akılda kalır bir şifreye zorlar. İngiltere'nin siber güvenlik kurumu NCSC bunu yıllar önce açıkça yazdı: bırakın yapıştırsınlar.

Sıralama şöyle: önce yapıştırma engelini kaldırın, sonra göster/gizle düğmesini ekleyin, en sonunda maskelemenin varsayılanını tartışın. İlk madde beş dakikalık bir silme işlemi ve üçünün içinde güvenliğe en çok katkıyı o yapar.