Tuz tellerinizi nerede saklıyorsunuz?

Ben her zaman veritabanı depolama için şifreleri hashing sırasında uygun bir giriş tuz dizesi kullandım. Benim ihtiyaçları için, tuz karma şifre yanında DB depolamak her zaman iyi çalıştı.

Bununla birlikte, bazı insanlar tuzun veritabanından ayrı olarak depolanmasını tavsiye eder. Onların argümanı, eğer veritabanı tehlikeye atılırsa, bir saldırganın bir kerede bir hesap kırmak için belirli bir tuz dizesini dikkate alarak bir gökkuşağı tablosu oluşturabileceğidir. Bu hesabın yönetici ayrıcalıkları varsa, başkalarını kırması bile gerekmeyebilir.

Güvenlik açısından, tuzları farklı bir yerde saklamakta fayda var mı? Aynı makinede sunucu kodu ve DB bulunan bir web uygulaması düşünün. Tuzlar bu makinedeki düz bir dosyada saklanırsa, veritabanı tehlikeye girerse, tuz dosyasının da olması ihtimali vardır.

Bunun için önerilen çözümler var mı?

Gökkuşağı tablolarının amacı, önceden oluşturulmuş ve başkaları için hesaplama zamanından tasarruf etmek için toplu olarak dağıtılmış olmalarıdır - anında şifre + tuz kombinasyonunu kırmak gibi gökkuşağı tabloları oluşturmak kadar uzun sürer (çünkü Gökkuşağı tabloları oluştururken yapılan şey, kaba kaba zorlama için hesaplamaları önceden çalıştırmaktır), bu nedenle birisinin "gökkuşağı tablosu üretebileceği" tuzunu bilerek argüman sahte.

Tuzları, kullanıcı bazında oldukları sürece ayrı bir dosyada saklamanın gerçek bir anlamı yoktur - tuzun amacı basitçe bunu yapmaktır, böylece bir gökkuşağı tablosu DB'deki her şifreyi kıramaz.

Bunu biraz farklı bir şekilde ele alacağım.

Ben her zaman tuzlu şifre karma ile karıştırılmış tuz saklıyorum.

Örneğin, tuzun ilk yarısını şifrenin tuzlu karmasından önce ve tuzun son yarısını şifrenin tuzlu karmasından sonra koyacağım. Uygulama bu tasarımın farkındadır, bu nedenle bu verileri alabilir ve tuz ve tuzlu parola karmasını elde edebilir.

Bu yaklaşımın mantığı:

Parola / sağlama verisi tehlikeye girerse ve bir saldırganın eline geçerse, saldırgan tuzun verilere bakmasının ne olduğunu bilemez. Bu şekilde bir saldırgan, karma ile eşleşen bir parola almak için pratik olarak kaba-kuvvet saldırısı gerçekleştiremez, çünkü başlamak için hash'ı bilmiyor ve verilerin hangi bölümlerinin tuzun parçaları olduğunu bilmiyor ya da tuzlu parola karmasının bazı bölümleri ( uygulamanızın kimlik doğrulama mantığını bilmediği sürece ).

Tuzlu parola karması olduğu gibi depolanırsa, tuzlanmış ve karıklandığında tuzlu parola karmasıyla aynı verileri üreten bir parola elde etmek için kaba kuvvet saldırısı gerçekleştirilebilir.

Ancak, örneğin, tuzlu parola karması olduğu gibi depolanmış olsa da, saldırganın bu ilk baytın atılması gerektiğini bilmediği sürece, tek bir rastgele baytla önceden bekletilmiş olsa bile, bu da zorluğu artıracaktır. saldırı. Uygulamanız, kullanıcı kimliğinizi doğrulamak için kullanıldığında verilerin ilk baytını atmayı bilir.

Bunun sonucu ..

1) Kimlik doğrulama uygulamanızın kullandığı verileri kesinlikle tam biçiminde saklamayın.

2) Mümkünse, ek güvenlik için kimlik doğrulama mantığınızı gizli tutun.

Bir adım daha ileri git ..

Uygulamanızın kimlik doğrulama mantığını gizli tutamazsanız - birçok kişi verilerinizin veritabanında nasıl saklandığını bilir. Tuzlu parola karmasını tuzla karıştırmaya karar verdiğinizi varsayalım, tuzun bir kısmı tuzlu parola karmasını önler ve diğer tuzu ekler.

Rastgele tuz üretirken, tuzunuzun şifre oranından önce / sonra saklayacağınız tuz miktarını da rastgele bir şekilde belirleyebilirsiniz.

Örneğin, 512 baytlık rastgele bir tuz üretiyorsunuz. Tuzu şifrenize ekler ve tuzlu şifrenizin SHA-512 karmasını elde edersiniz. Ayrıca rastgele bir tamsayı 200 de oluşturursunuz. Daha sonra tuzun ilk 200 baytını, ardından tuzlu parola karmasını ve ardından tuzun geri kalanını depolarsınız.

Bir kullanıcının şifre girişinin kimliğini doğrularken, uygulamanız dize üzerinden geçer ve verilerin ilk 1 baytının tuzun ilk 1 baytı ve ardından tuzlanmış karma olduğunu varsayar. Bu geçiş başarısız olacaktır. Uygulama, verilerin ilk 2 baytını tuzun ilk 2 baytı olarak kullanmaya devam edecek ve tuzun ilk 200 baytı olarak ilk 200 bayt kullanıldıktan sonra pozitif bir sonuç bulunana kadar tekrarlanacaktır. Şifre yanlışsa, uygulama hiçbiri bulununcaya kadar tüm permütasyonları denemeye devam edecektir.

Bu yaklaşımın artıları:

Artan güvenlik - kimlik doğrulama mantığınız bilinse bile, derleme zamanında kesin mantık bilinmiyor. Kesin mantık bilgisine rağmen, kaba kuvvet saldırısı yapmak neredeyse imkansızdır. Artan tuz uzunlukları güvenliği daha da artıracaktır.

Bu yaklaşımın eksileri:

Tam mantık çalışma zamanında çıkarıldığı için, bu yaklaşım çok CPU yoğundur. Tuzun uzunluğu ne kadar uzun olursa, bu yaklaşım o kadar fazla CPU yoğunluklu olur.

Yanlış şifrelerin doğrulanması en yüksek CPU maliyetini içerir. Bu, meşru taleplere karşı üretken olabilir, ancak saldırganlara karşı güvenliği artırır.

Bu yaklaşım çeşitli şekillerde uygulanabilir ve değişken genişlikli tuzlar ve / veya tuzlu parola karmaları kullanılarak daha da güvenli hale getirilebilir.

Genellikle, karmaya eklenir ve aynı alanda saklanırlar.

Bunları ayrı ayrı depolamaya gerek yoktur - nokta, her şifre için rastgele bir tuz kullanmaktır, böylece tek bir şifre tablosunun tüm şifre karmaları kümesine karşı kullanılamaz. Rastgele tuzlarla, bir saldırgan her karmayı ayrı ayrı kaba kuvvetle zorlamalıdır (veya tüm olası tuzlar için bir gökkuşağı tablosu hesaplamalıdır - çok daha fazla iş).

Daha güvenli bir depolama yeriniz olsaydı, karmaları orada saklamak mantıklı olurdu.

William Penberthy tarafından geliştirilen ASP.NET MVC 4 Web Uygulamaları kitabına dayanarak:

1. Ayrı bir veritabanında depolanan tuzlara erişmek için, bilgisayar korsanlarının tuz ve tuzlanmış parolaya erişmek için iki farklı veritabanını hacklemeleri gerekir. Onları parola ile aynı tabloda, hatta aynı veritabanının başka bir tablosunda saklamak, bilgisayar korsanlarının veritabanına eriştiklerinde hem tuz hem de parola karmasına erişebilecekleri anlamına gelir. Güvenlik, sisteme hacklemeyi buna değmeyecek kadar pahalı veya zaman alıcı hale getirme işlemini içerdiğinden, bir bilgisayar korsanının kazanmak zorunda kalacağı erişim miktarının iki katına çıkarılması sistemi daha güvenli hale getirmelidir.
2. Kullanım kolaylığı, tuzların karma parolalarla aynı veritabanında tutulmasının başlıca nedenidir. İki veritabanının her zaman aynı anda ve her zaman senkronize olduğundan emin olmanız gerekmez. Her kullanıcının rastgele bir tuzu varsa, tuz elde etmenin avantajı minimumdur, çünkü bireyin şifresini bulmayı kolaylaştırabilse de, genel olarak sistemin şifrelerini kırmak için gereken kuvvet miktarı yüksek olacaktır. Bu tartışma düzeyinde, beklenti budur: şifreleri korumak. Bilgisayar korsanları veritabanının bir kopyasını edindiyse, uygulama verileriniz zaten ele geçirilmiş demektir. Bu noktada sorun, paylaşılan şifrelerin potansiyeli nedeniyle kullanıcıların risklerini azaltmaktır.
3. İki ayrı bağlantılı, veritabanının bakım zorunluluğu büyüktür. Kabul edilirse, güvenlik algısını ekler, ancak verdiği tek avantaj, bir parolayı, tek bir veri öğesini korumasıdır. Veritabanındaki her alan ayrı ayrı şifrelenmişse ve bunun için aynı tuz kullanılmışsa, sisteminizin temel güvenliği artırıldığından, verileri verilerden ayrı olarak saklamak daha mantıklı olacaktır.

Bir tuzun amacı, tüm gökkuşağı tablolarını işe yaramaz hale getirmek ve yeni bir set yapılmasını gerektirmektir. Gökkuşağı masası yapmak için bir ipi tahmin etmek kadar uzun sürer. Örneğin "parola" nın SHA-256 karmasıdır 5e88 4898 da28 0471 51d0 e56f 8dc6 2927 7360 3d0d 6aab bdd6 2a11 ef72 1d15 42d8. "Badpassword" gibi bir tuz eklendikten sonra, karma hale getirilecek yeni dize, çığ etkisi nedeniyle çıkışı önemli ölçüde değiştiren "passwordbadpassword" olur 457b f8b5 37f1 802e f9c8 2e46 b8d3 f8b5 721b 7cbb d485 f0bb e523 bfbe 73e6 58d6.

Normalde tuz, parola ile aynı veritabanında saklanır, çünkü bir veritabanı saldırıya uğradığında, diğerinin de olması muhtemeldir.