Web sitelerinde şifreler söz konusu olduğunda çok fazla aptallık var .
- Bazılarının sadece teknik nedenleri vardır (geçerli ya da değil, bu başka bir soru, ancak neredeyse hepsi değil):
Parolanız dört karakter uzunluğunda olmalı ve yalnızca rakam içermelidir.
(Bir parolayı 0001 .. 9999 aralığıyla sınırlandırarak, bunları veritabanında sayı, düz metin olarak saklayabilirsiniz)
- Diğerleri, şifreleri daha güvenli hale getirecekleri bazı yanlış düşüncelerle açıklanmaktadır :
Parolanız büyük harfle başlamalı ve bir rakamla bitmelidir.
(Geliştirici veya yöneticisi Bunu yaparak, farz bu , aslında güvenli bir şifre seçin kullanmaya zorlayabilir olurken Parolanız en az bir büyük harf, küçük harf ve a. 6 karakter min içeren ve içermelidir" olarak kural haneli "sihirli bir şekilde bunu yapamaz)
- Diğer, son olarak, parolaların düz metin olarak saklanması ve bunların nasıl saklandığı, işlendiği veya alındığı konusunda bazı belirsizlikler olduğu ve bunları test etmek için zaman olmadığı açıklanmaktadır.
Parolanız geçersiz bir karakter içeriyor é.
veya,
Şifreniz y$₯46¥*A'xD<7&฿=ᴙcN&sF5_Ở!dbazı geçersiz karakterler içeriyor. Yalnızca Latin alfabesindeki karakterleri ve rakamları kullanın.
veya,
Parolanız boşluk karakterleri içeremez.
Her üç durumda da, geliştirici böyle şifrelerin doğru bir şekilde saklanacağından emin olmuştur.
İlk durumda, gönderildiğinde édönüştürülürse ne olur %C3%A9? Ya da veritabanı éyanlış depolanırsa ?
İkinci durumda, PHP (neden PHP?) Unicode ile başa çıkamazsa ve böyle bir şifre alırken korkunç bir şey yaparsa ne olur? <Karakter sorun yaratırsa ne olur? Ya &karakteri bir URL'de ayırıcı olarak yorumlanır (nedense, şifre POST yerine GET yoluyla gönderildiğini varsayarak)? Ya 'veritabanı tarafından yorumlanırsa, çünkü tahmin edin, SQL Injection'ın ne olduğu ve nasıl önleneceği hakkında hiçbir fikrimiz yok? Ya 'dönüştürülürse ne olacak \'?
Üçüncü durumda, PHP (tekrar?) Bazı durumlarda boşlukları keser , bazılarında ise? Kullanıcı (birbirini izleyen üç boşluk alanı ayarlamışken ) yöneticiler (düz metin olarak kullanıcı parolalarına şaşırtıcı bir şekilde erişimi olan) kaybolursa , yalnızca bir boşluk görüyorlarsa ne olur ?
Her üç durumda da, bu belirsizlikler testlerle , özellikle birim testlerle kolayca çözülebilir . Ancak çok sayıda projede, hiçbir test ve test edilecek zaman yok (ancak daha sonra hata ayıklamak için hala bol zaman).
Bu, geliştiricinin boşluklara veya unicode karakterlere izin vermenin olası sonuçlarını veya sadece ASCII 48..57 ∪ 65..90 ∪ 97..122 dışındaki herhangi bir karakteri (rakamlar, küçük harfler, büyük harfler) düşünmeye çalışıp çalışmadığı anlamına gelir. , test yapmanın mümkün olmadığı en kolay yol, onları yasaklamaktır .
Bence boşlukları yasaklamak için tek sebep bu. Yannis Rizos, UX ile ilgili başka bir neden daha verdi. Teoride mantıklı bir neden olsa da, uygulamada hiç işe yaramaz: UX'u gerçekten önemseyen kişiler tarafından yapılan web siteleri aptal şifre kurallarını düzeltmez. Bunun yerine, beyaz alanın gerçekten yasak olduğu web siteleri çoğunlukla UX hakkında hiç duymamış kişiler tarafından yapılır . Bu özellikle doğrudur, çünkü herhangi bir karakterin UX açısından gerçekten can sıkıcı olması, faydalı karakterler de dahil olmak üzere şifre ile ilgili herhangi bir kısıtlamanın minimum karakter sayısı olarak gerçekten can sıkıcı olmasıdır.