Bu durumda suçlu, şifrelerinde özel karakterlere (herhangi bir tür) izin vermeyen belirli (ve özellikle büyük) bir bankadır: Sadece [a-Z 1-9]. Bunu yapmak için geçerli bir nedeni var mı? Özellikle böyle değerli bilgileri koruyan bir sistem için, parola gücünü bu şekilde engellemek çok verimli görünmektedir.
Gelebildiğim tek şey, SQL enjeksiyonlarını engellemek için zayıf bir girişimdir, ancak bu şifrelerin özetlenmediğini varsayar (ki umarım doğru değildir).
Burada görmediğim bir açıklama, birçok finansal kurumun eski sistemlerle sıkı bir şekilde bütünleşmiş ve bu sistemlerin sınırlamalarına bağlı olmasıdır.
Bunun ironisi, eski sistemlerle uyumlu olacak şekilde inşa edilmiş sistemleri gördüm ama şimdi eski sistemlerin gittiğini ve eski sistemle uyumlu olacak şekilde inşa edilmiş yeni sistemle uyumluluk için politikanın hala var olması gerektiğini düşünüyorum.
(buradaki ders, eski bir sistemle uyumlu olmanız gerekiyorsa, gelecekte bu sınırlamaların kaldırılmasına izin vermenizdir).
Destek maliyeti ne olacak? Diyelim ki herkes şifre oluşturmasına izin verdik
€ Karakterden oluşuyor. Yaşasın, şifrelerde özel karakterler kullanabiliyoruz. Ama bekleyin - bankamıza cep telefonundan erişmek istiyorsak nasıl bu şifreyi yazabiliriz? Klavyemizden
€ Yazmak cep telefonundan daha kolaydır.
Tatiller ne olacak? Sadece İngiltere klavyesine erişen İngiltere'deyiz.
€ Yerine
£ Yazabiliriz.
easily kelimesi burada çok önemlidir. Bazı ortalama kullanıcılar için, "yeni" klavye için bu karakterleri yazmak sorun olabilir. Nasıl çözmeye çalışacak? Muhtemelen banka desteğini arayarak şifresini değiştirmelerini veya
why the € character dissapeared from his keyboard.
Bu, derinlemesine bir savunma önlemi olarak (zayıf bir şekilde haklı gösterilebilir) - bir enjeksiyon veya başka bir veri yorumlama hatası varsa, şifre karakter kümesini ve uzunluğunu sınırlandırmak, sömürülmesini engelleyebilir. Yalnızca 7 bit ASCII karakterler, Unicode ve çok baytlı karakter dizisi kullanımı ile ilgiliyse ve daha basit uygulamaların hata içermesi daha kuralsız olduğu için, uygulamayı biraz daha basitleştirir.
Bununla birlikte, bu düşük riski düşük şifre kalitesinden dolayı artan riske karşı değerlendirmek basit değildir - bir sistemin kullanıcı sayısı arttıkça, tehlikeye atılabilecek şifre sayısının da artmasını ve bu tür bir kaldırmaya yatırım yapmasını beklerim. kısıtlamalar daha değerli. Tüm bunlar, alan tamamen kısıtlanmamış olsa bile çoğu kullanıcının şifresi korkunç olacaktır.
Benim tahminim politika tüm kullanıcı tarafından girilen alanlar için var ve basitlik için şifreler de dahil olmak üzere aynı kullanıcı giriş politikası (özel karakter yok) uygulandı. Ya da bir noktada bazı bankalar parolaları karıştırmıyorlardı ve parola alanlarından bir SQLi saldırısı geçiriyorlardı ve parolaların özel karakterlere sahip olamayacağına karar verildi (ve hash getirildikten sonra politikanın nedeni unutuldu).
Kesinlikle karma olmayan ve SQLi veya XSS gibi çeşitli saldırılarda kullanılabilen (hesaba bakarak bir banka yöneticisinde) özel karakterlere izin verilmemesinin bir güvenlik yararı vardır. Bununla birlikte, bu tehditler genellikle SQL'de her zaman bağlı parametreler kullanılarak ve db'ye gösterilmeden/kaydedilmeden önce kullanıcı girişini her zaman sterilize ederek çözülür.
Diğer tahminim, diğer yerlerden farklı olabilecek özel kurallara sahip olmak istedikleri, bu nedenle standart güçlü parolanızı (kaybolabilir) kolayca yeniden kullanamayacaksınız ve siteleri için benzersiz bir şey bulmak zorunda kalacaksınız.
DÜZENLEME: Daha fazla düşünce üzerine, dile bağlı olarak, evrensel olarak yasaklanması/soyulması gereken en az üç özel ASCII karakter düşünebilirim, yalnızca kaderi cazip kılar.) Özellikle:
\0 (null - ascii 0), çünkü genellikle C stili dillerinde dizenin sonunu belirtmek için kullanılır (muhtemelen kullanıcılar dizenin bitiminden sonra belleği değiştirmek için) Ayrıca satır başı ve satır beslemeleri
\r (ascii 13) ve
\n (ascii 10), çünkü bunlar genellikle satır sonları
\r\n veya
\n olsun ve kaçınılmaz olanı ortaya çıkarır Sadece mac/linux makinemden değil, pencerelerden giriş yapabilirim.Aslında, sadece yazdırılabilir ascii (32-126) izin vermek ve yazdırılamayan ASCII 0-31 ve 127.
Ancak özel karakterlerle, unicode demek istemiyorsanız ASCII karakterler (
,./<>?;':"[]{}\|[email protected]#$%^&*(-=_+ gibi), birden çok işletim sisteminden/klavyeden/tarayıcıdan uygulamanın basitliklerinin özel karakterlere izin vermemesi makul görünmektedir. Parolanızın içinde küçük bir pi olduğunu düşünün. 0x3c0 kod noktası olan Yunan pi (π) veya 0x2ca1 kod noktası olan Kıpti küçük pi (ⲡ) - sadece biri çalışacak ve farklı karakterlere sahip bu tür bir sorun Unicode kod noktaları bulunacaktır.Bitlerle çalışan karmanız iki π ile eşitlenemeyecektir, bu nedenle farklı yerlerde giriş yapmayı denerseniz farklı karakterler girebilirsiniz.
Benzer şekilde, bu sorun programcı büyük ölçüde kontrol edip düzeltmeye çalışabilir, ancak unicode karakterlerin kodlama sorunları oluşturmasına izin verir. Bu, temel ascii karakterleriniz için her şeyin bir bayt sayısında temsil edilir. Bununla birlikte, unicode'un nasıl kodlanacağına ilişkin bir dizi farklı şema vardır. UTF-7, UTF-8, UTF-16, UTF-32, Latin-1 (iso-8859-1), Latin-N kodlaması ve (bazı kodlamalar için) bayt sırası nedir (küçük veya büyük endian) ? Pi (0x3c0) için unicode kod noktası UTF-7'de
2b 41 38 41 2d bayt olarak, UTF-8'de
CF 80 ve UTF-16'da
FF FE c0 03 ve UTF-32'deki
FF FE 00 00 c0 03 00 00. Latin-1'de pi'yi temsil edemezsiniz (yalnızca 95 ekstra yazdırılabilir karakter vardır), ancak şifrenizde bir
A1 varsa ve farklı kodlamalar içindeyseniz bunu temsil etmeniz gerekebilir aşağıdaki karakterlerden herhangi biri
¡ĄĦЁ‘ก”Ḃ (bazı Latin-N harflerinde A1 olabilir).
Evet, web sayfasında bir karakter kümesi tanımlanmış olabilir, ancak kullanıcılar tarayıcılarındaki bir sayfadaki karakter grubunu geçersiz kılabilir veya başka bir kodlamada başka bir yerden veri kopyalayıp yapıştırabilir. Günün sonunda, bu karakterleri yasaklamak daha basit olabilir.
Genelleme olarak, finansal kurumların uzunluk ve karakter kümesi karmaşıklığını kısıtlamasının en yaygın nedenleri şunlardır.
(1) Web hizmetleri, eski ana bilgisayar uygulamalarına yönelik, genellikle yalnızca küçük harfli alfa ve sayılardan oluşan sekiz karakter sınırlaması olan ön uç sistemleridir. "Özel karakter" yok. İşin garibi, bu en yaygın sınırlamadır. Yukarıdaki Mark Burnett'e + 1'leyin.
(2) Parolaları sağlamıyorlar, bu nedenle sabit uzunluklu sayısal bir dizeyi (yani karma çıktı - 32 bayt SHA256 (parola)) depolayamıyorlar. Bu nedenle, girdinin boyutunu sınırlama konusunda endişelenmeleri gerekir.
(3) SQL enjeksiyon tehdidi vektörü, yalnızca şifreler düz metin olarak saklandığında bir şifre sorunudur. Birçok kuruluş ve diğerleri, karma bir parola (ideal olarak tuzlanmış ve PBKDF2 gibi bir şey kullanarak gerildi .
Basit müşteri desteği şifre sıfırlama güvenlik dışında sıfırlama dışında, kullanıcı cihazından açık metin olarak bir kullanıcı şifresi iletmek için farkında olduğum kabul edilebilir bir neden yoktur. Sorumluluğu istemiyorsunuz, bu yüzden asla kabul etmeyin. Kripto karmaları bunun için.
İşte en iyi uygulamalardan bazılarını özetleyen ve kod örnekleri içeren harika bir blog yazısı. http://crackstation.net/hashing-security.htm
Aslında büyük bir internet mağazasından sordum (bol.com, uluslararası olup olmadıklarından emin değilim).
Onların tavsiyesi, güçlü bir şifre kullanmak, sık sık değiştirmek, harf ve rakam kullanmak, uzun olması ve belki de unuttuğum başka şeyler. Her neyse, hiç kimse takip her zamanki tavsiye. Ancak şifre politikasına önem veriyorlar.
Yine de çoğu özel karaktere izin vermezler ve maksimum şifre uzunluğu 12 karakterdir. Bana sorulduğunda, aksi takdirde çok fazla insanın desteğe başvuracağını söylediler.
Onlara "Parolanızı mı unuttunuz?" özelliği için, hiçbir cevap var ...
E-posta ile basit bir şifre sıfırlamanın söz konusu olmadığı bankalar için, destek maliyetlerinin gerçekten sebebi olduğunu düşünüyorum (burada başkaları tarafından önerilen gibi). Bu bol.com gibi başka bir web sitesi için, şifreleri hash olsun onlar çok güvensizlik olacaktır. Burada daha benzersiz bir şifre kullanmalısınız, eğer veritabanı sızarsa şifreniz bilinecektir.
Karakter kümesini alfasayısallarla sınırlamak, bir komut dosyasının veya istismarın giriş doğrulama aşamasını geçme olasılığını sınırlar.
Kullanıcı daha uzun parolalar kullanarak güvenliğini her zaman artırabilir, ancak uygulamanın saldırıları önlemeye yardımcı olması için belirli bir beyaz listeye sahip olması gerekir.
Yukarıdaki sorunu bir programcı olarak değil, bir UI arayüz tasarımcısı olarak görmeye çalışabilirim: Buradaki anahtar nokta, giriş gereksiniminin kısmen bir UI arayüz tasarımı problemi ve sadece bir programlama problemi olmasıdır.
Aşağıda yazacağım pencere boyutları ile ilgili benzer bir sorun gösteren mükemmel bir "Apress - Programcılar için Kullanıcı Arayüzü Tasarımı" kitabı var:
İşte ortak bir programcı düşünce modeli: sadece üç sayı vardır: 0, 1 ve n. N'ye izin verilirse, tüm n'ler eşit derecede olasıdır. Bu düşünce kalıbı, kodunuzda 0 ve 1 dışında sayısal sabitler kullanmamanız gereken eski kodlama kuralından (muhtemelen akıllı) gelir.
Şimdi yukarıdaki düşünme sadece bir programlama probleminde doğrudur, ancak kullanıcı arayüzleri ve özellikle pencereler ile ilgili olduğu için
Ama bu doğru değil. Sonuç olarak, eşit derecede olası değildir. Tam olarak ekranın üst kısmında bir pencere istemenizin birçok iyi nedeni vardır (ekran alanını en üst düzeye çıkarır), ancak ekranın üst kısmı ile pencerenin üst kısmı arasında iki piksel bırakmak için herhangi bir neden yoktur. . Yani, gerçekte, 0 2'den çok daha olasıdır.
Şimdi sorunumuza gelince, teorik olarak tüm karakterlere eşit derecede muhtemel ve eşit derecede programlama ve resmi bakış açısından izin verilmelidir, ancak burada da bir UI arayüzü sorunu örneğindeyiz ve bunun farkında olmalı ve doğru ağırlığı vermeliyiz .
Bu yüzden benim görüşüme göre yukarıdaki iş parçacığından bir cevap yorumlayacağım:
Diyelim ki herkesin € char içeren şifreler oluşturmasına izin verdik. Yaşasın, şifrelerde özel karakterler kullanabiliyoruz. Ama bekleyin - bankamıza cep telefonundan erişmek istiyorsak, bu şifreyi nasıl yazabiliriz? Klavyemizden € yazmak cep telefonundan daha kolaydır.
Kullanılabilirlik açısından ana nokta budur ve birkaç yıl sonra bir akıllı telefonla, var olmadıkları yıllar önce, kaçınması gereken bir karakter kullandığını fark ederse, kullanıcıyı suçlamamalıyız.
Bu tür sorunları düşünmek ve kullanıcının bundan kaçınmasına izin vermek bizim yükümlülüğümüzdür!
Partiye biraz geç - Geçenlerde bunun birçok banka için, bu karakterlere izin vermenin artan güvenliğinin değerinin uygulama maliyeti ve şifrelerini hatırlayamayan müşterilerle uğraşmanın destek maliyetinden daha ağır basması olduğunu okudum. .
Bunun iyi bir neden olduğunu söylemiyorum ama okuduğumu bu şekilde yorumladım.