2013-01-21 27 views
10

thể trùng lặp:
Secure hash and salt for PHP passwordsTên người dùng, Mật khẩu, Salting, Encrypting, Hash - Tất cả hoạt động như thế nào?

Iv'e đọc rất nhiều bài viết cả trong stackoverflow và các trang web khác nói về bảo mật web. Chẳng hạn như salting mã hóa vv Và tôi kinda không nhận được nó như vậy một lời giải thích đơn giản sẽ thực sự hữu ích.

Vì vậy, đây là những gì tôi biết cho đến thời điểm này. Người dùng ghi lại các loại tên người dùng và mật khẩu của mình. Đầu vào sau đó đi qua một quá trình. Giả sử tên người dùng và mật khẩu được kết hợp như ví dụ:

$username = (USERS USERNAME INPUT); 
$password = (USERS PASSWORD INPUT); 
$userinput = $username . $password; 

Sau đó, chúng tôi thêm một chút muối.

$salt1 = "13$13aVc!kd"; 
$salt2 = "4kr$!vlmeoc"; 

$salted = $salt1 . $userinput . $salt2; 

Sau đó, chúng tôi mã hóa nó.

$encrypted = encrypt($salted); 

Sau đó kiểm tra với cơ sở dữ liệu và nếu sử dụng quyền của mình được đăng nhập.

Đó là cách nó hoạt động đúng không? Nhưng Iv'e đã ​​đọc về cuộc tấn công bạo lực. Nó đoán các giá trị đầu vào phải không? Với quy trình trên. Nó không cho thấy kẻ tấn công chỉ cần lấy thông tin $ userinput chính xác để vào? Anh ta không cần phải đoán chuỗi dài $ mã hóa đúng không?

Lưu ý: Cho phép nói trong trường hợp này không có hình ảnh xác thực, không giới hạn số lần thử, không khóa, không có gì khác ngoài giới hạn ở trên.

Lưu ý: Hãy nhẹ nhàng tôi vẫn đang học.

+1

Đó là lý do tại sao người dùng được khuyên nên sử dụng mật khẩu mạnh thay vì "12345" nhưng có thể có hiệu lực bạo lực trong trường hợp của bạn .. – Deadlock

+0

để muối và mã hóa là vô dụng? –

+0

Sắp xếp, nhưng ngày đăng nếu bị tấn công ở giữa sẽ không được sử dụng cho kẻ tấn công vì nó sẽ có trong chuỗi được mã hóa và không thể được đảo ngược cho đến khi anh ta không có giá trị muối. – Deadlock

Trả lời

7

Nếu bạn loại trừ captchas, hãy thử giới hạn, khóa, v.v ... thì có. Bạn chỉ cần có sức mạnh vũ phu chuỗi văn bản thuần túy.

Tuy nhiên, điều này sẽ mất thời gian - ít nhất, nó bị ràng buộc bởi tốc độ máy chủ sẽ phản hồi yêu cầu đăng nhập. Ngay cả khi nhà phát triển không thêm bất kỳ biện pháp nào để ngăn chặn sự cố cưỡng bức, bản thân máy chủ chỉ có thể thực hiện quá trình xác minh mã hóa + một cách nhanh chóng và chỉ có thể xử lý nhiều yêu cầu song song.

Điều đó nói rằng, đây là lý do tại sao điều quan trọng là

  • Là một người sử dụng, sử dụng một mật khẩu mạnh, khó có thể brute-force
  • Là một nhà phát triển, có các biện pháp thích hợp để ngăn chặn tấn công brute-buộc của bạn quá trình đăng nhập

băm và muối mật khẩu không phải là để bảo vệ chống lại những người vũ phu buộc quá trình đăng nhập tự nhiên (có những điều khác mà bảo vệ chống lại đó). Thay vào đó, chúng bảo vệ chống lại sự xâm nhập tiềm tàng của bản thân lưu trữ mật khẩu (ví dụ: ai đó bán phá giá nội dung của cơ sở dữ liệu).

Cả băm và muối phục vụ để giảm tốc độ mà tại đó người có quyền truy cập vào các mật khẩu được lưu trữ có thể lấy các chuỗi văn bản đơn giản họ sẽ cần để có thể đi qua quá trình đăng nhập tự nhiên (của trang web của bạn hoặc các trang web khác, do mật khẩu thường được chia sẻ giữa các trang web) mà không bị vấp phải các biện pháp bảo mật chống bạo lực.

+0

@ user1429811 Nếu bạn muốn đọc thêm, tôi có toàn bộ bài đăng trên blog về chủ đề này tại đây - http://codingkilledthecat.wordpress.com/2012/09/04/some-best-practices-for-web-app -xác thực / – Amber

2

Ý tưởng băm và muối là nhiều hơn để ngăn người khác lấy mật khẩu người dùng nếu bản thân cơ sở dữ liệu bị xâm nhập. Nếu các mật khẩu được lưu trữ dưới dạng chuỗi bị băm và bị băm, kẻ tấn công không thể sử dụng chúng để truy cập tài khoản của người dùng trên một trang web khác.

1

Mã hóa mật khẩu là mã hóa một chiều (hoặc đúng hơn là giả sử ở một trang web an toàn). Đó là để nói rằng bạn lấy mật khẩu và bạn thực hiện một hình thức băm nó. bcrypt ví dụ là tiêu chuẩn chấp nhận được để làm điều này ngày hôm nay.

Nếu mã hóa một chiều, nhiều người tự hỏi nó có thể kiểm tra mật khẩu như thế nào. Nhưng bạn chỉ cần băm mật khẩu người dùng gửi và so sánh nó với những gì băm bạn lưu trữ trong cơ sở dữ liệu. Bằng cách này, nếu cơ sở dữ liệu của bạn bị đánh cắp, kẻ tấn công phải làm việc chăm chỉ hơn nhiều.

Vấn đề với việc băm nhỏ mật khẩu có thể dễ dàng bị trục trặc hoặc cầu vồng. Bạn có thể google bảng cầu vồng để tìm hiểu thêm về điều đó. Nhưng về cơ bản nó là một cách để biến những băm trở lại mật khẩu.

Nhập muối. Salting là thêm dữ liệu ngẫu nhiên về cơ bản cho mỗi mật khẩu. Điều này át các bảng cầu vồng. Có nghĩa là một cơ sở dữ liệu bị xâm phạm sẽ có nghĩa là sức mạnh vũ phu. Mà nếu bạn đang sử dụng một hệ thống băm như bcrypt mất rất nhiều thời gian và công sức cho các cuộc tấn công.

Đã nói tất cả điều đó. Tốt nhất là không tái tạo lại bánh xe. Chỉ cần sử dụng một hệ thống ủy quyền tốt được biết nếu bạn có thể.

0

Xem câu trả lời của tôi here

Và bạn nên tạo muối duy nhất cho mỗi mục khi bạn tạo băm.

0

Một vấn đề với các cuộc tấn công bạo lực là khi bạn sử dụng mã hóa nhanh như SHA1 hoặc MD5. Các chức năng này được xây dựng để chạy mật khẩu thông qua một thuật toán nhanh. Thay vào đó, bạn có thể sử dụng phương pháp Blowfish, mà không có chuyên gia về, nhưng câu chuyện dài ngắn phải mất nhiều tính toán cho một giá trị trả về, hơn SHA1 hoặc MD5. Điều này có nghĩa là có thể mất 5 năm để bạo lực một mật khẩu, băm với Blowfish vì thời gian tính toán.

Ví dụ tiếp theo được thực hiện với SHA1 và MD5, vì vậy nó dễ bị bruteforce tấn công, tuy nhiên phần muối nên OK để sử dụng:

$salt = md5(microtime().uniqueid()); 

Sản lượng này sẽ là một độc đáo 32 charecter muối, mà bạn sẽ đặt cùng với mật khẩu.

$passwod = $_POST['password']; 
$hashed_password = sha1($password.$salt); 

Bây giờ bạn phải lưu trữ cả mật khẩu và muối trong cơ sở dữ liệu. Và khi bạn kiểm tra mật khẩu người dùng nhập vào, bạn lấy muối và băm toàn bộ điều.

$temp_pass = $_POST['temp_pass']; 
$salt = //from database; 
$database_pass = //hashed pass from database; 

$hashed_temp_pass = sha1($temp_pass.$salt); 

if(hashed_temp_pass == $database_pass){ 
//Welcome user! 
} 
else{ 
//go away 
}