Database de verileri şifrelemek mantıklı mı?

diocletian

Picopat
Katılım
1 Temmuz 2023
Mesajlar
538
Çözümler
1
Mesela her databaseden veri çektiğim veya benzer işlemler yaptığımda decrypt edecek. Bunun için pgp sistemi gibi yapmayı düşündüm. Mesela kullanıcı özel ve önemli bir bilgi girdi ben onu önce encrypt edip veri tabanına atıyorum. Bu güvenlik açısından mantıklı mı gereksiz efor mu olur? Teoride bunu yapabilirim ama bilemedim.

@533388 @bitwise sizin görüşleriniz önemli benim için.
 
@diocletian databasede sifrelemek derken mesela MD5, SHA1 gibi yöntemlerle şifre mail gibi verileri sifrelemekse evet mantıklı eğer veri tabanına sızma veya başka bir işlem olursa güvenlik açısından iyi olur. Ben PHP ile yaptığım bir sitede önce şifreyi sifreleyip DB'ye kaydediyordum sonra kullanıcının girdigi şifreyi de tekrar sifreleyip ikisini karşılaştırıyordum biraz saçma ama güzel.
 
@diocletian databasede sifrelemek derken mesela MD5, SHA1 gibi yöntemlerle şifre mail gibi verileri sifrelemekse evet mantıklı eğer veri tabanına sızma veya başka bir işlem olursa güvenlik açısından iyi olur. Ben PHP ile yaptığım bir sitede önce şifreyi sifreleyip DB'ye kaydediyordum sonra kullanıcının girdigi şifreyi de tekrar sifreleyip ikisini karşılaştırıyordum biraz saçma ama güzel.

Tam olarak onu kastediyordum. Teşekkürler cevap için.
 
@diocletian rica ederim. Hatta belki kendi şifreleme yöntemini de olusturursun kullanıcının girdigi her chat değeri için bir harf ya da rakam, sembol atarsın ve öyle kaydedirsin.
 
@diocletian rica ederim. Hatta belki kendi şifreleme yöntemini de olusturursun kullanıcının girdigi her chat değeri için bir harf ya da rakam, sembol atarsın ve öyle kaydedirsin.
Hocam onu düşündüm fakat şöyle bir sorun çıktı karşıma: kötü niyetli bir kullanıcı sürekli şifreyi kırmayı deneyip(bir script aracılığıyla, sonuçta yazılabilir bir kod) kırabilir(çok işlem gücü ve kim niye böyle bir şey yapsın ayrı konu) bunun önlemini nasıl alabilirim? şeyi düşündüm her login olma fonksiyonunda bir kullanıcıya özel değişkeni 1 arttırıp 10 olduğunda login fonksiyonu çalışmadan break etmeyi düşünüyorum ama hala oturtamadım kafamda, araştırıyorum.
 
Evet, precomputed saldiri yememek icin salt kullanmali ve md5, sha gibi hizli hashing fonksiyonlari kullanmamalisin. PBDKF ya da scrypt gibi slow hashing fonksiyonlarini yeterince randomize bir salt ile birlikte saklayabilirsin. Salt'in kendisini encrypt etmene gerek yok her zaman unique olduktan sonra. Bunu da duzgun bir password policy ve rotasyon kombini ile pekistirirsin guzel bir sistem olur.

Ayni IP adresinden ya da ayni kullanici sifresine yonelik fazlaca denemeye karsi request drop edersin. Ek olarak time based saldirilara karsi da savunma olarak sistemin cevap suresini sabitlersin. Yani bir sunucunun cevap verme suresinden credential combosunun DB ye hit edip etmedigini analiz eden toollar da var.

Ayrica gerekmedikce "sistemde bu kullanici bulunamadi" vs gibi hatalar return etmemelisin. ( SSO vs kullanmiyorsan ) "Hatali giris" vs gibi jenerik ve minimal bilgi iceren hatalar olunmali. Elinde email listesi bulunan bir saldirgan sisteminde hangi kullanicilara dair veri oldugunu anlayamamali.
 
Son düzenleme:
@bitwise hocam dedikleriniz iyi ama IP adresi değiştirmek artık kolay değil mi ipui degistirip tekrardan dener.
Ayni kullaniciya yonelik olup olmadigindan da analiz etmek gerekiyor bu yuzden. X sure icinde Y defa hatali denemede bloke eder ya da captcha challenge yaparsin. Ayni kullaniciya farkli geoIP lokasyonlarindan denemeleri de "tehdit" olarak algilayan mekanizmalar gelistirilebilir ki cogu firma yapiyor bunu.
 
Evet, precomputed saldiri yememek icin salt kullanmali ve md5, sha gibi hizli hashing fonksiyonlari kullanmamalisin. PBDKF ya da scrypt gibi slow hashing fonksiyonlarini yeterince randomize bir salt ile birlikte saklayabilirsin. Salt'in kendisini encrypt etmene gerek yok her zaman unique olduktan sonra. Bunu da duzgun bir password policy ve rotasyon kombini ile pekistirirsin guzel bir sistem olur.

Ayni IP adresinden ya da ayni kullanici sifresine yonelik fazlaca denemeye karsi request drop edersin. Ek olarak time based saldirilara karsi da savunma olarak sistemin cevap suresini sabitlersin. Yani bir sunucunun cevap verme suresinden credential combosunun DB ye hit edip etmedigini analiz eden toollar da var.

Ayrica gerekmedikce "sistemde bu kullanici bulunamadi" vs gibi hatalar return etmemelisin. ( SSO vs kullanmiyorsan ) "Hatali giris" vs gibi jenerik ve minimal bilgi iceren hatalar olunmali. Elinde email listesi bulunan bir saldirgan sisteminde hangi kullanicilara dair veri oldugunu anlayamamali.
Ayni kullaniciya yonelik olup olmadigindan da analiz etmek gerekiyor bu yuzden. X sure icinde Y defa hatali denemede bloke eder ya da captcha challenge yaparsin. Ayni kullaniciya farkli geoIP lokasyonlarindan denemeleri de "tehdit" olarak algilayan mekanizmalar gelistirilebilir ki cogu firma yapiyor bunu.
Teşekkürler cevap için. Dediklerinizi değerlendireceğim
 

Geri
Yukarı