it-swarm-vi.com

Bảo mật mật khẩu trong cơ sở dữ liệu - ngày nay vẫn còn thực hành tốt nhất?

Có thể trùng lặp:
[.__.] Tôi nên sử dụng phương pháp băm mật khẩu nào?

Có rất nhiều bài viết tuyệt vời về bảo mật mật khẩu trong cơ sở dữ liệu trên stack stack và trên các trang web khác và vì tôi hoàn toàn mới với điều này, tôi đã dành khá nhiều giờ để cố gắng tìm hiểu thêm về nó trong những ngày qua. Tuy nhiên, có rất nhiều gợi ý khác nhau và cách thực hành tốt nhất mà tôi vẫn rất bối rối ...

Ngoài ra, vẫn còn nhiều bài viết cũ hơn từ 2007-2010, v.v ... Tôi đã thấy mọi thứ thay đổi nhanh như thế nào Tôi không chắc liệu điều này có còn phổ biến để sử dụng nó như họ đề xuất hay không. Vì vậy, tôi muốn tóm tắt những gì tôi tìm thấy trong các bài đăng và sau đó hỏi xem phương pháp này tôi tìm thấy có phải là một thực hành tốt không ...

Vì vậy, đây không phải là một hướng dẫn, nhưng một bản tóm tắt, tôi biết nó rất rất cơ bản và nếu có sai sót xin vui lòng sửa cho tôi!

  1. Chỉ cần đề cập: bạn không bao giờ nên lưu trữ mật khẩu văn bản đơn giản :)
  2. Bạn "mật khẩu băm" một chiều, vì vậy không ai có thể nhìn thấy văn bản đơn giản. Khi người dùng nhập mật khẩu, bạn băm nó theo cùng một cách và so sánh nó với mật khẩu băm trong cơ sở dữ liệu.
  3. Ngoài việc băm mật khẩu, bạn nên muối nó. Bạn thêm muối vào chuỗi mật khẩu đơn giản và băm chuỗi mới. Nếu mật khẩu đơn giản là yếu, thêm muối làm cho nó dài hơn và mạnh hơn.
  4. Hơn nữa, muối nên là ngẫu nhiên (Tôi đã đọc rằng thuật ngữ "muối" có nghĩa là dù sao nó cũng là ngẫu nhiên, nếu không nó được gọi là "chìa khóa"?). Điều này là để ngăn chặn các cuộc tấn công bảng Rainbow, bởi vì kẻ tấn công sẽ cần tạo một bảng cho mỗi loại muối đắt hơn nhiều về mặt thời gian, v.v. Ngoài ra, nếu hai người dùng có cùng một mật khẩu, bạn sẽ không nhận ra nó nếu bạn sử dụng muối ngẫu nhiên.
  5. Muối không phải là một bí mật! Nó đang được lưu trữ trong cơ sở dữ liệu bên cạnh mật khẩu băm. Tuy nhiên, có thể không phải là ý tưởng tốt nhất để sử dụng dấu thời gian, địa chỉ email của người dùng hoặc bất kỳ thứ gì khác được kết nối với người dùng dưới dạng muối ngẫu nhiên. Vì lý do đó là ví dụ đã đề cập rằng người dùng có xu hướng sử dụng cùng một mật khẩu trên nhiều trang web/dịch vụ. Vì vậy, muối nên là một chuỗi ngẫu nhiên, tôi đã đọc tốt nhất sẽ là 64 bit?
  6. Bước tiếp theo là thêm lần lặp vào quy trình băm (1000 vòng lặp trở lên), do đó muối được thêm vào mật khẩu và sau đó chúng được băm lặp đi lặp lại, nghĩa là chỉ một phần giây để người dùng chờ đợi khi đăng nhập trong, nhưng tổng hợp nếu bạn có khoảng 10.000 mục trong DB của bạn.
  7. Nó có thể là một lợi ích nhỏ, nếu bạn thêm khóa trang web, được lưu trữ, ví dụ: như một var toàn cầu ngoài muối. Tuy nhiên, bạn phải luôn cho rằng những kẻ tấn công cũng có quyền truy cập vào hệ thống tệp của bạn.
  8. Các thuật toán băm: Tôi thấy chắc chắn rằng nó không còn an toàn nữa khi sử dụng MD5, SHA1 và các phương pháp yếu khác ...

Vì vậy, có ý kiến ​​khác nhau về việc sử dụng SHA256, SHA512? Bạn có nên sử dụng hash_hmac? Một số người nói có: ( http://rdist.root.org/2009/10/29/stop-USE-unsafe-keyed-hashes-use-hmac/ ) một số người nói sử dụng thư viện là duy nhất cách an toàn ... và sau đó một hoặc hai lần trong một bài đăng Tôi đã đọc không sử dụng các thư viện như bcrypt hoặc bong bóng cá ??

Có thực sự cần thiết phải sử dụng thư viện hay không, ví dụ: một phương pháp như thế này đủ rồi:

function hash_password($password, $nonce) {

  for ($i = 0; $i < 5000; $i++) {
    $hashed_pass = hash_hmac('sha512', $hashed_pass . $nonce . $password, $site_key);
    }
  return $hashed_pass;
}

Nhiều người nói không phát minh ra thuật toán của riêng bạn, vì vậy tôi hơi sợ chỉ sử dụng bất cứ thứ gì tự phát minh ra.

Tôi có thể tưởng tượng nó rất khó dự đoán, nhưng một phương pháp được sử dụng cho đến ngày nay có thể được coi là đủ an toàn trong bao lâu?

CẬP NHẬT: Vì vậy, cảm ơn bạn cho tất cả thông tin phản hồi tuyệt vời của bạn. Có một điểm chính còn thiếu, như tôi thấy và nhiều bạn đã nói: bảo mật mật khẩu, nghĩa là mật khẩu mạnh là cơ bản. Tôi nghĩ rằng tôi đã nhận được tin nhắn, cảm ơn bạn một lần nữa! :)

CẬP NHẬT 2: Chỉ để hoàn thành, tôi đã tìm thấy đoạn mã sau trên http://www.lomaincode.com/creating-a-random-opes-with-php/ mà tôi sử dụng để tạo ra một loại muối ngẫu nhiên :

function Rand_string( $length ) {
    $chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!§$%&/().-:;_#+*[]{}="; 

    $size = strlen( $chars );
    for( $i = 0; $i < $length; $i++ ) {
        $str .= $chars[ Rand( 0, $size - 1 ) ];
    }

    return $str;
}

$random_salt= Rand_string(20);
47
Chris

Thông tin chung :

Câu hỏi hay nhưng tất cả những gì tôi có thể nói là nó hoàn toàn phụ thuộc vào cách sử dụng. Nếu bạn chỉ sử dụng nó cho một trang web nhỏ, có khả năng cao chỉ có "kiddies script" sẽ ghé thăm bạn, trong trường hợp đó, một SHA1 đơn giản với muối là hoàn toàn đủ ngày hôm nay. Trong trường hợp này, 5-8-10 năm hoặc thậm chí nhiều hơn là hoàn toàn tốt, những đứa trẻ kịch bản sẽ không thực sự đột nhập nếu chúng thấy rằng chúng không thể xâm nhập dễ dàng. Nếu trang web của bạn sẽ bị tấn công vì một số lý do - trang web tiền tệ, vv thì bạn nên sử dụng các chức năng có sẵn mới nhất. Trong trường hợp này, tôi thậm chí còn "mạo hiểm" sử dụng chức năng không chính thức nhưng đã được chuyển. Ngay bây giờ có một cuộc thi SHA3, đối với các websties sẽ có nhiều tiền trong đó, tôi sẽ sử dụng một trong 5 đối thủ cạnh tranh trong số này.

Những điểm tôi nói rất quan trọng :

1. sử dụng một loại muối ngẫu nhiên, thậm chí có thể là 20 ký tự. Việc phá mật khẩu trở nên khó khăn hơn rất nhiều và ngay cả khi chúng có thể bị phá vỡ, thì cũng mất quá nhiều thời gian để có giá trị.
[.__.] 2. sử dụng SHA-1, SHA-2 hoặc WHIRLPOOL. Với muối tốt, MD5 cũng ổn, nhưng tôi vẫn đề xuất những thứ này.
[.__.] . bạn có thể sử dụng bất kỳ loại mật mã tuyệt vời nào nếu mật khẩu của người dùng là tầm thường. Bạn phải chắc chắn rằng họ sử dụng phi từ điển, mật khẩu dài với chữ hoa, chữ thường, số và ký hiệu khác, nó có thể dễ dàng bị phá vỡ bởi lực lượng vũ phu. Bạn có thể cân nhắc rằng họ có thể bị buộc phải thay đổi mật khẩu mỗi năm hoặc lâu hơn.

Theo mã :

Vòng lặp nhiều lần có thể hữu ích nhưng tôi không nghĩ 5000 là bắt buộc. 3 cho bảo mật thông thường là tốt, hoặc 100, có thể 1000 có thể hoạt động, nhưng tôi nghĩ 5000 là quá nhiều. SHA-256 là tốt, nhưng bạn có thể sử dụng một thuật toán được phát triển riêng cho điều đó, xem các bình luận.

2
axiomer

Bạn đã quên chỉ một điều nhỏ:

Mật khẩu mạnh.

Chỉ cần 2 từ mà thừa cân toàn bộ chủ đề tuyệt vời của bạn.

Thực sự có hàng trăm chủ đề trên Stackoverflow bảo bạn sử dụng thuật toán băm này hoặc muối ngẫu nhiên.
[.___.].

Đối với những người dùng nghèo không thể nhớ $#%H4df84a$%#R mật khẩu - chỉ cần làm cho chúng sử dụng không phải mật khẩu mà là a cụm mật khẩu.

Is it a good day today, Winkie? Sử dụng các chữ cái khác nhau cũng như mật khẩu có độ phức tạp được đề xuất nhưng dễ nhớ hơn nhiều.

Tất nhiên, cụm từ không nên phổ biến như các mật khẩu phổ biến như "Joe" hoặc "123".
[.__.] "Chào buổi sáng", "Ôi Chúa ơi! Họ đã giết Kenny!" cụm từ nên tránh.
[.__.] Nhưng bằng cách thêm một số tính cách, nó sẽ ổn thôi:
[.__.] Oh My God! They moved Cthulhu! trông khá đủ

Một điều khác cần đề cập là một liên lạc an toàn giữa máy chủ và trình duyệt
[.___.

SSH hoặc một số triển khai ủy quyền tiêu hóa không kém phần cần thiết.

10
Your Common Sense

Hàm băm có mục đích chung (MD5, SHA1, SHA256) với hàm băm tốt có thể đủ an toàn cho hầu hết các trang web nhỏ hơn, với khả năng tính toán hiện tại. Tuy nhiên, luật của Moore sẽ đảm bảo rằng ngay cả những mật khẩu tốt cũng sẽ bị phơi bày trước các cuộc tấn công vũ phu trong tương lai gần. Vấn đề là các hàm băm có thể được tính toán quá nhanh. Giải pháp tốt nhất là sử dụng bcrypt hoặc PBKDF2 với số lần lặp cao. Bcrypt vs PBKDF2 đã được thảo luận tại http://security.stackexchange.com .

Một số người có thể nghĩ rằng điều này là quá mức cần thiết cho hầu hết các trang web nhưng hãy nhớ rằng mật khẩu được sử dụng lại mọi lúc và lưu trữ mật khẩu thường là thứ bạn sẽ không thay đổi cho đến khi có vấn đề.

Đề xuất:

  1. Sử dụng bcrypt hoặc PBKDF2. KHÔNG SỬ DỤNG ứng viên SHA3. Chúng có thể chứa các lỗ hổng bảo mật chưa được phát hiện.
  2. Sử dụng một loại muối ngẫu nhiên để giúp bảo vệ chống lại các cuộc tấn công bảng Rainbow.
  3. Buộc người dùng chọn một cụm mật khẩu.

Thêm thông tin

5
tony

Hàm hash_hmac() sẽ là một lựa chọn tốt, thậm chí nó có thể khắc phục các vấn đề của thuật toán băm yếu hơn. Vấn đề duy nhất là, đó là quá nhanh. Điều đó có nghĩa là với đủ năng lượng cpu (đám mây), việc tạo các bảng Rainbow khác nhau trở nên khả thi, đó là lý do để lặp lại. Nếu bạn cần bảo mật cao này, thì bạn có thể đo thời gian lặp lại của mình cần, sau đó tính số lần lặp cần thiết trong một thời gian nhất định.

Biên tập:

Lặp lại có thể giải quyết vấn đề này, nó nên được thực hiện theo cách, rằng người ta có thể tăng số lần lặp lại sau đó, mà không làm cho các giá trị băm hiện có không hợp lệ. Điều này là cần thiết để thích ứng với phần cứng mới trong tương lai, nhưng yêu cầu lưu trữ các tham số băm cùng với hàm băm.

Thuật toán băm bcrypt được thiết kế để đáp ứng nhu cầu này, tôi đã viết một ví dụ nhỏ về cách sử dụng bcrypt với PHP 5. , tôi đã cố gắng nhận xét nó, vì vậy người ta có thể nhận xét hiểu những gì đang xảy ra.

2
martinstoeckli