View source for Choosing and Using Security Questions Cheat Sheet tr


== '''Güvenlik Sorularının Seçilmesi ve Kullanılması Referans Belgesi''' ==

'''Giriş:'''
Bu referans dökümanı, çok genel bir web uygulaması olan “Şifremi unuttum”  özelliğinin uygulanması için hangi güvenlik sorularının seçilmesi ve kullanılması gerektiğine dair uygulanmış ve başarılı olmuş örnekleri yazılım geliştiricilere sunmaktadır.

'''Problem:'''
Kullanıcılara veya geliştiricilere “Şifremi Unuttum” özelliği için rehber olacak şekilde belirlenmiş bir endüstri standartı (biçimi) bulunmamaktadır. Bunun sonucunca uygulama geliştiriciler genellikle şüpheli/belirsiz/kesin olmayan soruları seçerek bunları güvenliksiz bir şekilde bu uygulamaya entegre ediyorlar. Geliştiriciler bunu uygularken, sadece kullanıcılarını riske atarak değil, aynı zamanda (potansiyel sorumluluk sorunları nedeniyle) kurumlarını da riske atarak yapmaktadırlar. Ideal olarak, çok faktörlü yetkilendirme mekanizmalarından sadece birini kullandıklarında şifreler ölü yada daha az önemli olurdu.Fakat gerçek şu ki, şifrelerle muhtemelen sıkışmış durumdayız aynen Cobol da sıkışmış olduğumuz gibi. 

(Burada Cobol ile sıkışmışlık konusunu biraz açıklamak faydalı olacaktır: Bilgisayar dünyasında “Cobol bizden uzun yaşayacak” mottosuna dair eski bir espri var, Yazılım ve Donanım arasında ki fark nedir? diye. Cevap şöyle: Eğer donanımı yeterince uzun bir süre kullanırsanız, kırılır. Eğer yazılımı yeterince uzun bir süre kullanırsanız,çalışır/çalışmaya devam eder. Bunun ortaya çıkışının ardındaki temel sebep ise onlarca yıllık yaşına rağmen (ki Cobol 1959-1960 larda ortaya çıkmıştı) Cobol günümüzde halen bankalarda ve büyük şirketlerde kritik uygulamaları / sistemleri yönetmektedir. 1980 ve 90 larda Cobol u değiştirmek, yerine başka teknolojileri uygulama çabaları da sonuçsuz kaldı. Ve bizler şu anda yaşlı Cobol ile önceden görülebilir bir gelecek konusunda sıkışmış durumdayız ve bu kodları yazanların çoğunun 2.dünya savaşı öncesi doğmuş ve çoktan emekli olmaya başlamış insanlar olduklarını düşünürsek sanırım durum daha da açıklanabilir bir hale geliyor.)

Açıklamadan sonra o halde, “Şifremi Unuttum” sorununun makul bir çözümü için bizler neler yapabiliriz?

Güvenlik Sorularının Seçimi ve/veya Kimlik Verisi:

Çoğumuz, kötü bir “güvenlik sorusu” ile karşılaştığımızda anında anlarız. Bunların anlamlarını çok rahatça anlarsınız. “Favori renginiz hangisidir?” gibi bir soru açıkça kötü bir güvenlik sorusudur. Fakat (http://goodsecurityquestions.com/) sitesini de de belirtildiği üzere “Esasen ortada mevcut İYİ bir güvenlik sorusu yoktur; sadece açık veya kötü olanı vardır.”

Birçok kurum/şirket veya organizasyon için kullanıcıların unutlulan şifreleri yeniden oluşturmasına izin vermesinde ki sebep sadece güvenlik değildir, kendi giderlerini azaltmaktan da ziyade, kendi müşteri destek hatlarının aranmasında ki hacimi düşürmektir. Bu klasik olarak uygunluk/kolaylık ve Güvenlik takasıdır ve bu durumda, uygunluk/kolaylık (her ikisi de organizasyon açısından giderlerin azaltılması için ve kullanıcı açısından basit olması için, self-servis) hemen hemen herzaman kazanır.

Bu sebepledir ki, iş dünyası tarafında düşük maliyet her zaman kazanır,peki bu barı hiç olmassa birazcık daha yükseltmek için ne yapabiliriz?

Bununla ilgili birkaç öneri mevcut. Şunu bilhassa not etmekte fayda var,kasıtlı olarak veya bilerek spesifik/özel güvenlik soruları sormaktan kaçınıyoruz.Bunu yapmak muhtemel olarak zarar verici olacaktır, çünkü birçok geliştirici bu soruları üzerinde çok düşünmeden kullanacaktır ve düşmanlar nam-ı diğer black hat hacker lar veya zarar vermek isteyenler çeşitli sosyal sitelerden bu verileri elde etmeye başlayacaklar. 


== '''İstenilen Karakteristik''' ==

İdeal olarak unutulan bir şifreyi tekrar elde etmek veya yeniden belirlemek için herhangi bir güvenlik sorusu veya sunulan kimlik bilgileri
şu dört karakteristiğe sahip olmalıdır:

'''Akılda Kalıcı:''' Eğer kullanıcılar güvenlik sorusuna verdikleri cevabı hatırlayamazlar ise, hiçbirşey başarılamamış demektir.

'''Tutarlı:''' Kullanıcının cevabı zaman içerisinde değişmemeli. Mesela, "aileden birinin veya sevgilinin veya akrabalardan birinin ismi nedir?" gibi bir soru takip eden zaman içerisinde birçok farklı cevaba sahip olacaktır.

'''Olabildiğince Evrensel:''' Güvenlik soruları mümkün olduğunca geniş bir kitleye hitap etmeli.

'''Güvenli:''' Güvenlik sorularının cevapları kolay tahmin edilebilir veya araştırılabilir olmamalıdır.


== '''Adımlar''' ==

Genel olarak, şifre yenileme veya unutulması durumunda tekrar elde etme esnasında kullanılacak girdiler için tek bir HTML formu kullanılmalıdır. 

Eğer kuruluşunuz kullanıcılar ile iş odaklı olarak bağlı ise, muhtemel olarak kullanıcılar internet sayfasında kayıt olurken haklarında size bir takım ilave bilgiler de vereceklerdir.Bu bilgiler -altta belirtilenler ile sınırlı olmamak kaydı ile- şu şekilde olabilir:

'''* E-Posta Adresi,'''

'''* Soyadı,'''

'''* Doğum Tarihi,'''

'''* Hesap Numarası,'''

'''* Müşteri Numarası,'''

'''* Sosyal Güvenlik Numarası veya Vatandaşlık Numarasının son 4 hanesi,'''

'''* Posta Kodu,'''

'''* Sokak Numarası,'''


Güvenliği biraz daha güçlendirmek için, kullanıcıya ilk olarak '''E-Posta''' adresini sorduktan sonra bu e-posta adresine kullanıcıyı özel güvenlikli bir sayfaya yönlendirecek bir e-posta gönderilebilir ve bu sayfada kullanıcının 2 veya daha fazla kimlik faktörleri sorulabilir.Bu yol ile e-posta nın kendisi o kadar da kullanışlı değil çünkü kullanıcılar sayfaya ulaştıktan sonra halen cevaplamak zorunda oldukları birçok gizli güvenlik sorusu ile karşılaşacaklar.

Buna karşılık, eğer bir internet sayfasının hostluğunu üstlenmiş iseniz ve hedef kitleniz genel kullanıcılar ise, mesela sosyal medya, ücretsiz e-posta, haberler, fotoğraf paylaşım vs siteler ise o zaman büyük olasılıkla yukarda sayılan bilgilere sahip olamıcaksınız ve heryerde bulunan veya daha doğru bir ifade ile '''"sık rastlanan"''' bazı genel güvenlik sorularını kullanmaya ihtiyacınız olacak. Fakat, aynı zamanda şifre güvenliği ve yenilemesi için bant dışı bazı verileri de toplamak durumundasınız, örnek olarak farklı bir e-posta adresi, kısa mesaj (SMS) için telefon numarası gibi...

İnanın veya inanmayın, kullanıcıların birkaç set hali hazırda mevcut olarak kaydedilmiş olan güvenlik sorularından seçme hakları vardır. Genellikle kullanıcılardan profillerini ilk oluşturma aşamasının bir parçası olarak güvenlik sorularınıda doldurmalarını istiyoruz ve sıklıkla kullanıcılar bu noktada sabırsız davranıp biran önce kayıt olup siteyi kullanmaya başlamak istiyorlar. Bunun yerine kullanıcılara kendi güvenlik sorusunu veya sorularını oluşturmalarını istersek eğer, kullanıcılar kendilerini genellikle baskı altında hissediyorlar ve böylece belki de '''çok çok''' basit güvenlik soruları ortaya çıkabiliyor.

Kullanıcıların kendi güvenlik sorularını veya sorusunu oluşturma isteğimizin aynı zamanda çok da mantıklı bir açıklaması mevcut. Kullanıcıların kendi güvenlik sorularını oluştuma da görünen hakim ve yasal olan fikir,eğer biz kullanıcılara kendi sorularını oluşturmada makul ve mantıklı bir rehber sağlayabilirsek ve kullanıcılara bunun için ısrar edersek, hiç olmassa bazı sorumluluklar kuruluş/organizasyondan tarafından kullanıcı tarafına geçmiş olur. Kullanıcı hesabının veya hesaplarının zayıf güvenlik soruları (Örnek:Hangi dondurma rengi favorim?) nedeniyle hacklenmesi gibi bir durum ortaya çıktığında, kullanıcılar kuruluş/organizasyonu suçlamak yerine kendilerini kusurlu görecekler ve organizasyona daha az dava açılması veya şikayet gelmesi söz konusu olacaktır.

OWASP şifreyi tekrar belirlemeden önce kullanıcıya Forgot Password Cheat Sheet de önerdiği üzere, birden fazla güvenlik sorusunun sorulmasını tavsiye ediyor. Bunu iyi bir şekilde pratik etmek için kullanıcıdan kendi hazırladığı soru yanında soru havuzunda bulunan 1 veya 2 soruyu seçip cevap vermesi istenmelidir.

'''Adım 2'''

'''Mevcut Güvenlik Sorularını Yasal veya Mahremiyet Birimleri/Görevlileri ile Gözden Geçirin:'''

Birçok geliştirici potansiyel soruları ilk olarak genellikle ilgili iş birimleri ile gözden geçirir.Fakat, bu soruları asıl yasal olan veya mahremiyet ile ilgili yönetici kişilerle gözden geçirme sorumluluğu geliştiricilerin değildir. Lakin, bu akla yatkın bir tavsiye olarak alınabilir, çünkü sorular bu aşamada kanunlar, çeşitli düzenlemeler / uyumluluk konularına bağlı olmak zorunda olabilirler. Mesela, telekomunikasyon endüstrisinde, FCC(ABD'de: Federal Communications Commission dairesi)düzenlemelerinde müşterilerine kişisel bilgi içeren sorular sormayı yasaklamıştır. Bu sebepledir ki,'''"Hangi Şehirde Doğdunuz?"''' gibi soruların sorulmasına genellikle izin verilmemektedir.

'''Adım 3'''

'''Cevapların Minimum Uzunlukları Üzerinde Israrcı Olun:'''

Eğer güvenlik sorularını çok kibar bir şekilde sorarak cevaplarını almaya çalışsanız dahi, genellikle kullanıcılar bu tür sorulara tüm bilgilerini açığa çıkaracağını öngörerek cevaplamaktan hoşlanmazlar ve sıklıkla bu tür soruları kısaca geçiştirmeye çalışırlar. Bu tür durumlarda kısa bir kelime yada "xxx" yada "1234" gibi cevaplarla karşılaşmak '''hiçte nadir''' bir durum değildir. Eğer kullanıcılara bir sözcük grubu veya bir cümle ile cevap vermeleri gerektiğini söylediğinizde ve kabul edilebilir cevabın minimum uzunluğunu belirttiğinizde (mesela 10-12 karakter) kullanıcılardan bu duruma karşı genelde daha dirençli cevaplar alırsınız.

'''Adım 4'''

'''Güvenlik Sorularını ve Cevaplarını Güvenlik Olarak Nasıl Kayıtlı Tutabilirsiniz:'''

Bu olaya 2 farklı bakış açısı mevcut:

'''*''' Soruları kayıt altına almak,

'''*''' Cevapları kayıt altına almak,

Açıkça, sorular kullanıcılara sunulmak durumunda, bu sebeple güvenlik sorularını kayıtlı tutarken ya düz metin (plaintext) yada ters olarak şifrelenmiş (reversible cyphertext) olarak tutulabilir.Teknik olarak cevaplar herhangi bir kişi tarafından görülmeye ihtiyaç duymadığından güvenli olarak şifrelenmiş hash ler şeklinde tutulabilirler. (İlke olarak, bazı yardım masaları şifreleri kurtarmak veya tekrar belirlemek için soruları da cevapları da kullandıklarının farkındayım ve bu yardım masaları kullanıcıların cevapları yazarak girmeleri yerine kendilerinin görmeleri ve okumaları konusunda ısrarlı davranmaktalar.YMMV '''*-Burada YMMV ile ilgili ilave olarak bir bilgi vermek istiyorum-*'''Your Mileage May Vary: Algılayıştaki farklılığı ortaya koymak için kullanılan bir terimdir.Uzunca yazmak yerine "YMMV" şeklinde kullanılmaktadır.Burada yazının orjinalini yazan kişi açıklamasının sonunda YMMV'yi koyarak algılayışlarımız farklı olabilir demeye getirmektedir.)

Her iki durumda da, cevapların düz metin olarak tutulmasındansa şifrelenmiş olarak tutulmasını tavsiye ediyoruz. Bu özellikle, kullanıcılara sunulan '''"kendi güvenlik sorunuzu oluşturun"''' seçeneği için cevabın çok özel olduğu düşünüldüğünde çok doğru bir adım olacaktır. (Mesela: Eşim ile paylaştığım banka hesap numarası nedir? gibi bir soru için)

Bu sebeplerdendir ki, ana soru soruların düz metin mi yoksa tersine şifrelenmiş olarak mı tutulacağından ziyade kabul edilmelidir ki biz biraz ön yargılı olarak özellikle '''"kendi güvenlik sorunuzu oluşturun"''' tarzı sorularda şifrelemenin kullanılmasından yanayız.

Eğer cevaplar şifreli tutulursa, veritabanının hacklenmesi durumunda kuruluşa dava açılması veya daha az zor durumda kalması riski daha aza indirgenecektir.

Buna ilave olarak, müşterinize soruların ve cevapların şifreli olarak tutulduğunu açıklarsanız, bazı soruların sorulmasında kendilerini daha fazla güvende hissedeceklerdir özellikle bazı utandırıcı sorularda.

'''Adım 5'''

'''Periyodik Olarak Kullanıcılarınıza Sorularını Gözden Geçirtin:'''

Birçok şirket sıklıkla kullanıcılarından e-posta adresi,sokak bilgisi vs bilgilerini hala güncel olup olmadığına dair güncellemesini ister. Bu güncelleme istendiği sırada oluşan fırsatı kullanıcıların güvenlik sorularını da gözden geçirmelerini istemek için kullanabilirsiniz.