Hash’in tuzu biberi
Şifreyi herkes Hash’ler, biz içine tuz biber ekmeye geldik. Türkçe deyimlere bu kadar güzel uyan bir algoritmik yapı daha yoktur büyük ihtimalle. Ben de Türkçe anlatabileceğim bu denli güzel bir konu bulmuşken ayrıca Medium yazılarıma da artık Türkçe devam etmek istiyorken bu pası kaçıramazdım. Uzuuun bir aradan sonra Yine, Yeni, Yeniden…
Önce biraz Hash’ten bahsedelim.
Hash
Hash, bir veri kümesinin belirli bir algoritma aracılığıyla sabit uzunlukta bir değere dönüştürülmesidir.
Yani GitHub şifrenizin yada bir Cem Yılmaz filminin yada Milena’ya yazılmış mektupların belli büyüklükte bir string çıktısı.
Peki bu çıktının özelliği ne? Bu çıktı öncelikle benzersiz. Bu çıktıdan bir tane daha yok. Örneğin, SHA-256 algoritması ile GORA filminin 2 saat 7 dakika 33 saniye süren versiyonunun dosyasını Hash’lediğiniz, ardından filmin sonundan bir saniye kırpıp 2 saat 7 dakika 32 saniyelik bir versiyonunu oluşturup o dosyayı Hash’lediniz, çıkan iki Hash değeri farklı olacaktır. Dosyanın içeriğindeki en ufak değişiklik bile birbirinden tamamen alakasız başka bir Hash değeri almanıza sebep olacaktır. Aslında bu muazzam bir güvenlik yöntemi ancak o kısma birazdan geleceğiz.
Bu çıktının bir diğer önemli özelliği ise veriye dair bir bilgi içermiyor olması. Mesela bir sanatçının bir albümünü Hash’ledik diyelim. Çıkan çıktıdan sanatçının kim olduğuna dair şarkılarına ve o şarkıların sözlerine dair en ufak bir bilgi edinemeyiz. Bu da günün sonunda Hash çıktısının veri bütünüyle bir alakası olmadığını ve sadece o veri bütününü temsil ettiği sonucuna ulaştırır bizleri.
İşin yukarıda bahsettiğim güvenlik boyutuna gelecek olursak. Hash’in benzersiz olması nasıl bu kadar büyük bir güvenlik yöntemi olabilir? Bir örnekle hemen açıklayayım. Bir banka bütün para transferlerini bir tabloda “Ali Veli’ye 100TL yolladı” şeklinde tutuyor olsun. Aynı zamanda da bunları Hash’leyerek farklı bir tabloda tutuyor olsun. Bu verinin hash çıktısı şu şekilde olacaktır : “63a0c77f7650b56fcd843777aab3f9a1380c187825ec788a4096334accb67594” bu değer. Kötü niyetli bir kişi bu veritabanını ele geçirmiş olsun. Tabloları inceleyip “Ali Veli’ye 100TL yolladı” datasını “Ali Veli’ye 100.000TL yolladı” olarak değiştirsin. Eğer banka bu verileri Hash’lemeden tutarsa Ali’nin Veli’ye ne kadar yolladığını bilemeyeceği için Veli’ye 100.000TL ödemek zorunda ancak bankamız verilerini Hash’leyerek tuttuğu için “Ali Veli’ye 100.000TL yolladı” datasının Hash’inin “b86ace14d9c3b6e9f6772355d281263f7bd643622d5d42296224e937462a9480” olduğunu görecek ve 100.000TL’yi vermek zorunda kalmayacak. Temelde, Bitcoin güvenliğini bu şekilde sağlar.
Hash’i tuzlamaya geçmeden güvenlik konusundan ve Hash çıktısının bazen içerdiği veriye dair bilgi verebileceğinden bahseden muazzam bir video iliştiriyorum buraya.
hafif programming kanalını ve hafif üsluplarıyla (kendi deyimleri) Özgür ve Görkem beyleri dinlemenizi, izlemenizi ve beğenmenizi şiddetle tavsiye ediyorum.
Dönelim konumuza, biz bu Hash’i neden tuzlarız?
Salting
Madem veritabanı kaptırmaktan yola çıktık oradan da gidelim. Diyelim ki 100'lerce kullanıcısı olan bi veritabanınız var. Bu veritabanının da 3–4 ortamı var. Bunlar prod, pre-prod, test ve dev. Siz de düzenli aralıklarla prod veritabanı ile diğer veritabanlarını eziyorsunuz. Bu durumda diğer veritabanlarını prod ortamı koruduğunuz gibi korumuyorsanız zaten büyük bir güvenlik zafiyeti.
Örnek o ya bir güvenlik zafiyeti de bizden olsun dev ve test ortamları geliştiriciler ve analistler için kolaylaştırılmış bir yapıda ve bütün kullanıcıların şifreleri aynı. Artık bu şifreler veritabanında Hash’li bile olsa büyük bir güvenlik zafiyeti. Çünkü bir kişinin bile şifresi öğrenilirse bütün şifreler ve dolayısı ile bütün Hash’ler aynı olacağını için veritabanına giren kişi bütün kullanıcıların tek bir şifre ile yönetildiğini anlar.
İşte tam bu anda için işine Salted Hash giriyor. Biz bu dataları en başta veritabanına yazarken önce tuzlayıp sonra Hash’leyeceğiz.
Peki nasıl yapacağız?
Bunun birçok yolu var bunlardan biri, her bir kullanıcı için belli uzunlukta rastgele bir kelime oluşturmak. Oluşturulan kelimeyi şifrenin önüne, arkasına yada ortasına ekleyip şifreyi öyle Hash’lemek. Artık bütün şifreler aynı bile olsa veritabanında hepsinin Hash’li hali farklı şekilde tutulacak. Buradaki kritik olay oluşturulan rastgele kelimeyi de farklı bir tabloda saklamak. Veritabanını çalan kişi bu kelimeyi bulsa bile tuzlama algoritmasına sahip olmayacağız için şifreyi güvende tutma işini büyük ölçüde artırmış oluruz.
Peki ya biberleme?
Peppering
Örneğimizle devam edelim. Dedik ya tuzlama yöntemi ile güvenliği büyük ölçüde artırıyoruz. Peki nasıl daha fazla artırabiliriz güvenliği?,
Kaynak koda sabit bir değer ekleyerek. Yani Hash’e biber ekerek. Şu şekilde açıklayayım.
Kaynak kodumuzu veritabanımızla aynı yerde tutmadığımız senaryoda veritabanı kaptırılırsa sadece veriler gider. Biz bu şifrelere önce rastgele bir kelime ekliyoruz. Sonra Hash’liyoruz. Ancak şifrelediğimiz kelimeyi de aynı veritabanında saklıyoruz. Ancak şifre veritabanına gitmeden önce kaynak kodda sabit bir kelime eklesek ve bu sabit kelimeyi hiçbir zaman veritabanına kaydetmezsek eğer, şifre biberlenmiş ve Hash’lenmiş oluyor.
Hem tuzlayıp hem biberlediğimiz Hash tadından yenmez :d
Kısaca Hash’in tuzu ve biberi böyle. O kadar tuz biber dedik madem yazıyı tuz biber olmadan bitirmeyelim. Sevgiyle…
