DB şifrelerini koruma


18

Gördüğüm çoğu PHP / MySQL tabanlı web sitesinin yapısına baktığımızda, günlük kazma bilgilerini saklayan bir kurulum veya yapılandırma dosyası olduğu için biraz kazarsanız veritabanı şifresini ayırt etmek çok zor değil gibi görünüyor DB içine. Veritabanımın ayrıcalıklarının uzak istekler için uygun şekilde kısıtlandığından emin olmanın temel önlemi dışında, bu bilgileri korumak için kendi projelerimde uygulayabileceğim seçenekler nelerdir?


1
Açıklığa kavuşturmak için - web sitesine veritabanına giriş yapmak için kimlik bilgilerini depolamayı soruyorsunuz ve web sitesinin kullanıcıları için şifreleri veritabanında nasıl düzgün bir şekilde saklayacağınızı soruyorsunuz, değil mi?
Joe

Doğru; Ben de buna katılıyorum.
Kaji

Yanıtlar:


10

Parolaların depolanması hakkında doğrudan bir yanıt değil, ancak webapps oluştururken genellikle en az iki veritabanı bağlantısı kullanıyorum - biri kullanıcılarla ilgili etkinlikler için zamanın% 99'unu kısıtlı ayrıcalıklarla ve diğeri 'yönetici' işlevi için kullanılıyor (kullanıcıları silme vb.).

Başka birisinin paketini yüklediğim birkaç durumda, iki örnek yükleyeceğim ... genel kullanıcı türü şeyleri yapmak için yalnızca veritabanı erişimine sahip halka açık bir örnek ve IP ile kısıtlanmış ikinci bir örnek herhangi bir 'yönetici' türü etkinlik için kullanılması gereken yerel alt ağım (muhtemelen farklı bir makinede bile). Her ikisi de tablolar, vb değiştirmek için erişim var, ama ... Ben webapp veteriner henüz kendi güncelleme görevleri çalıştırmak için izin daha yerel veritabanı araçları üzerinden gitmek istiyorum.

Gerçi daha da ileriye gidebilir ve belirli görevler için daha fazla bağlantı ekleyebilirsiniz ... böylece kullanıcı oluşturma ve şifre yönetimi görevleri, kullanıcı tablolarında ekstra ayrıcalıklara sahip bir kullanıcıdan geçer, girişin kimlik doğrulaması için veritabanı hakları vardır ve başka bir şey yoktur , vb.

Bu şekilde, bir sql enjeksiyon saldırısı varsa, çoğu web sayfasında gerçekten önemli bir şey yapamaz - şifre karmasını göremez, yeni bir yönetici kullanıcı ekleyemez (yapabileceklerinden değil Yine de makinenizde bir kabuk almayı başarabilirlerse yine de yardımcı olmaz, ancak onları yavaşlatır.


1
Benzer bir şey yapıyoruz. Ancak, veritabanının işlevselliği yerine her kullanıcısı / uygulaması için genellikle yeni bir hesap oluştururuz. Bu bizim için iki sorunu çözüyor - 1) OEM gibi araçlarda veritabanının kullanımını farklılaştırabiliriz (yani, veritabanını ayrıntılarla kimin çekiçlediğini görebiliriz) ve 2) her kullanıcının gördüklerini ve veri tabanı.
ScottCher


4

Ben elimden geldiğince yerel soketler üzerinden PostgreSQL'in 'Ident' kimlik doğrulamasını kullanmanın büyük bir hayranıyım . Bu şekilde, yerel kullanıcılar doğrudan yerel bilgisayarın Unix / Windows kullanıcılarıyla eşlenir ve parolaları saklama konusunda endişelenmem gerekmez. Bu henüz MySQL bir seçenek olduğunu sanmıyorum.

Veritabanı ve web sunucusunun iki ayrı makinede olduğu yerlerde, SSL üzerinden MD5 parolaları kullanıyorum: Bir düşmanın ön uç sunucuma erişimi varsa, veritabanıyla nasıl iletişim kurduğunu anlaması sadece zaman meselesidir.


3

.NET Framework kullanıyorsanız, şifreli bağlantı dizelerini kullanmayı düşünebilirsiniz. Başka bir dilde / çerçevede böyle bir şeyin mümkün olup olmadığını bilmiyorum, ancak bağlantılarınızın tehlikeye girmediğinden emin olmak için başka bir koruma olacaktır.

Şifreli bağlantı dizeleri kullanmanın dışında, LDAP / Kerberos / Active Directory kullanmak en güvenli seçenek olacaktır.


3

Parolalarınız düz metin olarak kaydedilmişse, karma (MD5, SHA) kullanın Luke!


OP, kullanıcı şifrelerini saklamak istemiyor. Ama evet, kesinlikle kullanıcı parolalarınızı hash edin, ancak bunu yapmak için hiçbir zaman MD5 veya SHA ailesini kullanmayın! Bcrypt veya PBKDF2 kullanın . Aksi takdirde yakında MD5 ve SHA1 kullanan ve böylece kullanıcılarını basit kaba kuvvet saldırılarına maruz bırakan bu şirketler gibi haberlerde bulacaksınız .
Nick Chammas

Sadece haşlamanın yanı sıra emin, tuzlama ve diğer teknikler gereklidir. Ve kişi asla kendi başına kripto ilkellerini uygulamamalı, aksine yaygın olarak test edilmiş bazı kripto kütüphanelerini kullanmalıdır.
Yasir Arsanukaev

2

Programlama dilinize bağlı olarak, oturum açma kimlik bilgilerini şifreleyebilirsiniz, ancak yorumlanmış bir dil çalıştırıyorsanız, birisinin sisteme erişim sağladığında kimlik bilgilerini çözemediğinden emin olmanın bir yolu yoktur.

C ++ veya benzerlerini çalıştırıyorsanız, tuzlanmış bir şifreleme / şifre çözme işlevi oluşturmanızı / bulmanızı ve bu yolla kimlik bilgilerini çalıştırmanızı ve elde edilen karma değerini sistemde bir dosya olarak depolamanızı öneririm.

PHP veya benzeri bir şekilde mcrypt_encrypt()çalıştırıyorsanız, sisteme erişim kazanırlarsa herhangi bir bilgisayar korsanını yavaşlatmak için kimlik bilgilerini tuzlayın ve kimlik bilgilerini tuzlamanızı öneririz .


Kimlik bilgilerini şifrelerseniz, bunların şifresini tekrar çözmek için başka bir sırya ihtiyacınız vardır. Veya alternatif olarak, şifrelenmiş form sır haline gelir, böylece bir saldırgan bunu kullanabilir. Bazı ayrıntılar eksik.
Peter Eisentraut
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.