Cách tốt nhất để triển khai trên mạng Hãy nhớ tôi về một trang web là gì? [đóng cửa]


510

Tôi muốn trang web của tôi có một hộp kiểm mà người dùng có thể nhấp để họ sẽ không phải đăng nhập mỗi khi họ truy cập trang web của tôi. Tôi biết tôi sẽ cần lưu trữ một cookie trên máy tính của họ để thực hiện điều này, nhưng những gì nên được chứa trong cookie đó?

Ngoài ra, có những lỗi phổ biến cần chú ý để ngăn cookie này xuất hiện lỗ hổng bảo mật, có thể tránh được trong khi vẫn cung cấp chức năng 'nhớ tôi' không?


5
Kiểm tra stackoverflow.com/questions/549/ (phần II của câu trả lời hàng đầu)
Frosty Z

nếu bạn đang sử dụng ASP.NET, hãy xem codeproject.com/Articles/779844/Remember-Me
Bel tin2014

1
Có một số thông tin rất hữu ích trong Security SE ~ security.stackexchange.com/questions/19676/iêu
b1nary.atr0phy

Câu trả lời hiện được chấp nhận bởi splattne là quá phức tạp. Tạo mã thông báo +16 byte từ một nguồn ngẫu nhiên, băm nó và lưu mã băm + tài khoản trong cơ sở dữ liệu. Sau đó gửi mã thông báo cho người dùng (được mã hóa base64) trong cookie HTTPS + httpOnly (để Javascript không thể truy cập / đánh cắp nó). Bằng cách này, không ai có thể đoán mã thông báo hoặc đăng xuất mọi người bằng các lần đoán không hợp lệ, nhưng ngay cả khi cơ sở dữ liệu của bạn bị hack, không ai có thể sử dụng mã thông báo trong cơ sở dữ liệu (chúng được băm). Vì vậy, chỉ khách hàng ban đầu (hoặc ai đó đánh cắp mã thông báo từ cửa hàng trình duyệt bằng cách nào đó) mới có thể sử dụng nó.
Xeoncross

Câu trả lời:


536

Cải thiện Cookie đăng nhập liên tục Thực hành tốt nhất

Bạn có thể sử dụng chiến lược này được mô tả ở đây là thông lệ tốt nhất (2006) hoặc chiến lược cập nhật được mô tả tại đây (2015):

  1. Khi người dùng đăng nhập thành công với mục Nhớ tôi đã chọn, cookie đăng nhập sẽ được cấp cùng với cookie quản lý phiên chuẩn.
  2. Cookie đăng nhập chứa mã định danh sê-ri và mã thông báo . Chuỗi và mã thông báo là số ngẫu nhiên không thể đoán từ một không gian rộng lớn phù hợp. Cả hai được lưu trữ cùng nhau trong một bảng cơ sở dữ liệu, mã thông báo được băm (sha256 là tốt).
  3. Khi người dùng không đăng nhập truy cập trang web và xuất hiện cookie đăng nhập, số nhận dạng sê-ri sẽ được tra cứu trong cơ sở dữ liệu .
    1. Nếu số nhận dạng sê-ri hiện diện và hàm băm của mã thông báo khớp với hàm băm cho số nhận dạng sê-ri đó, người dùng được coi là xác thực . Mã thông báo mới được tạo, hàm băm mới cho mã thông báo được lưu trữ trên bản ghi cũ và cookie đăng nhập mới được cấp cho người dùng (bạn có thể sử dụng lại mã định danh sê-ri ).
    2. Nếu chuỗi có mặt nhưng mã thông báo không khớp, hành vi trộm cắp được giả định. Người dùng nhận được một cảnh báo mạnh mẽ và tất cả các phiên nhớ của người dùng sẽ bị xóa.
    3. Nếu tên người dùng và sê-ri không có mặt, cookie đăng nhập sẽ bị bỏ qua .

Cách tiếp cận này cung cấp phòng thủ chuyên sâu. Nếu ai đó quản lý để rò rỉ bảng cơ sở dữ liệu, nó sẽ không cung cấp cho kẻ tấn công một cánh cửa mở để mạo danh người dùng.


20
xem thêm: stackoverflow.com/questions/549/ Bạn không nên đọc phiên bản 'cải tiến'
Jacco

8
Vấn đề với điều này là bạn để lộ tên người dùng trong cookie, mặc dù đây là những gì Gmail làm. Tại sao bạn cần cả ID loạt và mã thông báo? Sẽ không một mã thông báo lớn hơn sẽ ổn chứ?
Dan Rosenstark

10
Ngoài ra, liên quan đến mô hình này, những gì để ngăn chặn kẻ tấn công ăn cắp và hơn là đặt cookie vào máy tính của anh ta và xóa cookie khỏi máy tính bị hack. Máy tính của anh ta sẽ được xác thực và cập nhật khi cần mà không biết máy tính bị hack bao giờ biết? Thay đổi duy nhất là người dùng máy tính bị hack sẽ phải đăng nhập lại và đặt nhớ tôi. Việc người dùng bị hack có nhận ra điều này hay không là không chắc chắn.

24
@HiroProtagonist Bộ nhận dạng sê-ri là để ngăn chặn một cuộc tấn công DoS. Không có nó, tôi có thể nhanh chóng viết một tập lệnh đánh vào trang web của bạn với mỗi tên người dùng và mã thông báo không hợp lệ, đăng xuất mọi người trên trang web của bạn.
Chris Moschini

6
Giải pháp này là SAU, nó không xử lý cuncurrency: Nếu hai yêu cầu xác thực nhớ tôi đến cùng một lúc, với cùng một cookie nhớ tôi, cái đầu tiên thành công và thay đổi mã thông báo, cái thứ hai gây ra xác thực không thành công và một cảnh báo sai (vì mã thông báo đã được thay đổi bởi yêu cầu đầu tiên). (Tình huống này có thể xảy ra khi trình duyệt khởi động và trang web được khôi phục trong hai tab trình duyệt.)
slobo

9

Tôi sẽ lưu trữ ID người dùng và mã thông báo. Khi người dùng quay lại trang web, hãy so sánh hai mẩu thông tin đó với một thứ liên tục như mục nhập cơ sở dữ liệu.

Về bảo mật, chỉ cần không đặt bất cứ thứ gì vào đó sẽ cho phép ai đó sửa đổi cookie để có thêm lợi ích. Ví dụ: không lưu trữ nhóm người dùng hoặc mật khẩu của họ. Bất cứ điều gì có thể được sửa đổi sẽ phá vỡ bảo mật của bạn không nên được lưu trữ trong cookie.


8

Lưu trữ UserId của họ và một Ghi nhớ. Khi họ đăng nhập bằng nhớ tôi đã kiểm tra, tạo một Ghi nhớ mới (làm mất hiệu lực mọi máy khác được đánh dấu là ghi nhớ tôi).

Khi họ quay lại, hãy tìm kiếm chúng bằng mã thông báo nhớ tôi và đảm bảo UserId khớp.


Điều này có thể được vũ phu buộc trong vài giây. Tôi sẽ chỉ đặt user_id của mình thành 1 và vũ phu tất cả các mã thông báo. Nó sẽ cho tôi quyền truy cập sau vài giây
Một người bạn

4

Điều tra các phiên liên tục bản thân tôi Tôi thấy rằng nó đơn giản là không đáng để mạo hiểm bảo mật. Sử dụng nó nếu bạn hoàn toàn phải làm, nhưng bạn nên xem xét một phiên như vậy chỉ được xác thực yếu và buộc đăng nhập mới cho bất kỳ thứ gì có thể có giá trị đối với kẻ tấn công.

Lý do tất nhiên là các cookie của bạn chứa phiên liên tục của bạn rất dễ bị đánh cắp.

4 cách để đánh cắp cookie của bạn (từ nhận xét của Jens Roland trên trang@splattne dựa trên câu trả lời của anh ấy):

  1. Bằng cách chặn nó trên một dòng không an toàn (đánh hơi gói / chiếm quyền điều khiển phiên)
  2. Bằng cách truy cập trực tiếp vào trình duyệt của người dùng (thông qua phần mềm độc hại hoặc quyền truy cập vật lý vào hộp)
  3. Bằng cách đọc nó từ cơ sở dữ liệu máy chủ (có thể là SQL Injection, nhưng có thể là bất cứ điều gì)
  4. Bằng cách hack XSS (hoặc khai thác phía máy khách tương tự)

104
1. HTTPS được thiết kế để ngăn chặn điều này. 2. Luôn đăng nhập Không phải là vấn đề bảo mật ở đây, bạn có vấn đề lớn hơn. 3. Giống như 2. 4. Điều này có thể được ngăn chặn bằng chính sách kiểm soát truy cập và vệ sinh đầu vào tốt; nếu bạn không thực hiện các bước này, bạn lại gặp vấn đề lớn hơn là Đăng nhập.
Chris Moschini
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.