Giá trị băm muối nên đến từ đâu?

Khi thêm giá trị muối vào giá trị băm cho một cái gì đó như mật khẩu không thể được lưu trữ trong văn bản thuần túy, nơi tốt nhất để lấy các giá trị muối đến từ đâu? Đối với ngữ cảnh, chúng ta hãy giả sử đây là mật khẩu khi đăng nhập trang web.

Tôi thường có một cột created TIMESTAMPtrong bảng người dùng để tôi có thể thấy khi người dùng đăng ký. Tôi không muốn thêm một cột bổ sung cho Muối, vì vậy tôi sử dụng cột dấu thời gian làm muối:

SHA1(password + created)

Có vấn đề gì không?

Muối phục vụ hai mục đích. Nó khiến cho việc sử dụng các bảng mật khẩu được trộn sẵn ("bảng cầu vồng") trở nên không thực tế và nó làm cho các mật khẩu giống hệt nhau trông khác nhau trong danh sách băm. Làm cho các mật khẩu giống hệt nhau trông khác nhau giúp tránh một vấn đề trong đó một số người đang sử dụng một mật khẩu cụ thể, có lẽ là một mật khẩu yếu phổ biến.

Do đó, mỗi tài khoản nên có loại muối duy nhất của riêng mình và muối không nên dự đoán quá mức, theo nghĩa là sẽ không có một nhóm muối nào có khả năng xảy ra. (Nếu nhiều trang web bắt đầu từ 1 và được tính lên, chẳng hạn, kẻ xấu có thể tạo các bảng cầu vồng bao gồm cả số lượng muối thấp.) Chúng không phải ngẫu nhiên theo bất kỳ ý nghĩa nào khác hơn là không thể đoán trước. Chúng không có gì bí mật hơn bản thân hàm băm, vì vậy chúng không cần phải đặc biệt vô dụng.

Sử dụng bất kỳ phương pháp thuận tiện để tạo ra một muối. Nếu có nhiều giá trị muối tiềm năng (các hệ thống Unix ban đầu thường sử dụng hai byte, với số lượng có thể là 65536) so với số lượng tài khoản, việc gán bán ngẫu nhiên sẽ gần như không bao giờ tạo ra một loại muối trùng lặp.

Mỗi lần bạn muốn lưu trữ một mật khẩu mới (đăng ký, đặt lại mật khẩu, cập nhật mật khẩu), một kỹ thuật tốt là:

• tạo ra muối mới
  • sử dụng một trình tạo số giả ngẫu nhiên an toàn bằng mật mã
  • sử dụng muối có kích thước khá - giá trị tốt là kích thước khối của thuật toán băm cơ bản (có thể là SHA-256)
• tạo mã thông báo mật khẩu mới
  • tạo một hàm hmac từ thuật toán băm cơ bản (có thể là SHA-256) bằng cách sử dụng muối làm khóa hmac
  • for i in (0...65536) { password = hmac(password) }
  • kết quả của các ứng dụng lặp của hàm hmac là mã thông báo mật khẩu
• lưu trữ muối và mã thông báo mật khẩu
  • không lưu trữ mật khẩu gốc
  • tùy chọn lưu trữ thuật toán băm cơ bản và trải dài để khám phá

Tận dụng khuôn khổ. Trong .NET, bạn có thể sử dụng RNGCryptoServoiceProvider ...

        // If salt is not specified, generate it on the fly.
        if (saltBytes == null)
        {
            // Define min and max salt sizes.
            int minSaltSize = 4;
            int maxSaltSize = 8;

            // Generate a random number for the size of the salt.
            Random  random = new Random();
            int saltSize = random.Next(minSaltSize, maxSaltSize);

            // Allocate a byte array, which will hold the salt.
            saltBytes = new byte[saltSize];

            // Initialize a random number generator.
            RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();

            // Fill the salt with cryptographically strong byte values.
            rng.GetNonZeroBytes(saltBytes); 
        }

Các khung khác nên có các lớp tương tự bạn có thể tận dụng. Để đạt được sự ngẫu nhiên, phần mềm thường sử dụng người dùng so với Randomnhư đã đề cập ở trên. Di chuyển ngẫu nhiên một con chuột trong một khu vực xác định để cung cấp muối là một tùy chọn được sử dụng bởi TrueCrypt. Nó đáp ứng nhu cầu cụ thể và mức độ bảo mật của bạn; vì muối của bạn chỉ đơn giản là có thể !@#$%.

Bạn tạo phía máy chủ muối và gán nó cho tài khoản người dùng khi tạo. Sử dụng tốt hơn một số API tạo tiền điện tử có sẵn với khung của bạn nhưng về nguyên tắc, bất kỳ chuỗi nào cũng được.

Thông thường mọi thứ được lưu trữ như thế này:

User
-------------------
ID
Username
PasswordHashWithSalt

Thí dụ:

Mật khẩuHashWithSalt =

A15CD9652D4F4A3FB61A2A422AEAFDF0DEA4E703 j5d58k4b56s8744q

Sử dụng bcrypt và đọc bài viết này như một mình băm bình thường không phải là sự bảo vệ nghiêm trọng trong thời đại ngày nay.

Cân nhắc sử dụng giao thức mật khẩu không kiến ​​thức SDR có nhiều thư viện mã nguồn mở và không có bằng sáng chế.

SDR yêu cầu muối và nơi tốt nhất để có được đó là khách hàng; thời gian nhấn phím, di chuyển chuột, băm các biến môi trường, số ngẫu nhiên, thời gian tạo tệp trong thư mục tạm thời của chúng, để tạo muối ở cuối của chúng theo cách không thể đoán trước từ máy chủ của bạn. SDR lấy muối, một số nguyên tố lớn, mật khẩu người dùng và tạo khóa xác minh. Bạn không lưu trữ mật khẩu, nó không bao giờ rời khỏi máy của họ nhưng bạn có thể xác minh rằng họ có mật khẩu đi kèm với khóa xác minh và muối. Nó miễn dịch với con người trong các cuộc tấn công từ giữa và từ điển. Mã hóa các khóa và muối trong cột cơ sở dữ liệu để đảm bảo.