URL https với thông số mã thông báo: an toàn như thế nào?

Question

Trên trang web của chúng tôi, chúng tôi cung cấp cho người dùng mô phỏng dựa trên thông tin cá nhân của họ (được cung cấp thông qua biểu mẫu). Chúng tôi muốn cho phép họ quay lại kết quả mô phỏng của họ sau, nhưng không buộc họ phải tạo tài khoản đăng nhập/mật khẩu.

Chúng tôi đã nghĩ đến việc gửi cho họ một email có liên kết, từ đó họ có thể lấy lại kết quả của họ. Nhưng, một cách tự nhiên, chúng tôi phải bảo mật URL này, vì dữ liệu cá nhân bị đe dọa.

Vì vậy, chúng tôi dự định chuyển một mã thông báo (như kết hợp 40 ký tự chữ cái và chữ số, hoặc mã băm MD5) trong URL và sử dụng SSL.

Cuối cùng, họ sẽ nhận được một email như thế:

Hi,
Nhận lại kết quả của bạn trên https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn

Bạn nghĩ gì về nó? Nó có đủ an toàn không? Bạn sẽ tư vấn cho tôi về việc tạo mã thông báo? Điều gì về việc chuyển các tham số URL trong yêu cầu https?

Answer 1

SSL sẽ bảo vệ thông số truy vấn khi chuyển tiếp; tuy nhiên, bản thân email không an toàn và email có thể bị trả lại cùng với bất kỳ số lượng máy chủ nào trước khi đến đích.

Cũng tùy thuộc vào máy chủ web của bạn, URL đầy đủ có thể đăng nhập vào các tệp nhật ký của nó. Tùy thuộc vào mức độ nhạy cảm của dữ liệu mà bạn có thể không muốn những người CNTT có quyền truy cập vào tất cả các mã thông báo.

Ngoài ra, URL có chuỗi truy vấn sẽ được lưu trong lịch sử của người dùng, cho phép những người dùng khác của cùng một máy truy cập URL.

Cuối cùng và điều làm cho điều này rất không an toàn, URL được gửi trong tiêu đề Người giới thiệu của tất cả các yêu cầu cho bất kỳ tài nguyên nào, ngay cả tài nguyên của bên thứ ba. Vì vậy, nếu bạn sử dụng Google Analytics chẳng hạn, bạn sẽ gửi cho Google mã thông báo URL trong và tất cả cho họ.

Theo tôi, đây là một ý tưởng tồi.

Answer 2

E-mail vốn không an toàn. Nếu bất cứ ai có thể nhấp vào liên kết đó và truy cập dữ liệu, bạn không thực sự bảo vệ dữ liệu đó.

Answer 3

SSL đóng chặt nội dung của dữ liệu đang chuyển, nhưng tôi không chắc chắn về URL.

Bất kể, một cách để giảm thiểu kẻ tấn công sử dụng lại mã thông báo URL đó là đảm bảo mỗi mã thông báo chỉ có thể được sử dụng một lần. Bạn thậm chí có thể thiết lập một cookie để người dùng hợp pháp có thể tiếp tục sử dụng liên kết, nhưng sau lần truy cập đầu tiên nó sẽ chỉ hoạt động cho một người nào đó với cookie.

Nếu email của người dùng bị xâm phạm và kẻ tấn công nhận được liên kết đầu tiên, tốt, bạn đang bị hosed. Nhưng người dùng cũng có vấn đề lớn hơn.

Answer 4

Bạn biết rằng nếu có bất kỳ tin tặc nào truy cập vào cơ sở dữ liệu của bạn, bạn có thể tự do cung cấp thông tin cá nhân?

Sau đó tôi sẽ nói rằng điều này không phải là xấu như ý tưởng. Tôi sẽ không sử dụng MD5 hoặc SHA1 vì chúng không an toàn cho băm. Chúng có thể được "giải mã" (tôi biết nó không phải là mã hóa) khá dễ dàng.

Nếu không, tôi có thể sẽ sử dụng thông tin thứ hai sẽ không được gửi bằng loại mật khẩu email. Lý do khá đơn giản, nếu ai đó có quyền truy cập vào email của người dùng (khá dễ dàng với hotmail nếu bạn không giết phiên của bạn), anh ta sẽ có quyền truy cập vào bất kỳ thông tin nào mà người dùng đã gửi.

Lưu ý rằng HTTPS sẽ bảo mật và mã hóa dữ liệu được gửi từ trang web của bạn đến người dùng cuối. Không có gì khác, lấy nó như một bộ điều khiển an toàn. Không có gì ít hơn nữa.

Answer 5

Mã thông báo an toàn khi được chuyển qua SSL. Vấn đề bạn cần phải có là nó có thể cho mọi người (những người không có ý định) bằng cách có thể xem URL.

Nếu đó là thông tin cá nhân như SSN, tôi không nghĩ mình sẽ gửi URL thông qua email. Tôi muốn họ tạo tên người dùng và mật khẩu cho trang web. Thật dễ dàng để thỏa hiệp một email với loại thông tin đó đang bị đe dọa cho bạn và cho họ. Nếu tài khoản của ai đó bị bắt buộc, nó sẽ đi vào quesion có lỗi thực sự là nó. Bạn càng bảo vệ tốt hơn quan điểm nghiêm ngặt của CYA.

Answer 6

Từ những gì tôi hiểu ý tưởng của bạn, trong lý thuyết ai đó có thể nhập một chuỗi ký tự ngẫu nhiên 40 hoặc MD5 băm và nhận chi tiết của ai đó. Trong khi điều này có thể rất khó, nó chỉ cần xảy ra một lần.

Một sự hòa tan tốt hơn có thể là gửi cho người dùng một mã thông báo sau đó yêu cầu họ nhập một số chi tiết, chẳng hạn như tên, mã bưu điện, ssn hoặc kết hợp của chúng.

Answer 7

Tôi thực sự sẽ không cân nhắc điều đó đủ an toàn cho một tình huống có vấn đề về quyền riêng tư nghiêm trọng. Thực tế là bạn đang gửi URL trong một email (có lẽ là văn bản rõ ràng) đến nay là liên kết yếu nhất. Sau đó là nguy cơ tấn công brute force trên thẻ, mà (thiếu cấu trúc của một cơ chế xác thực thực) có thể dễ bị tổn thương hơn là thiết lập tên người dùng và mật khẩu được xây dựng tốt.

Không có vấn đề gì cả với các tham số trong yêu cầu https, tình cờ.

Answer 8

Tôi muốn sử dụng cookie cho điều đó. Quy trình làm việc phải như sau:

1. Người dùng truy cập trang web của bạn lần đầu tiên.
2. Trang web đặt cookie
3. Người dùng nhập dữ liệu. Dữ liệu được lưu trữ trong DB bằng cách sử dụng một số khóa được lưu trữ trong cookie.
4. Khi người dùng rời đi, bạn gửi cho họ email có https: liên kết
5. Khi người dùng quay lại, trang web phát hiện ra cookie và có thể trình bày cho người dùng dữ liệu cũ.

Hiện tại, người dùng muốn sử dụng trình duyệt khác trên một máy khác. Trong trường hợp này, hãy cung cấp nút "chuyển". Khi người dùng nhấp vào nút này, cô ấy sẽ nhận được "mã thông báo". Cô ấy có thể sử dụng mã thông báo này trên một máy tính khác để đặt lại cookie. Bằng cách này, người dùng quyết định mức độ an toàn mà cô ấy muốn chuyển mã thông báo.

Answer 9

Vì vậy, đó sẽ là một ý tưởng tồi. Bạn sẽ làm xói mòn bảo mật bằng cách sử dụng dễ dàng. Như đã nói trước khi SSL sẽ chỉ bảo vệ việc truyền thông tin giữa trình duyệt máy chủ và máy khách và sẽ chỉ ngăn chặn cuộc tấn công của người trung gian. Email rất nguy hiểm và không an toàn.

Tốt nhất là tên người dùng và xác thực mật khẩu để truy cập thông tin.

Tôi thích ý tưởng cookie nhiều hơn hoặc ít hơn.Bạn cũng nên mã hóa thông tin cookie. Bạn cũng nên tạo mã thông báo bằng muối và cụm từ khóa cộng với $ _SERVER ['HTTP_USER_AGENT'] để hạn chế xác suất của cuộc tấn công. Lưu trữ càng nhiều thông tin không nhạy cảm về khách hàng trong cookie để sử dụng xác minh.

Các cụm từ then chốt có thể được lưu trữ trong cookie để sử dụng dễ dàng nhưng hãy nhớ rằng cũng Cookie có thể bị đánh cắp = (.

Better để cho các khách hàng gõ cụm từ quan trọng mà ông cung cấp, mà cũng được lưu giữ trong

Hoặc, khóa có thể được sử dụng trong trường hợp người đó sử dụng một máy khác với thông số $ _SERVER ['HTTP_USER_AGENT'] hoặc đơn giản là bỏ cookie. hoặc thiết lập

Cũng đảm bảo rằng dữ liệu nhạy cảm được mã hóa trong cơ sở dữ liệu. Bạn không bao giờ biết;)