Güvenli bir veritabanında saklanıyorsa şifreler neden şifrelenmelidir?

Bir web servisim var. Şu anda, sunucumdaki MySQL tablosunda düz metin olarak depolanmış şifrelerim var . Bunun en iyi uygulama olmadığını biliyorum ve bu yüzden üzerinde çalışıyorum.

Güvenli bir veritabanında saklanıyorsa şifreler neden şifrelenmelidir? Birisi veritabanıma girerse, herkesin şifresini alacağının farkındayım. Fakat birileri veritabanıma girerse, örneğin verileri silerken başka problemlerim var.

Aklıma gelen senaryo, saldırıya uğramış olmanız. Birkaç saat önce bir veritabanını geri yüklüyorsun ve her şey yolunda. Ancak, şifreleriniz düz metinse ... Hırsızın tüm şifreleri vardır ve hepsini sıfırlamanız gerekir. Kullanıcılarınıza güçlük.

Şifreler şifrelenmişse, önceki veritabanına geri yükleyebilirsiniz. Bu doğru düşünme mi?

Öncelikle, salt okunur erişim haklarında okuma yazma işleminden daha özgür olmalısınız. Bir bilgisayar korsanının verilerinize erişimi olabilir ancak bu bilgileri düzenleyemiyor olabilir.

Ama, daha da önemlisi, bu seninle ilgili değil. Birisi veritabanınıza tam olarak erişebiliyorsa mahvolmanız gerçeği önemli değildir. Çok daha önemli, kullanıcının verileridir.

Veritabanınızı kurtarırsanız, bilgisayar korsanı yine de kullanıcı hesabınıza erişebilir.

Ve başka ne biliyor kim? Ya Google’da aynı şifreyi kullanıyorlarsa? Veya PayPal? Bu, bilgisayar korsanının annesinin kızlık soyadı veya kredi kartının son 4 hanesine erişmesini sağlarsa?

Ya bu onları başka hesaplara sokarsa? Kullanıcı destek sisteminden geçmek ve daha fazla bilgi almak için bilgisayar korsanlarının yanına koymayın .

Sadece ... sadece yapma. Bu, kullanıcının özel bilgileridir ve görebilmeniz gerekmez. Aynı zamanda senin ünün. Şifrele.

EDIT: Ekstra bir yorum, gelecekteki okuyucuların her cevabı ve yorumları okumasını engellemek için

Şifreleyecekseniz (en kesin anlamıyla), o zaman herkese açık ve özel bir anahtar çifti kullanmanız gerekir ; bu iyi, ancak hayatı hem siz hem de kullanıcı için biraz daha zorlaştırır.

Daha basit ve aynı derecede etkili bir çözüm, şifreyi rastgele-tuzlamak ve hash etmektir. Tek başına karmaşa yetmez; Eğer kullanıcı ortak bir şifre kullanıyorsa, basit bir internet araması ile kolayca bulunabilecek olan ters karma tablolarda görünecektir.

Eğer saldırıya uğrarsanız, siteyi yedeklemelerden geri yükleyebilir ve düzeltebilirsiniz. Ancak bilgisayar korsanının hala herkesin hesabına şifreleri var! Bu olayın belgelenmiş gerçek dünya örnekleri var (Sony, Linked-in), eğer şifre tabloları uygun şekilde karıştırılmış ve tuzlanmışsa, sevice'yi güvenli bir şekilde geri yüklemek ve hızlıca geri yüklemek çok daha kolay olurdu.

Muhtemelen , saldırıya uğrayacağınızı varsaymak ve yedekleme stratejinizi tasarlamak ve bu varsayımları dikkate alarak hassas verileri şifrelemek iyi bir fikirdir . Ve sadece koruman gereken bilgisayar korsanları değil. Hoşnutsuz, dürüst olmayan veya sadece ipucu olmayan çalışanlar düz metin şifreler verebilir.

Sıkıştırma olmadan, şifresini değiştirinceye kadar herkes için erişimi devre dışı bırakmanız gerekir (bu mümkün olsa bile herkes için büyük bir baş ağrısı olacaktır). Parolalar şifrelenmiş ve tuzlanmışsa, web hizmetini geri yükleyebilirsiniz ve bir saldırganın insanların hesaplarına erişmesi çok daha zor olacaktır.

Düzgün bir şekilde karıştırılmış ve tuzlanmış bir şifre temelde tek yönlüdür. Şifreyi karma şifreden kolayca tahmin edemezsiniz. Siz bile, servis sağlayıcı tahmin edemediğinden, yalnızca sıfırlayabilirsiniz.

Ayrıca, Elin'in dediği gibi, kendi karmaşınızı (ya da şifrelemenizi) yuvarlamaya çalışmayın. Standart bir kütüphane kullanın.

Fakat eğer birisi veritabanıma girerse, yani verileri silerken başka problemlerim var.

Bu sorunlarla ilgili değil sen onu tüm diğer kullanıcılar için neden olabilecek sorunlar hakkında var, var. Bu, sitede çalışan kişilerin orada depolanan verileri kötüye kullanmaları için cezbedilmeyi (veya daha da kötüsü, potansiyel yükümlülüğü) kaldırmakla ilgilidir.

İnsanlar bile, bak gereken farklı sistemlerde farklı şifreler kullanmak, gerçeklik olmasıdır yok .

... ve şifrelere sahip olmak çok kolay olduğu için, sektördeki en iyi uygulamaları takip etmemeniz için hiçbir bahaneniz yok.

Veri silmek gibi göze çarpan saldırılar genellikle amatör şeylerdir ve endişelerinizin en küçüğüdür. Deneyimli bir saldırganın yapacağı ilk şeylerden biri meşru bir erişim elde etmeye çalışmaktır, bu yüzden kullandığı orijinal güvenlik açığını düzeltseniz bile, yine de içeri girebilir. istediğini yerine getirir. Şifreleri bozulmadan bırakarak, potansiyel olarak işini daha kolay hale getirdin. Ayrıca gelecekteki kötü niyetli davranışlarını tespit etmeyi ve izole etmeyi zorlaştırdın.

Ayrıca, tüm ödünler size tam kabuk erişimi sağlamaz. Bir saldırganın kullandığı güvenlik açığı yalnızca userstablodaki salt okunur bir SQL enjeksiyonu ise ? Şifreleri bozulmadan bırakmak sadece ona tam erişim sağladı.

Bu, kullanıcı verilerinizi korumakla ilgili sorumluluğunuz hakkındaki diğer cevapların nedenlerine ek olarak verilir. Demek istediğim, kaybedecek bir şeyi olan sadece kullanıcılarınız değil.

Buraya sorunun kendisindeki bir yanlışlık hakkında cevap yazmam gerekiyor. Şifrelerin şifrelenmesi gerekip gerekmediğini soruyorsunuz. Hiç kimse şifreleri şifrelemez; hiç kimse, tek amacı şifreleri şifrelemek olan Firefox Sync ve Roboform gibi hizmetler ve programlar dışında.

Tanımlara bir göz atalım:

Şifrelemede, şifreleme, mesajları (veya bilgileri) yalnızca yetkili tarafların okuyabileceği şekilde kodlama işlemidir.

Ve karma:

Bir karma işlevi, isteğe bağlı uzunluktaki verileri sabit uzunluktaki verilerle eşleyen herhangi bir algoritmadır.

Başka bir deyişle, şifreleme iki yönlü bir dönüşümdür ve karma ise tek yönlü bir dönüşümdür, bu nedenle bunları daha sonra görüntülemek için şifresini çözmüyorsanız, şifreleme değildir.

Ayrıca, sadece karma, tuz değil ! Şifrelerinizi almadan önce bu sayfanın tamamını okuyun.

OP'nin şimdi aradığı karma algoritmalara gelince, SHA-384 veya SHA-512 gibi üst seviye SHA-2 değişkenlerinden herhangi birini öneririm.

Ve karma tur kullandığınızdan emin olun . Bir kez karma yapma, birden çok kez karma.

Giriş işleminizi daha güvenli hale getirmek için bu sayfayı okumayı düşünün .

İkincisi, veritabanınız asla yeterince güvenli olamaz. Her zaman güvenlik delikleri ve sürekli gelişen riskler olacaktır. Murphy Yasasını takip etmeli ve her zaman en kötü olaya hazır olmalısınız.

Diğer noktalar pdr markaları Başka tam olarak ne der gibidir: sosyal mühendislik kullanarak her web sitesi için aynı parolayı kullanan kişiler, hacker, vb vb daha fazla bilgi elde etmek

Burada tehlikede olan önemli bir ilke var. Kullanıcı şifresini bilen bir işi olan sadece bir kişi var. Bu kullanıcı. Eşleri / kocası, doktorları ve hatta papazları değil.

Kesinlikle kullandıkları hizmetten sorumlu programcı, veritabanı yöneticisi veya sistem teknisyeni içermez. Programcının, kullanıcının gerçekten bir sorunu çözmek için önemsiz bir sorun olan parolayı gerçekten bildiğini kanıtlama sorumluluğu bulunduğundan, bu bir zorluk yaratır.

Saf çözüm, kullanıcının bazı yeni ve öngörülemeyen verilerle zorlandığı bir mekanizmaya sahip olmak ve daha sonra bu verilere ve şifrelerine dayanan bir yanıt döndürmek zorunda kalmaktır. Bunun bir uygulaması, kullanıcıdan yeni oluşturulan bazı verileri dijital imzasıyla dijital olarak imzalamasını istemek ve matematiksel olarak hesabı oluşturmak için kullandıkları şifreleme anahtar çiftini kullandıklarını kanıtlayabiliriz.

Uygulamada, saf çözümler önemli müşteri tarafı altyapısı ve işlemesi gerektirir ve birçok web sitesi için bu genellikle korunan veriler için uygun değildir.

Daha yaygın bir çözüm şöyle olacaktır:

Uygulamada bir şifrenin ilk alındığı noktada, şifre, uygulamanın rasgele 'tuz' değeri ile birlikte karma fonksiyonuna geçirilir.

Daha sonra orijinal dizgenin hafızasına yazılır ve bu noktadan itibaren, tuzlanmış karma veri tabanında depolanır veya veri tabanı kaydı ile karşılaştırılır.

Burada güvenliği sağlayan kilit hususlar şunlardır:

1. Karma bilgisi, doğrudan kimlik doğrulama sağlamaz.
2. Parolanın karma değerinden ters hesaplanması pratik değildir.
3. Gökkuşağı tablolarının kullanımı (uzun parola listeleri ve hesaplanan karmaları) daha zorlaştırılmıştır, çünkü elde edilen karma hem kullanıcı adına hem de parolaya bağlıdır.

İkinci bir savunma katmanı olarak şifreleri "şifrelemeniz" (aslında "karma" yapmanız gerekir), bu şifreleri ikinci bir savunma katmanı olarak gösterir : bu, veritabanını salt okunur bir şekilde gösteren bir saldırganın yükselmesini önlemek içindir. Bu, okuma-yazma erişimine girer ve kesin olarak verileri değiştirmeye başlar. Salt okunur kısmi ihlaller, gerçek dünyada meydana gelir, örneğin salt okunur erişimli bir hesaptan yapılan bazı SQL enjeksiyon saldırılarıyla veya atılan bir sabit diski veya eski bir yedekleme teypini çöp kutusundan alarak. Orada bu konuda uzun yazdım .

Parolaları doğru şekilde şifrelemek için bu cevaba bakınız . Bu tuzları, yinelemeleri ve hepsinden, en, içerir değil kendi algoritmaları (ev yapımı şifreleme felaket için emin bir tarifi) icat.

Başkalarının söylediklerini tekrarlamayacağım, ancak PHP 5.3.8 veya daha iyisine sahip olduğunuzu varsayarak bcrypt, şifrelerinizi saklamak için PHP yerel kullanıyor olmalısınız . Bu PHP içine inşa edilmiştir. PHP 5.5'iniz varsa, mevcut en iyi şifre sabitini kullanabilirsiniz. 5.3.8 yapmak veya 5.5 gibi davranmak için bir kütüphane de kullanabilirsiniz.

Yığın Taşması sorusu PHP'de şifreleri toplamak için bcrypt nasıl kullanılır? açıklar ve diğer cevaplar daha fazla açıklar. Lütfen bunu kendiniz yapmaya çalışmayın.

Bu cevapta belirtilen sebeplerden ötürü pdr'nin cevabına katılıyorum.

Aşağıdakileri ekleyeceğim: Yapmanız gereken kolay ve genel olarak herhangi bir uygulama için en iyi uygulama olarak kabul ediliyor. Daha spesifik olarak, şifreler her zaman kalıcı depolamaya yazmadan önce her zaman tuzlanmalı ve karıştırılmalıdır . Tuzlama ve iyi bir şifreleme hash (bazı popüler dillerde ücretsiz kaynak kodu da sağlar) seçmenin önemi hakkında iyi bir referans: https://crackstation.net/hashing-security.htm

Az miktarda ekstra geliştirme süresi, kullanıcılarınıza sağladığı korumaya ve bir geliştirici olarak ününüze değer.

Aklıma gelen senaryo, saldırıya uğramış olmanız.

Düşünmeniz gereken başka bir senaryo: Birisi DBA'nızı attı (veya DB’nizde belirli sorguları çalıştırabilecek biri varsa), kullanıcıların şifrelerini vermek için 100 dolar. Veya sosyal mühendisler bunu yapmak için bazı stajyerler.

Daha sonra bu şifreleri kullanıcının Gmail’ine veya ticari siteye giriş yapmak için kullanırlar (çünkü insanlar ... akıllıdan daha az diyebiliriz - ve aynı şifreyi siteler arasında kullanırlar).

Ardından kızgın kullanıcı şirketinizi şifresini ifşa ettiği için dava eder.

NOBODY (şirketinizdeki kişiler dahil) düz metin şifresini okuyabilmelidir. Hiç. Bunun için meşru bir iş veya teknik ihtiyaç yoktur.

Birincisi, veritabanı yöneticileri bile kullanıcıların şifrelerini görmemelidir. Bunları karma yapmak, yöneticinin bir şifreye bakmaya karar vermesi ve kullanıcılarının hesabına giriş yapması durumunda bunu önleyecektir.

Peki, henüz kimsenin bundan bahsetmemesi şaşırtıcı, peki ya veritabanınızın FİZİKSEL güvenliği?

Dünyadaki en iyi BT güvenliğine sahip olabilirsiniz, ancak bu, depolama ortamınıza fiziksel olarak erişebilecek birini durdurmaz. Ekibiniz bu öğleden sonra Superbowl'u kazandığında ve ofisinizin / barındırma sağlayıcınızın bulunduğu şehir merkezindeki küçük bir isyan patladığında ne olur? (ABD'deki iki büyük BT alanı olan Seattle-Denver olduğu göz önüne alındığında, bunun mantıksız olduğunu sanmıyorum). Mafya binanıza çarptı ve yetkililer boğulmuş halde iken, birisi donanımınızın bir kısmını üzerinde açık metin şifreleri içeren bir DB ile kaptı?

Bazı üst düzey yöneticiler yasadışı borsa işlemlerini yürütmek için şirketteki pozisyonunu kullandığı için Federaller ekipmanınızı gösterip ele geçirdiğinde ne olur? Daha sonra Federaller bu şifreleri, yanlış bir şey yapmamış olsalar da müşterilerinizi araştırmak için kullanır. Sonra onları savunmasız bırakan SEN olduğunun farkındalar .

BT departmanınız, eski sürücüleri stajyere "dağıtmadan" önce DB'nizi tutan eski RAID sürücülerini silmeyi unuttuğunda ne olur, sonra yurt oda arkadaşlarının geride bıraktıklarını bulup, yapabileceklerini anlarlar. "Sat" ve asla geri izlemeyecek mi?

DB Sunucunuz bir anakartı patlattığında, BT yeni sunucunuza bir görüntü geri yüklerse ve eski sunucunun "karkası" geri dönüşüm yığınında atılırsa ne olur? Bu sürücüler hala iyi ve bu veriler hala orada.

İyi bir mimar, güvenliğin, daha sonra güvenlik duvarları ve operasyon politikaları ile "kenetleneceğiniz" bir şey olmadığını bilir. Güvenlik, en başından beri tasarımın temel bir parçası olmalıdır ve bu, şifreler tek yönlü olarak şifrelenmiştir , ASLA şifreleme yapılmadan iletilmez (kendi veri merkezlerinde bile) ve asla kurtarılamaz. Alınabilecek herhangi bir şey tehlikeye girebilir.

Veritabanınızın saldırıya uğradığı durumu bir kenara koymak: Bir müşteri olarak şifrenizi bilmenizi istemem. Bir istek üzerine geldiğinde şifreyi kolayca alabileceğinizi biliyorum, ancak istediğiniz zaman sorgulamak için elinizde olmadığında daha iyi bir his var.

Parolalar düz metin olarak saklanırsa, kullanıcı tarafından biliniyor ve bu tabloya erişimi olan herkes anlamına gelir. Kullanıcıları ve şifreleri uygulama hakkındaki tüm fikir, sisteminizde belirli bir oturumun hem gizlilik hem de güvenlik nedenleriyle söz konusu bir kişiye ait olduğundan emin olmaktır.

Eğer bir kullanıcı adı / şifre bir grup insan tarafından biliniyorsa, bir kişiyi kesin olarak tanımlamak işe yaramaz hale gelir ve bu kimlik hırsızlığı, sahtekarlık ...

Bu yüzden, şifreleri, okuma yeteneğine sahip olmadan doğrulayabilmeniz için asimetrik şifreleme protokolleri kullanılarak saklanır.

Bence soruda temel bir kusur var. Gerçek şu ki, "güvenli veritabanı" diye bir şey yoktur. Kötü niyetli kullanıcıların sunucularınızdaki rasgele verilere erişmesine izin verebilecek bir yerde sisteminizde kusurlar olduğu belirtilmelidir. Heartbleed , araştırmacılar tarafından fark edilmeden önce iki yıldan fazla süredir vahşi olan bir istismar olarak, mükemmel bir durum. Verileri korumak için nasıl yapılacağını bildiğiniz her şeyi yapmış olabilirsiniz, ancak sunucularınızda kullandığınız diğer tüm yazılım parçalarını ve etkileşime girdikleri karmaşık yolları hesaba katamazsınız.

Birisi seninle ilgilenirse, saldırıya uğrayacaksın . İlk etapta saldırıya uğramamak için elinizden gelenin en iyisini yapmak, ancak mümkün olduğu kadar çok engelle karşılaşarak meydana gelen zararı azaltmak da önemlidir. Şifrelerinizi karıştırın. Kurulumu o kadar zor değil ve kullanıcılarına gizliliklerini ciddiye almamak suretiyle bir kötülük yapıyorsunuz. Kötü niyetli saldırılara karşı bir şekilde daha iyi korumalı olduğunuzu düşünmek , hepsi saldırıya uğramış olan Yahoo , Sony veya Target gibi şirketlerden daha iyidir .