Womenes
Merhaba,
bir sifreleme isleminde arka planda yapilan calismalar (sifrelemenin teknigi basta olmak üzere, sifreleme tipine, boyutlara ve detayina göre) teknik altyapi ile paraleldir ve olmak zorundaligi vardir günümüzde. Bu bilgi sabitken degisimini yapabildigimiz birtakim uygulama adimlari da mevcut.
600-1200 ms'e cikmasi gayet normal cünkü nasil bir sifreleme yaptiysaniz ona görede zaman kaybi oluyor. Bu konuya neredeyse herkesin kendine göre bir yaklasimi mevcut.
bcrypt'in wikipedia aciklamasinda yanlis okumadiysam "bcrypt is a password-hashing function" diye aciklama var. @Halil Han BADEM 'in dedigi gibi sifrelerin üzerine uygulanma..
Her ne kadar egitim ve ögrenme amacli olsanizda genel kabul görmüs, NIST ve BSI tarafindan standart olarakda kabul edilip tavsiye edilen RSA (en az 4096 bit key) gibi güclü bir sifreleme edinmenizde fayda var.
1 - JavaScript icin Formül ile aciklama
2 - Npm ekleyerek paket ile kullanimi (örnekli)
Private/Public Key sifreleme ile sifrelenmis bir objeyi tekrar sifrelemeye ihtiyaciniz yok. Ekstra bir komponente de ihtiyaciniz olmayacak dolayisiyla. Ancak bunun yaninda diger sütunlarinizda da gizli olmasini istediginiz bilgiler varsa, sifrelemek yerine yukarida bahsettigim gibi uygulama adimlarina yönelik degisimler yapilabilir.
Öneri 1 :
- Tablo adini "Status" olarak degil "Table_1" veya bakildiginda anlasilamayacak sekilde isimlendirme yapin.
- Ismini degistirdiginiz "Status" tablonuzdaki kullanicinin arkadaslik durumlarinda tuttugunuz veriyi;
- eger veri integer tipindeyse kendi olusturmus oldugunuz (ya da olusturacaginiz) bir yöntemle (mesela sayiya sadece sizin bildiginiz bir sayiyi ekleyerek binary seklinde cevirerek tutmak) binary sekline getirip öyle tutun.
- eger veri bir string ise yukarida Integer örnegindeki gibi farkli sekilde kendi yöntemlerinizi uygulayarak saklayabilirsiniz.
Yukaridaki "Öneri 1" adimda sifrelemeden yapilan bir ek adimdir ve ele gecirilen bir veritabaninda ele geciren kisinin veritabanini izlemeden ve test yapmadan anlamasi mümkün degildir. Ve bu sekilde daha da ileri adimlarida mevcuttur.
Öneri 2 :
- Ileride gercekten önem arz edecek ancak fazla sayida ya da boyutta olmayan bir bilgiyi veritabaninda tutmayin. Bu da tabii ki domain üstünde dosya ve klasör yetkilendirmesi de gerektirir.
- Kullanici giris yapar
- Giris basariliysa veritabaninda bir Temp tablosu olusturulur. (Temp tablosu yerine kendi Status tablosu da olabilir giriste bilgiler doldurulmak üzere.)
- Domain üzerinde kullanicinin kendine ait olan klasörden degistirilerek saklanmis veriler yine tersine cevirilerek gecici Temp tablosuna aktarilir ve kullanicinin hesabina iletilir.
- Kullanici cikis yaparken Temp tablsoundan "Status" verileri tekrar silinir. (Temp tablosu yerine kendi Status tablosu da olabilir cikista silinmek üzere.)
"Öneri 2" de sistemin kendi altyapisini kullanilarak da islemler güvenli sekilde yürütülebilir.
Öneri 3 :
- Eger güvenlik agirlikli calisacak ve teknik yeterliliginiz varsa buna uygun cözümlerde mevcut tabiiki,
- Bahsettiginiz sistemde kendinize (firmaniza, domaininize ya da vs.) ait önceden olusturmus oldugunuz bir RSA anahtariniz vardir. Tabii ki yine Private/Public olarak.
- Kullanici register islemi yaparken ilk önce sizin Private keyinizi de dahil ederek sifreleme yapar. Public key'i ya da Private keyi'i ele gecse dahi sizin Private/Public keyiniz ele gecmeden kendisi dahil acamaz.
- Kullaniciya ait özel kalmasi gereken bilgiler (Örnek Status tablonuz) de yine ayni mekanizmayla sifrelenerek saklanir. Yani veriler kendi Private key'i ile sifrelenmis sekilde saklanir.
- Kullanici giris yaptiginda sifrelenmis bilgileri kendi RSA bilgileri ve güvenlik icin olusturmus oldugunuz RSA bilgileriyle diger özel bilgiler acilir.
"Öneri 3" de yer alan basit etkilesimli capraz RSA sifrelemedir. Teknik altyapisi iyi olan sunucu ve sistemlerde size neredeyse sorun yasatmayacak düzeyde de hizmet eder.
Diger yandan bunlara ek olarak kendi sisteminize, domaininize arka planda calisacak bir servis ile bu yükleri dengeleyebilirsiniz. Kullanici girisini kontrol ederken paralel olarak da servis gerekli decrypt islemlerinizi async yaparak
yine ayni ya da yakin sürelerde kullaniciya bu sekilde hizmet saglayabilirsiniz.
Kendi uzman oldugunuz programlama dilini gecici olarak birakip sadece bu nedenle araya farkli bir yazilim dili (C/C++) uygulamasi gelistirip entegre etmek sahsim adina söylemek gerekirse dogru degil. Benzer ya da daha güclü sorunlari o yazilim diliyle de yasayabilirsiniz. Bunun nedeni sizin güvenlik kavramina nasil baktiginiz ve nasil tasarladiginizdir.
Kendi gercek yasam örnegimi aciklayim. Bir RSA 4096 bit key sifrelemesi ile kullanici güvenligini 3 capraz güclü RSA anahtarlariyla sifreledim.
- Benim anahtarim olmadan tek basina hareket edemeyen bir kullanici,
- kullanicinin veri güvenligi tehlikede olsa bile yine benim anahtarim olmadan görüntülenemeyen bilgiler,
- Veritabanindan veriler calinsa bile ve hatta benim RSA anahtarlarim güvenlik tehdidi altinda olsa bile yine kullanici anahtari olmadan acilamayan bilgiler..
- Benim ve kullanicinin veri güvenligi tehlikede olsa bile sisteme ait olan RSA anahtarlari olmadan yine acilamayan bilgiler.
Ekstralarida mevcuttur. Örnek olarak "Salting", ileri düzey "chiper", SHA256 hash ve yerel düzey güvenlik politikalari.
Yukaridaki örnekler cogaltilabilir ama inanin bu kadari bile cok uzun bir yazi haline geldi. Sonuc olarak güvenlik saglamak, zaman ve teknik altyapidan fedakarlik etmek anlamina da gelmektedir. Ya da yanlis tasarlanmis yapilarin sistem kaynaklarini dogru kullanmadigi anlaminda gelmektedir.
Saygilarimla
