İsteyenin Bir Yüzü, İmplemente Etmeyenin İki Yüzü Kara
Bir araştırma sonucuna göre güvenli bir sistem geliştirilmesi için önce bunu yazılımcılardan talep etmelisiniz! Araştırmanın detayları ve güvenli parola saklamak için kullanılan yöntemler yazımızda.
2017 ve 2018 yıllarında Naikashina bilgisayar bilimleri öğrencilerinin parolaları güvenli saklama konusundaki yaklaşımlarını değerlendirmek için 20'şer kişilik iki grup üzerinde bir deney gerçekleştirdi. Araştırmaya katılan öğrencilerden üniversitenin sosyal medya uygulaması için bir kullanıcı kayıt uygulaması geliştirmelerini istedi.
Gruplardan birine kullanıcı parolalarının güvenli bir biçimde saklanması şartı koşulurken, diğer gruba spesifik olarak böyle bir koşuldan söz edilmedi.
Araştırmacının edindiği sonuca göre katılımcılardan parolaları güvenli saklamaları açıkça talep edilmediğinde, hiçbir öğrencinin geliştirmede güvenli bir sistem için elzem olan bu ihtiyacı dikkate almadığı gözlemlendi. Sadece ikisi güvenli bir biçimde saklamak için girişimde bulundu fakat sonra daha güvensiz bir yöntem seçerek vazgeçti.
Kendilerine parolaları güvenli bir biçimde saklamaları şartı koşulan diğer gruptan ise sadece 12 kişi bunu çeşitli seviyelerde gerçekleştirdiler.
Yukarıda sonuçlarını paylaştığımız araştırmada birkaç önemli nokta var. Araştırmaya katılanların tamamı bilgisayar bilimleri öğrencisi, acaba böylesi bir çalışma geliştiriciler üzerinde gerçekleşse sonuçlar nasıl olacaktı?
İkinci olarak da tüm katılımcılar bir deneyin parçası olduklarını bildikleri için güvenliğin kendilerine çalışma başında koşulan şartlarla ilgisi olmadığını düşünmüş olmamalılar.
Nitekim güvenli parola saklama işlemini gerçekleştirmeyen 28 kişiden 15'i ise gerekçe olarak gerçek bir müşteri için geliştirmediklerini belirterek, güvenli parola saklama implementasyonuna ihtiyaç duymadıklarını belirtiyorlar.
Peki bu araştırmayı gerçek geliştiriciler üzerinde, gerçek bir olay ile tekrarlamak mümkün mü? Evet!
Kendilerini Freelancer'da bir start-up firma olarak tanıtan araştırmacılar verdikleri ilanda geliştiricilerinin işi bıraktığını ve social networking sitelerinin geliştirilmesinin devamı için yardıma ihtiyaç duyduklarını belirttiler. Geliştiricilerden talep ettikleri ise söz konusu hayali social networking sitesinin kullanıcı kayıt fonksiyonu idi.
100 ile 200 Euro arasında değişen iki farklı bütçe ile ilanı veren araştırmacılar 43 geliştiricinin dahil olduğu araştırmada ilginç sonuçlara ulaştı.
Katılımcıları ikiye bölen araştırmacılar bu gruplardan ilkine güvenli parola saklamanın implemente edilmesi gerektiğini söylerken, diğer bir grup katılımcıya böyle bir ihtiyaçtan söz etmediler.
Üç günlük bir proje teslim süresinin sonunda dönüş yapan 18 kişinin gönderdiği ilk kod örneğine güvenli parola saklama özelliği implemente edilmemişti. Bunlardan 15'i kendisine çalışma başlangıcında "güvenli parola saklama" özelliği bahsedilmemiş gruba dahil idiler. Kendisine çalışma başlangıcında kullanıcı kayıt fonksiyonu geliştirilirken parolaları güvenli saklama özelliği eklenmesi istenmeyen 22 kişiden 15'i yani yüzde 68'i buna ihtiyaç bile duymamışlardı!
Sonuç Freelancers'dan kiralanan geliştiricilerin de aksi açıkça belirtilmedikçe parolaları saklama ihtiyacı hissetmedikleri, güvenli parola saklamaya dair yanlış kanaatleri olduğu ya da güvenli parola saklama özelliği ekleyenlerin modası geçmiş yöntemlere başvurdukları oldu.
Tabloda bold olarak işaretli alanlar, işi ilk teslimlerinde güvenli parola saklama seçeneğini koda implemente etmeyenler. Kullanıcıların iki gruba ayrıldığını söylemiştik. Prompting değeri 1 olanlar güvenli parola saklama özelliği ihtiyacının spesifik olarak belirtilmediği grup. Working Time katılımcıların kodu ilk yollamaları için geçen süre. Include Security alanı ise güvenli parola saklama özelliği eklenmeleri istendikten sonra geçen süre. C&P çözümlerde internetteki kaynaklardan copy/paste olarak faydalanan katılımcıları gösteriyor. Study kolonu ise çeşitli yöntemlerle bunun akademik bir araştırma olduğundan haberdar olduklarını söyleyen kullanıcılar. SQ ise güvenli parola saklama implementasyonunda hangi hashing fonksiyonunun kullanılacağını soran katılımcılar. N belirteci "non prompting" yani kendilerine güvenli parola saklama özelliği eklenmesi hususen söylenmemiş olan kullanıcılar. P ise prompting yani kendilerine peşinen bu talebin iletildiği kişiler. 100 ve 200 değerleri de ilan için teklif verilen bütçeyi gösteriyor.
Güvenlik Talep Ediyorsanız, Açıkça Belirtmelisiniz
Öğrenciler ile yapılan diğer çalışmadan elde edilen sonuçlara benzer şekilde güvenlik gereksiniminin açıkça talep edilmesi sonuçları önemli ölçüde etkiliyor. Bir grup freelancer'ın özellikle de düşük bütçe grubundaki (100 euro) ilana talip olan geliştiricilerin büyük bir kısmı parolaları güvenli saklama konusuna kafa yormamışlar.
Her iki çalışma mukayese edildiğinde geliştiricilerin geliştirdikleri hizmetin gerçek dünyada kullanacaklarını bilmelerine rağmen elde edilen sonucun, geliştirdikleri kodun gerçek dünyada kullanılmayacağını bilen öğrencilerden edilen sonuçlarla karşılaştırılabilecek yakınlıkta olduğu gözlemleniyor.
Geliştiriciler Güvenlik Konusunda Yeterli ve Doğru Bilgiye Sahip Değiller
Encryption ve hashing geliştiriciler tarafından eş anlamlı iki kavram olarak kullanılıyor. Nitekim ürettikleri çözüm de bunu doğrular nitelikte. Bir grup geliştiricinin güvenli parola saklama yöntemi olarak Base64 encoding'i kullandıkları tespit ediliyor.
43 kişilik katılımcıdan 8'i güvenli parola saklama yöntemi olarak Base64 encoding'i kullanmıştı.
Geliştiricilerin kendilerini de geliştirmeleri gerekiyor. Bir grup geliştiricinin güvenli parola saklama yöntemi olarak güncelliğini yitirmiş metodlar kullandıkları tespit ediliyor. Bu sonuç öğrenciler ile yapılan diğer araştırmalarda da gözlemlenmişti. Geliştiricilerin de kendilerini geliştirmeleri ve güvenlik sahasındaki gelişmeleri takip etmeleri gerekiyor. Örneğin araştırma sonuçlarında zayıf bir hashing algoritması olan MD5'i kullanan geliştirici sayısı 10.
Kopyala ve Yapıştır
Yine öğrenciler ile yapılan deneydekine benzer bir sonuç, freelancer'larda da rastlandı. Güvenli parola saklama çözümü olarak bir kısım freelancer internetten buldukları çözümleri doğrudan kullandılar.
43 geliştiriciden 17'si internetten edindiği kodu projede kullanıyor.
Daha önce 2014 yılında Rebecca Balebako ve beraberindeki birkaç araştırmacı tarafından The Privacy and Security Behaviors of Smartphone App Developers başlığı ile yapılan araştırmada 13 geliştirici ile yapılan birebir mülakat ve 228 geliştiricinin katıldığı anket sonucunda geliştiricilerin yarısı güvenli bir biçimde dataları sakladıklarını belirtmişti. Fakat bu araştırma, sadece deneklerin görüşlerine itibar edildiği araştırmalarda sonuçların gerçeklerle örtüşmediğini gösteriyor. Zira yukarıda da zikredildiği gibi geliştiriciler ya güvenlik konusunda yanlış bir bakış açısına sahip, ya da eski teknolojileri kullanıyorlar.
Proje kapsamında anlaşılan geliştiricilerin güvenli parola saklama konusunda başvurduğu yöntemler şunlar:
- Base64
- MD5
- SHA-1
- 3DES
- AES
- PBKDF2
- HMAC/SHA1
- SHA-256
- BCrypt
Araştırmanın ayrıntıları için lütfen tıklayınız.
Parola Saklama Konusundaki Doğru Bilinen Yanlışlar
Encoding Şemaları, Parolaları Güvenle Saklamak İçin Uygun Bir Yöntem Değildir.
Encoding, encryption ve hashing birbirlerinden farklı ama zaman zaman birbirlerinin yerine ikâme edilen kavramlar.
Eldeki bir metin encoding işlemine tabi tutulduğunda üretilen çıktı göze karmaşık göründüğü için çoğunlukla bu encryption yani şifreleme ile karıştırılabiliyor. Oysa aradaki temel fark, kaynak metne tekrar ulaşmak için encoding işlemini tersine çevirmek (decoding) yeterli iken, encryption da ise kaynak metne ulaşmak için şifrelemede kullanılan anahtara da sahip olmak gerekiyor.
Encoding şemaları, araştırma örneğinde ve sıklıkla data ifşaatlarına gözlendiği şekliyle Base64 encoding şeması ile bir nevi gizlenmeye çalışılmaktadır.
Oysa encoding şemaları parolaların güvenli bir şekilde saklanmasına değil, farklı bir karakter kümesi ile yeniden kodlanmasıdır.
Örneğin Base64 encoding şemasında girdi bu şemanın karakter kümesi ile yeniden kodlanır. Amacı asla parolayı şifreli bir halde saklamak değil, sadece girdi olarak kullanılan data eklendiği kontekste o kontekste özel anlam içeren karakterlere sahipse bunları problemsiz bir şekilde aktarmaktır.
Örneğin Netsparker metnini Base64 ile encode ettiğimizde TmV0c3Bhcmtlcg== sonucuna ulaşabiliyoruz. Burada Base64'e has olan "=" paddingini gören saldırgan kolaylıkla decoding işlemini yaparak zahmetsizce bu girdiyi orjinaline çevirebilir.
Özet Algoritmaları, Şifreleme ve Tuzlama (Salt)
Bu ikisinden tamamen farklı olan hashing yani özet algoritmaları ise matematiksel bir operasyondan geçirilen kaynak metinden, bir daha kaynağa dönüşün mümkün olmayacağı başka bir alfanumerik değere ulaşmak anlamına geliyor. Yani hashing ile elde edilen değer, kaynak metne tekrar ulaşmak için terse çevrilemeyecektir.
Örneğin Netsparker metnini SHA-256 özet algoritmasından geçirdiğimizde ulaşacağımız çıktı:
8c858bca263e9a2a1129821d10f61b93053afabee16dd2c97669ace4037412edParolaları güveni bir biçimde saklarken kullanılan yöntemlerden biri de özet algoritmalarından geçirerek elde edilen sonuçları veritabanında saklamak. Clear text ya da encoded olarak saklamaktan daha güvenli gözükse de bu yöntemin de kendine mahsus dezavantajları var.
Güçlü Bir Hashing Algoritması Kullanmak
Bir hashing algoritmasının gücü farklı girdilerden aynı çıktıyı yaratmaması ile ölçülebilir. Yani Collusion adı verilen vakaya neden olabilecek bir zayıflığı içermemesi gerekiyor. 2017 Şubat'ında Google mühendisleri 2011 yılından itibaren teorik olarak kırılabilmesinin muhtemel olduğu düşünülen SHA-1 algoritmasında iki farklı PDF dosyasını kullanarak aynı özet çıktısını üretmeyi başardı.
Ayrıntılara Netsparker Blogu'nda Sven Morgenroth tarafından kaleme alınan Collision Based Hashing Algorithm Disclosure yazısından ulaşabilirsiniz.
Bu ne demek? Bir başka zayıf özet algoritması olan MD5'den örnek verelim:
Örneğin aşağıdaki iki farklı string, MD5 özet fonksiyonundan geçirildiğinde aynı özet değerine ulaşılmaktadır:
Input 1:
d1 31 dd 02 c5 e6 ee c4 69 3d 9a 06 98 af f9 5c
2f ca b5 87 12 46 7e ab 40 04 58 3e b8 fb 7f 89
55 ad 34 06 09 f4 b3 02 83 e4 88 83 25 71 41 5a
08 51 25 e8 f7 cd c9 9f d9 1d bd f2 80 37 3c 5b
d8 82 3e 31 56 34 8f 5b ae 6d ac d4 36 c9 19 c6
dd 53 e2 b4 87 da 03 fd 02 39 63 06 d2 48 cd a0
e9 9f 33 42 0f 57 7e e8 ce 54 b6 70 80 a8 0d 1e
c6 98 21 bc b6 a8 83 93 96 f9 65 2b 6f f7 2a 70Input 2:
d1 31 dd 02 c5 e6 ee c4 69 3d 9a 06 98 af f9 5c
2f ca b5 07 12 46 7e ab 40 04 58 3e b8 fb 7f 89
55 ad 34 06 09 f4 b3 02 83 e4 88 83 25 f1 41 5a
08 51 25 e8 f7 cd c9 9f d9 1d bd 72 80 37 3c 5b
d8 82 3e 31 56 34 8f 5b ae 6d ac d4 36 c9 19 c6
dd 53 e2 34 87 da 03 fd 02 39 63 06 d2 48 cd a0
e9 9f 33 42 0f 57 7e e8 ce 54 b6 70 80 28 0d 1e
c6 98 21 bc b6 a8 83 93 96 f9 65 ab 6f f7 2a 70 Üretilen sonuç: 79054025255fb1a26e4bc422aef54eb4 (Hex Digest)
Sisteminizde iki farklı kullanıcınız varsa Kullanıcı 1'in parolası kırmızı ile boyanmış text, Kullanıcı 2'nin kullanıcı parolası mavi ile boyanmış text ise. Veritabanında aynı özet değer ile tutulduğundan ötürü Kullanıcı 2'nin parolası ile Kullanıcı 1 adına login gerçekleşecektir.
Güçlü Bir Hash Algoritması Yeterli mi?
Her ne kadar bir özet algoritmasının gücü farklı girdiler ile aynı çıktıyı üretmemesinde yatsa da, burada önemli bir ayrıntı var. Özet fonksiyonları aynı girdi için, aynı çıktıyı üretecektir.
Burada karşımıza her gün yeni biri ile uyandığımız ifşa listeleri ve önceden hesaplanmış hash tabloları (Rainbow Tables) çıkıyor.
Saldırganlar sık kullanılan parolalar ile ürettikleri hashler sonuçları ile ele geçirdikleri databaselerdeki hash'leri mukayese ederek parolanın clear text haline ulaşabilir.
Örneğin 123456qwerty gibi bir parolanın database'e kaydedilmiş SHA256 değeri b108fdf8c7b6bdd4e66a6e3e2d5dd3636456831fad30fda68a8f821eeee02714
Bunu kolaylıkla önceden hazırlanmış listelerden bulabilirsiniz:
Çözüm, parolaları hash ya da şifrelenmiş halde saklarken salt dediğimiz tuzlama yöntemi kullanmaktır. Salt özetle parolaya eklenen her bir kullanıcı için üretilmiş random değere verilen isimdir. Önceden hesaplanmış hash listelerinde bu değerler bilinemeyeceği için parolanın saltlandıktan sonra üretilen hash ile bu tablodaki hiçbir kayıt eşleşmeyecektir.
Tabii burada her kullanıcı için üretilen salt'ın benzersiz olması, mümkünse farklı bir tablo ya da veritabanında saklanması, kullanıcı parola değişikliği işlemi ile birlikte bu salt değerinin de değiştirilmesi gerekmektedir.
protected_password = hash(password + salt)(Yukarıdaki işlem iteratif olarak gerçekleştirilebilir.)
Parola saklama konusunda tercih edilen yöntemlerden bir diğeri de parolayı şifreleyerek saklama yöntemidir.
Bu hashing'e göre dezavantajları olan bir yöntemdir.
Şifrelemede kullanılan anahtarı elde eden bir saldırgan parolaları clear text olarak decrypt edebilir. Bir geliştirici olarak kullanıcı parolalarının clear text hallerine ihtiyaç duymayacaksanız hashing + salt yeterli olacaktır.
