Sunucu Tarafında Kullanıcı Doğrulama Yöntemleri ve Sertifika Bazlı Doğrulama

Sunucu Tarafında Kullanıcı Doğrulama Yöntemleri ve Sertifika Bazlı Doğrulama

Sunucularımız genellikle herkesin istek atmasına müsait olsa da her kullanıcının istediği bilgiye ulaşması sistemimizi ve diğer kullanıcıları tehlikeye sokabilir bu yüzden isteği atan kullanıcıyı doğrulamamız( authentication ) ve yetkilendirmemiz( authorization ) gerekmektedir. Temel olarak şu kimlik doğrulama yöntemleri kullanılabilir:

1 - Password Doğrulaması:

Kullanıcı kayıt olurken kullanıcı ismi, müşteri numarası, email adresi gibi benzersiz bir alan sahip olması istenir bu sayede kullanıcı sistemde doğrudan işaret edilebilir ve kullanıcıdan sadece kendisinin bileceği bir şifre tanımlaması istenir böylece kullanıcı adı bilinse bile şifresini sadece kendisi bileceği için sistem görece güvenli olur.

Veritabanında biraz önce bahsettiğimiz ID alanı herhangi bir gizleme yapılmadan tutulmasında son kullanıcı için bir sakınca yoktur çünkü bu değer şifreye sahip olmayan biri için önemsizdir fakat şifre açık bir şekilde(plain text) tutulduğunda veritabanına yapılacak saldırıda tüm kullanıcıların verisine artık tek hamlede erişilebilmesine yol açar. Bunun önüne geçmek için aşağıdaki gibi birkaç farklı şekilde koruma sağlayabiliriz.

Karıştırma:

Karıştırma yapılırken kelime katarındaki karakterler belli bir örüntüye göre yer değiştirilir yahut ötelenirler, çözümleme yapılırken de aynı algoritma tam tersi işletilerek katarın ilk haline ulaşılır.

Hash’leme:

Hash’leme, bir algoritma(hash function) ile bir karakter katarını(key) bir daha geri dönüştürülemeyecek şekilde yeni bir karakter katarına dönüştürme işlemidir. Şahsi algoritmanızı tasarlayarak yahut SHA, CRC, Fletcher, MD-2 gibi hazır algoritmalar kullanarak bu işlemi yapabiliriz. Zaruret olan bir durum olmadığı müddetçe farklı zümreler tarafından çok farklı koşullarda test edildiğinden dolayı bahsedilen hazır algoritmaların kullanılması tavsiye edilir.

Hash fonksiyonuna verilen ve içeriği aynı olan girdilerin çıktıları da aynıdır bu sayede sunucuya gönderilen şifre hash’lenerek veritabanında tutulan kullanıcı hash’i ile karşılaştırılabilir.

Hash-Salt:

Salt’lama bir karakter katarının bir yerine başka bir kelimeyi ekleme işlemine denir. En basit örneği kelimenin sonuna başka bir kelimeyi eklemektir.

Şifrelerde Hash’leme işlemi yapılsa bile elimizdeki tüm kombinasyonlar denenerek(brute force) hash’in gerçek karşılığı bir müddet sonra bulunabilir. Bu süreyi arttırmak için şifrelere salt’lama yapılır ve ardından hash’lenir, salt key’i sunucu ortamında tutulduğu için ayrık sistemlerde veritabanı ele geçirilse bile salt değeri bilinmez.

Şifre salt’landıktan sonra hash’lendiği için aynı hash’e sahip kayıtlardan sadece bir tanesinin bulunması hepsini ifşalayacaktır bundan dolayı salt’lar birbirinden farklı olacak şekilde oluşturulmalıdır. Hash’in ve Salt’ın aynı kayıt içinde tutulması başta güvenli değil gibi görünse de aslında rastgele olmayan salt kullanıldığında brute force ile salt bulunduktan sonra tüm şifrelerin çözülmesi oldukça hızlanacaktır ama salt’lar farklıysa her kayıt için tek tek salt-hash denemesinin yapılması oldukça maliyetli olacaktır.

2 - Token Doğrulaması:

Token’larla yapılan doğrulamayı basitçe iki arkadaş arasında bulunan gizli bir şifre olarak düşünebiliriz. Bu şifre uzaktan bakıldığında bir anlam ifade etmeyen, benzersiz olan bir karakter katarıdır. Sunucu bu token üretirken benzersiz olduğunu garanti eder ya da aynısından iki tane üretme olasılığı o kadar düşüktür ki bunu ihmal edebilir. Kullanıcı sunucuya istek üzerinden bu token’ı yollayarak kendini tanıtır. HTTP/HTTPS isteklerinde cookie, header, body yahut url içinde olabilir.

Token doğrulamasına çok benzer olarak ticket doğrulaması da vardır. Bunun için verebileceğimiz en popüler örnek Kerberos protokolüdür.

Kerberos network üzerinde kullanıcı doğrulaması yapılmasını sağlayan bir protokoldür. Kullanıcı gateway’le konuşur gibi ilk önce bir authentication sunucusuyla konuşur ve sunucudan bir ticket alır ardından bu ticket’ı konuşmak istediği sunucuya iletir ve aralarında veri akışı başlar.

3 - OAuth

Bazı durumlarda siz ne kadar güvenli bir sistem oluştursanız bile kullanıcı kişisel bilgilerini sisteminize girmek istemeyebilir. Böyle durumlarda kullanıcının güvenebileceği Google, Facebook, Apple gibi sistemlerden giriş yapmasını sağlayıp istediğimiz bilgilere onlar üzerinden ulaşabiliriz.

Sistemi basitçe şöyle anlatabiliriz:

Kullanıcı güvendiği sistemde kendini tanıtır ve o sistem bizim daha önce belirlediğimiz verilere ulaşabilmemizi sağlayacak bir token’ı bize iletir ve bu token ile kullanıcıyı doğrulayabilir ve verilerine ulaşabiliriz.

4 - Sertifika Bazlı doğrulama:

Sertifika bazlı doğrulamada kullanıcı sunucuya kullanıcı bilgisi ve şifre yahut token göndermek yerine tarafsız otoritelerce onaylanmış sertifika dosyasını göndererek bu sertifika trusted store denilen sertifika doğrulayıcısı tarafından doğrulanır ve kullanıcı kaynaklara erişebilir hale gelir.

Doğrulama yapmak için en çok kullanılan biri de HTTPS protokolünün zorunlu kıldığı SSL/TLS sertifikasıdır.

SSL/TLS’in Çalışma Şekli:

1. Kullanıcı “hello” mesajı yollayarak sunucuya güvenli session oluşturmak istediğini söyler
2. Server, server sertifikasını, CA bilgisini, ve public key’ini kullanıcıya gönderir
3. Kullanıcı sunucu sertifikasını trusted store içinde doğrulatır ve onay gelirse devam eder
4. Kullanıcı sunucuya sunucunun public key’ini kullanarak tek seferlik session key gönderir
5. Sunucu gelen key’i kendi private key’i ile şifreler ve kullanıcı ile sunucu arasında şifrelenmiş iletişim başlar

Bu SSL’in işleyişidir ve sadece kullanıcı sunucunun güvenli olduğunu doğrular, kullanıcıyı da doğrulamak için mutual SSL denilen, 3. adımdan sonra 2. ve 3.adımlar sunucu tarafında kullanıcı sertifikası için de yapan, başarılı olursa 4.adımdan devam eden yöntem kullanılmalıdır.

SSL’le Sunucu Tarafında Kullanıcı Doğrulaması

Sunucunun isteği kimin tarafından atıldığını bilebilmesi için kullanıcının da bir sertifikası olması gerekmektedir.

Sertifikanın önemli bazı alanları:

version: Protokolün versiyon numarasıdır.

certificate serial number: sertifikaya ait seri numarası.

Period of validity: sertifikanın geçerlilik süresi.

subject name: sertifika sahibinin bilgileri. İçinde sahibinin ülkesi, bölgesi, şehri, organizasyon ismi ve genel adı tutulabilir.

Signature: sertifikanın imzası.

SSL’le gelecek kullanıcılar, sertifikasında bulunan subject name , Signature veya Thumbprint gibi benzersiz olan alanlarına göre ayırt edilebilir, eğer kullanıcıya ait bir SSL sertifikası yoksa mutual SSL yönteminde sunucunun kendisi tarafından imzalanan(self-signed) bir sertifika oluşturulup kendisine gönderilebilir. Unutulmamalıdır ki self-signed yöntemi sadece localhost içinde çalışmaktadır.

Node.js için sertifika doğrulama örneği: https://github.com/julie-ng/nodejs-certificate-auth

C# için sertifika doğrulama örneği: https://github.com/niteshsinghal85/blogs/tree/main/CertificateAuthExample

Tavsiyelerim

Kullanıcıya ait bir ip adresinden birden fazla kullanıcı bilgisiyle doğrulamada kullanılabilecek hem kullanıcı hem de sunucu için en maliyetsiz olan yöntem, kullanıcıyı ilk önce hash-salt yöntemi ile doğruladıktan sonra ona kullanabileceği token vererek kullanıcıyı token ile doğrulamaktır çünkü kullanıcı sadece tek sefere mahsus giriş yapar ve ardından sistem tarafından otomatik olarak giriş yaptırtılabilir ama unutulmamalıdır ki bu girişler otomatik olarak yapılabileceği için kullanıcı bilgisi olmadan da giriş yapılmasına sebep olmaktadır, sunucu tarafında iste her girişte girilen şifreyle karşılaştırma yapmak için şifre hash’lenme gerekliliğini ortadan kaldıracaktır.

Eğer bir domain üzerinde sadece bir kullanıcı bulunacaksa sadece sertifika ile doğrulama yapılabilir çünkü sertifika geldiği ve gideceği adresi her zaman taahhüt eder.

Kaynakça: