2011-01-23 29 views
8

Tôi đã tự hỏi cách đăng nhập cookie an toàn nhất là gì? Nếu bạn chỉ lưu trữ mật khẩu (được mã hóa bằng muối) và tên người dùng trong cookie và xác thực nó trên bảng người dùng, kẻ tấn công tiềm năng có thể lấy cắp cookie và đăng nhập. Mọi người thường không kiểm tra có 'lần cuối cùng trực tuyến'.Cách tương đối an toàn khi sử dụng cookie đăng nhập là gì?

Vì vậy, có cách nào tốt hơn cho 'nhớ cookie của tôi'? IP không phải là một lựa chọn tốt, phải không? (Một số máy thay đổi IP mọi lúc).

cách
+1

Vui lòng cho chúng tôi biết điều gì đó về ứng dụng của bạn sẽ sử dụng tính năng này. Tác động tiềm tàng của hành vi trộm cắp danh tính/nhận dạng là gì? – Gumbo

+0

hầu hết các máy thay đổi IP mọi lúc ... – Shoe

+2

Tính năng "nhớ tôi" không an toàn theo định nghĩa. Vì vậy, đó là vào bạn để lựa chọn giữa khả năng sử dụng và hoang tưởng. –

Trả lời

19

Tôi nghĩ mình đã tìm được giải pháp thông minh!

Ưu điểm của việc này (phức tạp?) Kịch bản:.

  • Khi người dùng đăng nhập thành công trong với Ghi nhớ kiểm tra, một cookie đăng nhập được cấp ngoài các quản lý chuẩn của phiên Cookie [2 ]
  • Cookie đăng nhập chứa tên người dùng của người dùng, số nhận dạng chuỗi và mã thông báo. Chuỗi và mã thông báo là các số ngẫu nhiên không thể tránh khỏi từ một không gian lớn phù hợp. Cả ba được lưu trữ cùng nhau trong một bảng cơ sở dữ liệu.
  • Khi người dùng không đăng nhập truy cập trang web và hiển thị cookie đăng nhập, tên người dùng, chuỗi và mã thông báo được tra cứu trong cơ sở dữ liệu.
  • Nếu bộ ba có mặt, người dùng được coi là đã được xác thực. Mã thông báo được sử dụng được xóa khỏi cơ sở dữ liệu. Mã thông báo mới được tạo, được lưu trữ trong cơ sở dữ liệu có tên người dùng và số nhận dạng theo cùng một chuỗi và một cookie đăng nhập mới chứa tất cả ba là cấp cho người dùng.
  • Nếu tên người dùng và chuỗi là hiện tại nhưng mã thông báo không khớp, giả định hành vi trộm cắp. Người dùng nhận được cảnh báo mạnh mẽ và tất cả phiên nhớ của người dùng bị xóa .
  • Nếu tên người dùng và chuỗi không phải là , cookie đăng nhập sẽ bị bỏ qua.

Tôi đã thực hiện một bảng trong cơ sở dữ liệu với các thông tin sau:

session | token | username | expire 

Các nhớ tôi cookie sẽ có thiết lập này:

$value = "$session|$token|$userhash"; //Total length = 106 
  • Session sẽ là một chuỗi trong số 40 (sha1) ký tự.
  • Token sẽ là một chuỗi gồm 32 (md5) ký tự.
  • Userhash trong cookie sẽ là chuỗi 32 (md5 tên người dùng) ký tự.
  • Username trong cơ sở dữ liệu sẽ là tên người dùng thông thường .
  • Expire sẽ hiện là + 60 ngày.

Kịch bản:

if(isset($_SESSION['check']) || $_SESSION['check']){ 
    //User is logged in 
}else if(isset($_COOKIE['remember']) && strlen($_COOKIE['remember'])==106){ 
    //THERE is a cookie, which is the right length 40session+32token+32user+2'|' 
    //Now lets go check it... 
    conncectdb(); //Sets connection 
    //How do I protect this script form harmful user input? 
    $plode = explode('|',$_COOKIE['remember']); 
    $session = mysql_real_escape_string($plode[0]); 
    $token = mysql_real_escape_string($plode[1]); 
    $userhash = mysql_real_escape_string($plode[2]); 
    $result = mysql_query(" SELECT user 
       FROM tokens 
       WHERE session = '$session' 
       AND token = '$token' 
       AND md5(user) = '$userhash';") 
    if(mysql_num_rows($result)==1){ 
     //COOKIE is completely valid! 
     //Make a new cookie with the same session and another token. 
     $newusername = mysql_result($result,0,0); 
     $newsession = $session; 
     $newtoken = md5(uniqid(rand(), true)); 
     $newuserhash = md5($username); 
     $value = "$newsession|$newtoken|$newuserhash"; 
     $expire = time()+4184000; 
     setcookie('remember', $value, $expire, '/', 'www.example.com', isset($_SERVER["HTTPS"]), true); 
     mysql_query(" UPDATE tokens 
       SET token='$newtoken', expire='$expire' 
       WHERE session = '$session' 
       AND token = '$token' 
       AND md5(user)='$userhash';"); 
     //Set-up the whole session (with user details from database) etc... 
    } else if(mysql_num_rows(mysql_query("SELECT user FROM tokens WHERE session = '$session' AND md5(user) = '$userhash';"))==1)){ 
     //TOKEN is different, session is valid 
     //This user is probably under attack 
     //Put up a warning, and let the user re-validate (login) 
     //Remove the whole session (also the other sessions from this user?) 
    } else { 
     //Cookie expired in database? Unlikely... 
     //Invalid in what way? 
    } 
} else { 
    //No cookie, rest of the script 
} 

Ưu điểm của kịch bản:

  • Nhiều đăng nhập. Bạn có thể tạo các phiên mới cho mỗi máy tính bạn đang sử dụng.
  • Cookie và cơ sở dữ liệu sẽ luôn sạch sẽ. Người dùng đang hoạt động gia hạn cookie mỗi lần đăng nhập .
  • Kiểm tra phiên tại đầu đảm bảo rằng cơ sở dữ liệu sẽ không nhận yêu cầu vô dụng.
  • Nếu kẻ tấn công đánh cắp một cookie, nó nhận mã thông báo mới, chứ không phải phiên mới . Vì vậy, khi người dùng thực sự truy cập trang web có mã thông báo cũ (không hợp lệ) nhưng VỚI người dùng hợp lệ phiên kết hợp người dùng nhận được cảnh báo về hành vi trộm cắp tiềm năng. Sau khi xác thực lại bằng cách đăng nhập vào phiên mới được tạo và phiên lệnh giữ kẻ tấn công không hợp lệ. Việc xác nhận lại đảm bảo nạn nhân thực sự là nạn nhân chứ không phải là kẻ tấn công .

tham khảo: http://jaspan.com/improved_persistent_login_cookie_best_practice

+0

Tôi thấy không có seinse trong giải pháp này. Mục đích của trường phiên trong bảng này là gì? tại sao bảng chuyên dụng ở tất cả? Tại sao không lưu trữ chỉ một băm được tạo ra từ dữ liệu của một số người dùng? –

+0

Bất kỳ giải pháp nào khác cũng sẽ cho phép bạn có nhiều phiên làm việc, mà không cần thêm bảng, mà không làm phức tạp tập lệnh của bạn –

+0

Điều này giới hạn thời gian của kẻ tấn công có thể sử dụng tài khoản của bạn. – SuperSpy

3

phổ biến nhất:

  • Nhiều kịch bản sử dụng một số loại theo dõi phiên. Khi người dùng truy cập trang web lần đầu tiên, nó tạo một ID ngẫu nhiên duy nhất cho người dùng và thông tin phiên cửa hàng trong máy chủ và ID trong cookie. Sau đó, máy chủ xác định người dùng bằng ID duy nhất (được gọi là ID phiên). Thông tin liên quan đến ID phiên chỉ có thể được xem bởi máy chủ. PHP sử dụng tùy chọn này theo mặc định,

  • Một số lưu trữ dữ liệu người dùng trong chính cookie, nhưng với chữ ký HMAC sử dụng chuỗi bí mật làm khóa. Tập lệnh loại bỏ cookie nếu chữ ký không khớp. Bằng cách này, máy chủ không phải giữ dữ liệu phiên trên máy chủ. Người dùng nhìn thấy những gì trong phiên bằng cách xem cookie, vì vậy bạn không nên lưu trữ dữ liệu nhạy cảm trong đó. Chỉ cần ID người dùng (và có thể là thời gian đăng nhập và thời gian hết hạn của cookie) là đủ. Mặc dù người dùng có thể xem thông tin trong phiên nào, chữ ký trong cookie đảm bảo rằng người dùng không thể tự sửa đổi dữ liệu phiên.

Những cách này cung cấp một số bảo mật, người dùng không thể giả mạo dữ liệu phiên nhưng không bảo vệ người dùng khỏi người nghe trộm. Họ luôn có thể sử dụng một gói sniffer và ăn cắp một phiên từ bất kỳ mạng WiFi mở. Một số ứng dụng dựa trên IP của người dùng nhưng không quan trọng nếu kẻ tấn công nằm trong cùng một mạng. Một số ứng dụng dựa vào User-Agent, nhưng sẽ có vấn đề khi người dùng cập nhật trình duyệt của họ hoặc nhập dữ liệu từ trình duyệt khác.

Nếu bạn thực sự quan ngại về bảo mật, thì use HTTPS.

Đồng thời đọc this article, đặc biệt là phần được gọi là Nhà điều hành trang web khắc phục sự cố như thế nào?

+0

Văn bản dài chứ không phải một từ duy nhất về chủ đề. Và một upvote từ một trong những người không đọc nhưng chỉ ấn tượng bởi kích thước văn bản. –

+0

Không phải là chủ đề về cookie đăng nhập và bảo mật của nó? Đó là những gì tôi đang nói về câu trả lời. – Thai

+0

Nó hoàn toàn trong chủ đề và nó đã cho tôi thêm một số ý tưởng về ID phiên và công cụ HTTPS. Tôi đã upvoted. – Shoe

6

Như một “nhớ đến tôi” tính năng luôn luôn là một nguy cơ bảo mật bổ sung.

Bởi vì giống như trong một phiên bạn chỉ có một định danh mà không cũng đủ chỉ để xác định một người dùng (nó là ai?) mà còn để xác thực người dùng (Là nó thực sự anh ấy/cô ấy?) mà không làm xác thực thực tế.

Nhưng ngược lại với phiên có (hoặc phải có) chỉ một thời gian ngắn (ít hơn một giờ) và số nhận dạng (hoặc phải) thay đổi định kỳ (dựa trên thời gian và sự cần thiết do tính xác thực/thay đổi trạng thái thẩm quyền), số nhận dạng “nhớ tôi” có giá trị trong nhiều ngày nếu không kể cả tháng hoặc năm! Và thời hạn hiệu lực dài này gây ra thêm một nguy cơ bảo mật.

Vì vậy, trước khi hỏi cách triển khai tính năng "nhớ tôi", bạn nên tự hỏi mình có thực sự muốn có thêm rủi ro bảo mật không. Điều đó chủ yếu phụ thuộc vào các tài sản mà ứng dụng của bạn có và mục đích xác thực có và nếu bạn muốn mạo hiểm mạo danh/nhận dạng trộm cắp mà tính năng “nhớ tôi” đặt ra.

Nếu vậy, hãy đảm bảo cung cấp bảo mật cơ bản bằng cách sử dụng HTTPS và đặt cờ HTTPOnlysecure flag in your cookies. Sau đó, bạn có thể làm như sau để xây dựng như một “nhớ đến tôi” tính năng:

  • xác thực yêu cầu
    Nếu người dùng xác thực thông qua HTTPS và thiết lập các “nhớ đến tôi” tùy chọn, tạo ra một ngẫu nhiên nhớ tôi mã thông báo, lưu trữ nó ở phía máy chủ trong cơ sở dữ liệu “nhớ tôi” và đặt nhớ tôi cookie với cờ an toàn với giá trị đó. Sau đó, bắt đầu phiên mới và đặt nhớ tôi cờ.

  • Mọi yêu cầu khác

    1. Nếu không có phiên hiện tại, chuyển hướng đến nhớ tôi trang thông qua HTTPS để kiểm tra liệu có một nhớ tôi cookie. Nếu có mã số hãy nhớ tôi và nó hợp lệ, vô hiệu hóa, tạo mã mới, lưu trữ trong cơ sở dữ liệu “nhớ tôi”, đặt cookie với mã thông báo mới đó và tạo phiên mới với nhớ tôi đặt cờ. Nếu không, hãy chuyển hướng đến trang đăng nhập.
    2. Nếu phiên hiện tại không hợp lệ (hãy đảm bảo sử dụng strict session invalidation), chuyển hướng đến trang nhớ tôi qua HTTPS nếu cờ nhớ tôi được đặt; nếu không hãy chuyển hướng đến trang đăng nhập.

Với cách làm này xác thực được đảm bảo thông qua HTTPS, cả xác thực ban đầu và “nhớ đến tôi” xác thực.Và người dùng chỉ xác thực trong phiên hiện tại; nếu nó hết hạn, người dùng phải xác thực lại bằng cách sử dụng mã thông báo nhớ tôi hoặc cung cấp thông tin xác thực đăng nhập của họ. Và khi ghi nhớ tôi mã thông báo được lưu trữ trong cơ sở dữ liệu, người dùng có thể vô hiệu hóa bất kỳ mã hiện tại nào nhớ tôi.

+0

'nếu bạn thực sự muốn có thêm nguy cơ bảo mật' Tôi có thể giới hạn người dùng được xác thực cookie để ngăn chặn thiệt hại. Kiểm tra tập lệnh của tôi bên dưới, bạn sẽ không bao giờ nhận được mã thông báo ngẫu nhiên may mắn vì nếu mã thông báo giống nhau, người dùng phải giống hệt nhau. Tôi muốn ghi nhớ tôi thường xuyên hơn, thay vì vậy chỉ cần sửa phiên sẽ hết hạn thành giá trị cao hơn. – SuperSpy

+0

Đây là câu trả lời, nhưng (đối với tôi) không phải là câu trả lời. – SuperSpy

Các vấn đề liên quan