Mevcut kullanıcılar için yeni bir şifre zorlamadan şifre karma işleminin güncellenmesi

Mevcut bir uygulamayı, kurulmuş bir kullanıcı tabanı ile sürdürürsünüz. Zamanla, mevcut şifre karma tekniğinin modası geçmiş olduğuna ve iyileştirilmesi gerektiğine karar verilir. Ayrıca, UX nedenleriyle, mevcut kullanıcıların şifrelerini güncellemeye zorlanmasını istemiyorsunuz. Şifrelerin tamamen güncellenmesinin tamamı ekranın arkasında gerçekleşmelidir.

Aşağıdakileri içeren kullanıcılar için 'basit' bir veritabanı modeli düşünün:

1. İD
2. E-posta
3. Parola

Kişi böyle bir gereksinimi çözmek için nasıl dolaşıyor?

Mevcut düşüncelerim:

• uygun sınıfta yeni bir karma yöntemi oluşturun
• Ek bir şifre alanı tutmak için veritabanındaki kullanıcı tablosunu güncelle
• Bir kullanıcı eski parola karmaşasını kullanarak başarılı bir şekilde oturum açtığında, ikinci parola alanını güncelleştirilmiş karma ile doldurun.

Bu beni ve şifre karma değerlerini güncellemeyen ve bu nedenle her ikisini de kontrol etmeye zorlanacak kullanıcılar arasında ayrım yapamayacağıma dair sorun çıkarıyor. Bu korkunç derecede kusurlu görünüyor.

Ayrıca, bu temelde, eski karma tekniğin, her bir kullanıcı şifresini güncelleyene kadar süresiz olarak kalmaya zorlanabileceği anlamına gelir. Sadece o anda eski karma denetimini kaldırmaya başlayabilir ve gereksiz veritabanı alanını kaldırabilirim.

Burada esasen bazı tasarım ipuçlarını arıyorum, çünkü şu anki 'çözümüm' kirli, eksik ve ne olmasın, ancak olası bir çözümü tanımlamak için gerçek kod gerekiyorsa, herhangi bir dili kullanmaktan çekinmeyin.

Eski yöntemi belirtmek için 1, yeni yöntemi belirtmek için 2 olan "hash_method" alanını eklemenizi öneririm.

Makul bir şekilde konuşursak, eğer bu tür bir şeye önem veriyorsanız ve başvurunuz nispeten uzun sürüyor (görünüşe göre zaten), bu muhtemelen şifreleme ve bilgi güvenliği böyle gelişmekte olan, oldukça öngörülemeyen bir alan olduğu için tekrar olacak. Eğer karma kullanılıyorsa, MD5 üzerinden basit bir işlemin standart olduğu bir zaman vardı! O zaman biri SHA1'i kullanmaları gerektiğini düşünebilir ve şimdi tuzlu, küresel tuz + bireysel rastgele tuz, SHA3, şifrelemeye hazır rasgele sayı üretmenin farklı yöntemleri var ... bu sadece 'durmayacak' bunu genişletilebilir, tekrarlanabilir bir şekilde düzeltin.

Diyelim ki şimdi şöyle bir şeyiniz var (basitlik için sözde-javascript'te, umarım):

var user = getUserByID(id);
var tryPassword = hashPassword(getInputPassword());


if (user.getPasswordHash() == tryPassword)
{
    // Authenticated!
}

function hashPassword(clearPassword)
{
    // TODO: Learn what "hash" means
    return clearPassword + "H@$I-I";
}

Şimdi daha iyi bir yöntem olduğunu fark edersek, sadece küçük bir yeniden düzenleme yapmanız gerekir:

var user = getUserByID(id);
var tryPassword = hashPassword(getInputPassword(), user.getHashingMethod());

if (user.getPasswordHash() == tryPassword)
{
    // Authenticated!
}

function hashPassword(clearPassword, hashMethod)
{
    // Note: Hash doesn't mean what we thought it did. Oops...

    var hash;
    if (hashMethod == 1)
    {
        hash = clearPassword + "H@$I-I";
    }
    else if (hashMethod == 2)
    {
        // Totally gonna get it right this time.
        hash = SuperMethodTheNSASaidWasAwesome(clearPassword);
    }
    return hash;
}

Bu cevabın üretiminde hiçbir gizli ajan veya programcı zarar görmedi.

Yeni karma şemasını tüm kullanıcılara olabildiğince çabuk (örneğin eski olanı gerçekten güvensiz olduğu için) kullanıma sunmaya yeterince önem veriyorsanız, aslında her parolanın anında "geçişi" için bir yol vardır .

Fikir temelde karma hash etmektir . Kullanıcılar bir psonraki oturum açışında mevcut şifrelerini ( ) beklemek yerine , eski algoritma ( ) tarafından zaten mevcut olan karmaH2 üzerinde yeni karma algoritmasını ( ) kullanırsınız :H1

hash = H2(hash)  # where hash was previously equal to H1(p) 

Bu dönüşümü yaptıktan sonra, hala şifre doğrulaması yapabiliyorsunuz; kullanıcı parola ile giriş yapmaya çalıştığında sadece bir H2(H1(p'))önceki yerine hesaplamanız gerekir .H1(p')p'

Teorik olarak, bu teknik, çok sayıda taşıma (tatbik edilebilir H3, H4vb.) Uygulamada, hem performans hem de okunabilirlik nedeniyle eski hash fonksiyonundan kurtulmak istersiniz. Neyse ki, bu oldukça kolay: bir sonraki başarılı oturum açışınızda, kullanıcının parolasını içeren yeni kareyi hesapla ve mevcut karışıma sahip olanı değiştir:

hash = H2(p)

Ayrıca, sakladığınız karmaşayı hatırlamak için ek bir sütuna ihtiyacınız olacaktır: şifrenin biri veya eski karma. Talihsiz veritabanı sızıntısı durumunda, bu sütun krakerin işini daha kolay hale getirmemelidir; değeri ne olursa olsun, saldırganın H2eskisinden çok güvenli algoritmayı tersine çevirmesi gerekirdi H1.

Çözümünüz (veritabanındaki ek sütun) tamamen kabul edilebilir. Bununla ilgili tek sorun, daha önce bahsettiğiniz sorun: eski karma işleminin, değişiklikten bu yana kimliği doğrulanmamış kullanıcılar için hala kullanılıyor.

Bu durumu önlemek için, en aktif kullanıcılarınızın yeni karma algoritmaya geçmesini bekleyebilirsiniz.

1. Çok uzun süre kimlik doğrulaması yapmamış kullanıcıların hesaplarını kaldırın. Üç senedir web sitesine hiç gelmemiş olan bir kullanıcının hesabını kaldırmakta yanlış bir şey yoktur.

2. Kalan kullanıcılara bir süre kimliği doğrulanmamış kullanıcılar arasında, yeni bir şeyle ilgilenebileceklerini söyleyen bir e-posta gönderin. Eski karıĢmayı kullanan hesap sayısını daha da azaltmaya yardımcı olacaktır.

   Dikkatli olun: Spam içermeyen bir seçeneğiniz varsa, kullanıcılar web sitenizi kontrol edebilirler, e-postayı kontrol eden kullanıcılara göndermeyin.

3. Son olarak, 2. adımdan birkaç hafta sonra, hala eski tekniği kullanan kullanıcılar için şifreyi imha edin. Kimlik doğrulamaya çalışırlarsa ve parolalarının geçersiz olduğunu görürler; Hizmetinizle hala ilgileniyorlarsa, sıfırlayabilirler.

Muhtemelen asla bir kaç hash tipinden daha fazlasına sahip olmayacaksınız, bu yüzden veritabanınızı genişletmeden bunu çözebilirsiniz.

Yöntemlerin farklı uzunlukları varsa ve her yöntemin karma uzunluğu sabittir (md5'ten hmac-sha1'e geçiş), yöntemi karma uzunluğundan söyleyebilirsiniz. Aynı uzunluktalarsa, önce yeni yöntemi, sonra da ilk sınama başarısız olursa eski yöntemi kullanarak hash değerini hesaplayabilirsiniz. Kullanıcının en son ne zaman güncellendiğini / oluşturulduğunu söyleyen bir alanınız (gösterilmiyor) varsa, bunu hangi yöntemin kullanılacağının göstergesi olarak kullanabilirsiniz.

Böyle bir şey yaptım ve yeni karma olup olmadığını ve daha güvenli hale getirip getirmediğini söylemenin bir yolu var. Tahmininizi güncellemek için zaman ayırıyorsanız daha güvenli olduğunu düşünüyorum sizin için iyi bir şey ;-)

DB tablonuza "tuz" adlı yeni bir sütun ekleyin ve peki, bunu kullanıcı başına rasgele oluşturulmuş bir tuz olarak kullanın. (Gökkuşağı masa saldırılarını engeller)

Bu şekilde, şifrem "pass123" ve rasgele tuz 3333 ise, yeni şifrem "pass1233333" 'in karması olur.

Kullanıcının bir tuzu varsa, bunun yeni karma olduğunu biliyorsun. Kullanıcının tuzu null ise, bunun eski karma olduğunu bilirsiniz.

Geçiş stratejiniz ne kadar iyi olursa olsun, eğer veritabanı zaten çalınmışsa (ve bunun asla gerçekleşmediğini negatif olarak kanıtlayamazsanız), o zaman güvensiz hash işlevleriyle saklanan şifreler zaten tehlikeye girebilir. Bunun için tek azaltma, kullanıcıların şifrelerini değiştirmelerini gerektirir.

Bu, (sadece) kod yazarak çözülebilecek bir sorun değildir. Çözüm, kullanıcıları ve müşterileri maruz kaldıkları riskler hakkında bilgilendirmektir. Bu konuda açık olmaya istekli olduğunuzda, geçişi her kullanıcının şifresini sıfırlayarak kolayca yapabilirsiniz, çünkü en kolay ve en güvenli çözümdür. Tüm alternatifler gerçekten batırdığın gerçeğini gizlemekle ilgili.