Các URL riêng tư, không thể truy cập có tương đương với xác thực dựa trên mật khẩu không?


128

Tôi muốn tiết lộ một tài nguyên trên web. Tôi muốn bảo vệ tài nguyên này: để đảm bảo rằng nó chỉ có thể truy cập được đối với một số cá nhân.

Tôi có thể thiết lập một số loại xác thực dựa trên mật khẩu . Ví dụ: tôi chỉ có thể cho phép truy cập vào tài nguyên thông qua một máy chủ web kiểm tra các yêu cầu đến để có thông tin xác thực chính xác (có thể chống lại một số cơ sở dữ liệu sao lưu của người dùng) trước khi cung cấp tệp.

Thay phiên tôi chỉ có thể sử dụng một URL riêng tư . Đó là, tôi chỉ có thể lưu trữ tài nguyên tại một số đường dẫn không thể đoán, ví dụ https://example.com/23idcojj20ijf..., điều này hạn chế quyền truy cập vào những người biết chuỗi chính xác.

Từ quan điểm của một kẻ bất lương muốn truy cập tài nguyên này, những cách tiếp cận này có tương đương không? Nếu không, điều gì làm cho chúng khác nhau? Và theo khả năng duy trì, có những ưu và nhược điểm đối với một trong hai cách tiếp cận mà tôi nên biết trước khi thực hiện cái này hay cái khác?


45
Cách tiếp cận này thường chỉ được sử dụng mà không cần xác thực cho những thứ như đặt lại mật khẩu. Liên kết vô duyên thường hết hạn trong một khoảng thời gian ngắn và chỉ có thể được sử dụng bởi một người đã được xác thực bán (tức là trang web đã biết địa chỉ email mà liên kết được gửi đến).
Robert Harvey

6
Thảo luận liên quan về bảo mật.SE: security.stackexchange.com/q/58215/37496
Đánh dấu

9
@MonkeyZeus nó không bảo mật thông qua che khuất. Bí mật, thông thường là mật khẩu, trong trường hợp này là một URL.
Davidmh

16
@MonkeyZeus: Bảo mật thông qua che khuất đề cập đến việc giữ bí mật việc thực hiện cơ chế, không sử dụng các khóa tối nghĩa. Nếu các url vô duyên là bảo mật thông qua che khuất, thì mật khẩu mạnh cũng được.
JacquesB

1
@GladstoneKeep hãy ghi nhớ các công cụ rút ngắn URL. Một khi ai đó độc hại sử dụng một trong số họ, liên kết sẽ dễ đoán / ghi lại hơn nhiều.
RookieTEC9

Câu trả lời:


203

URL riêng có phần yếu hơn xác thực bằng thông tin xác thực, ngay cả khi kích thước bit của URL giống với thông tin đăng nhập. Lý do là URL có thể dễ dàng "rò rỉ" hơn. Nó được lưu trong bộ nhớ cache, đăng nhập trên máy chủ, v.v. Nếu bạn có các liên kết ngoài, URL riêng có thể hiển thị trong tiêu đề người giới thiệu trên các trang web khác. (Nó cũng có thể được nhìn thấy bởi những người nhìn qua vai bạn.)

Nếu nó bị rò rỉ (do tai nạn hoặc do sự bất cẩn của người dùng), nó có thể sẽ bị Google công khai và thậm chí được lập chỉ mục, điều này sẽ cho phép kẻ tấn công dễ dàng tìm kiếm tất cả các URL bị rò rỉ vào trang web của bạn!

Vì lý do này, các URL riêng tư thường chỉ được sử dụng cho các thao tác một lần như đặt lại mật khẩu và thông thường chúng chỉ hoạt động trong một thời gian giới hạn.


Có một chủ đề liên quan tại Bảo mật thông tin: URL ngẫu nhiên có phải là cách an toàn để bảo vệ ảnh tiểu sử không? - một câu trả lời chia sẻ câu chuyện này: Dropbox vô hiệu hóa các liên kết được chia sẻ cũ sau khi khai thuế kết thúc trên Google . Vì vậy, nó không chỉ là một rủi ro lý thuyết.


7
Phân minh nhỏ, nhưng "thường chỉ được sử dụng cho các thao tác một lần bắn" dường như là một tuyên bố quá mức cho rằng Dropbox (và có lẽ các dịch vụ đám mây khác) đang sử dụng chúng để "bảo vệ" quyền truy cập vào tệp.
Steve Jessop

4
Tôi sẽ thêm rằng người dùng được dạy, với thành công hạn chế, để bảo vệ mật khẩu của họ, nhưng không bảo vệ URL của họ.
svavil

1
Bạn nên thêm rằng nhiều mối lo ngại về kỹ thuật có thể được giảm thiểu bằng cách sử dụng một tham số trong URL riêng để xzy.com/myDoc?auth=8502375 và chuyển hướng tự động đến một url đơn giản sau khi kiểm tra xác thực. - Nhưng điều này không giải quyết được tất cả các vấn đề có thể xảy ra
Falco

3
TL; DR - không có thứ gọi là URL bí mật. Có một cuộc tấn công hiện tại làm lộ URL cho một tác nhân độc hại tại các điểm truy cập WiFi ngay cả khi bạn thường gửi URL qua HTTPS. Cuộc tấn công lạm dụng Tự động phát hiện Web Proxy (WPAD), buộc trình duyệt của bạn phải gửi tất cả các URL của bạn cho kẻ tấn công. Xem (ví dụ) arstechnica.com/security/2016/07/ trên
Harald

5
@JacquesB Không phải là một số rủi ro mà bạn đã xác định được giảm thiểu bằng cách đặt phần riêng tư vào phần phân đoạn của URL (tức là sau "#", ví dụ như Stack Exchange thực hiện cho các phản hồi xác thực Oauth của nó)? Ví dụ: tiêu đề người giới thiệu không được phép bao gồm đoạn .
Jason C

48

Ghi chú:

Rất nhiều người dường như nhầm lẫn một URL "riêng tư" với xác thực. Ngoài ra, dường như có một số nhầm lẫn rằng việc gửi liên kết thông qua một thực thể đáng tin cậy là một nỗ lực xác thực hai yếu tố. Để rõ ràng, chúng ta đang nói về một tài nguyên có thể truy cập công khai, mặc dù tài nguyên đó đủ khó đoán.

Khi sử dụng URL riêng tư, bạn phải luôn cho rằng nó có thể bị xâm phạm - bạn nên thiết kế một URL như vậy để ngay cả khi nó bị xâm phạm, tài nguyên sẽ không rò rỉ thông tin cho kẻ tấn công.


URL riêng tư / khó đoán không tương đương với xác thực dựa trên mật khẩu. Về bản chất, các URL riêng tư hoàn toàn không riêng tư - chúng là các tài nguyên có thể truy cập công khai. Tôi nghĩ rằng thuật ngữ URL "riêng tư" là một cách viết sai, thay vào đó chúng là các URL "tối nghĩa".

Có một số trường hợp nhất định khi sử dụng URL "riêng tư" có thể được chấp nhận, nhưng chúng vốn kém an toàn hơn các phương thức xác thực truyền thống như xác thực mật khẩu hoặc xác thực dựa trên khóa.

Một số địa điểm tôi thường thấy URL "riêng tư" được sử dụng là:

  1. Mật khẩu đặt lại email
  2. Email tạo chứng chỉ
  3. Email xác nhận tài khoản / email
  4. Cung cấp nội dung đã mua (sách điện tử, v.v.)
  5. Những thứ linh tinh khác như làm thủ tục chuyến bay, in thẻ lên máy bay, sử dụng URL riêng ngoài xác thực truyền thống

Điểm chung ở đây là các URL ngẫu nhiên thường chỉ tốt cho các thao tác một lần. Ngoài ra, xác thực truyền thống và URL ngẫu nhiên không loại trừ lẫn nhau - thực sự, chúng có thể được sử dụng kết hợp với nhau để cung cấp bảo mật bổ sung khi phân phối tài nguyên.


Như Robert Harvey đã chỉ ra, cách duy nhất để sử dụng URL ngẫu nhiên / riêng tư một cách an toàn là tạo trang động và gửi URL cho người dùng theo cách mà người dùng có thể được coi là bán xác thực. Đây có thể là email, SMS, v.v.

Một URL riêng / được tạo ngẫu nhiên thường có một vài thuộc tính:

  1. Nó sẽ hết hạn sau một khoảng thời gian hợp lý
  2. Nó phải là một URL sử dụng một lần: IE nó sẽ hết hạn sau lần truy cập đầu tiên.
  3. Nó nên trì hoãn xác thực người dùng với một số thực thể khác mà họ tin tưởng để xác thực an toàn cho người dùng. (Bằng cách gửi liên kết qua email hoặc SMS, v.v.)
  4. Một máy tính hiện đại không thể buộc URL trong khung thời gian trước khi hết hạn - bằng cách giới hạn tốc độ API làm lộ tài nguyên hoặc bằng cách tạo một điểm cuối url với đủ entropy sao cho không thể đoán được.
  5. Nó không nên rò rỉ thông tin về người dùng. IE: Nếu trang là để đặt lại mật khẩu: trang sẽ không hiển thị thông tin tài khoản người yêu cầu. Nếu Alice yêu cầu một liên kết đặt lại mật khẩu và Bob bằng cách nào đó đoán URL, Bob sẽ không có cách nào để biết mật khẩu mà anh ta đang đặt lại.
  6. Nếu nó rò rỉ thông tin về người dùng, thì nó nên được sử dụng trên đầu xác thực truyền thống, ví dụ, một trang có thể xem xét người dùng được xác thực nếu họ có bộ cookie hoặc nếu session_id của họ vẫn hợp lệ.

Tài nguyên khác nhau đòi hỏi mức độ bảo mật khác nhau. Ví dụ, nếu bạn muốn chia sẻ một công thức bí mật với một số bạn bè, có thể chấp nhận sử dụng URL ngẫu nhiên / riêng tư để chia sẻ nó với họ. Tuy nhiên, nếu tài nguyên có thể được sử dụng để đánh cắp danh tính của ai đó hoặc xâm phạm tài khoản của họ với các nhà cung cấp dịch vụ khác, bạn có thể quan tâm nhiều hơn đến việc hạn chế quyền truy cập vào tài nguyên đó.


4
Nếu tôi muốn chia sẻ công thức bí mật cho Coke với nhóm phát triển sản phẩm của mình, điều đó sẽ đòi hỏi một chút gì đó khác với nếu tôi muốn chia sẻ công thức cho món salad khoai tây tôi đã phục vụ hàng xóm trong bữa tiệc thịt nướng ở khu phố. Một lần nữa, bối cảnh. :-)
CVn

7
@ MichaelKjorling Tôi không chắc ai đó sẽ suy luận khác với bài viết của tôi như thế nào. Rõ ràng tôi đã nói rằng các tài nguyên khác nhau đòi hỏi mức độ xác thực khác nhau. Công thức cho than cốc sẽ có giá trị hơn nhiều so với công thức làm bánh quy của bà.
Charles Addis

9
@CharlesAddis Rõ ràng bạn chưa bao giờ nếm bánh quy của bà tôi!
Brian

1
Tôi nghĩ, mặc dù tôi có thể sai, rằng @ Michael nói rằng mô tả 5 điểm của bạn về các thuộc tính mà một URL bí mật nên có, đã quá mức cần thiết để chia sẻ một công thức bí mật với bạn bè. Làm cho mỗi một lần sử dụng (và do đó cần một URL riêng cho mỗi người bạn truy cập công thức) nói riêng có vẻ rất nhiều rắc rối vì lợi ích không đáng kể, đặc biệt là nếu cũng có thời gian hết hạn. Tôi đọc câu trả lời của bạn có nghĩa là "có thể chấp nhận sử dụng URL riêng tư, nhưng URL riêng tư nên có 5 thuộc tính này" và IMO hơi sai.
Steve Jessop

1
@BenjaminHodgson chính xác là lý do cho mục số 5 => nếu liên kết / URL kết thúc trong tay sai, không nên rò rỉ bất kỳ thông tin nào về người dùng đã yêu cầu.
Charles Addis

8

Khá nhiều tất cả các kế hoạch xác thực sôi sục để chứng minh rằng bạn biết một bí mật. Bạn tự xác thực một số dịch vụ bằng cách chứng minh rằng bạn biết mật khẩu bí mật hoặc URL bí mật hoặc, ...

Một số giao thức nâng cao hơn (ví dụ: OAUTH, Kerberos, ...) cho phép bạn chứng minh rằng bạn biết bí mật mà không thực sự truyền bí mật. Điều này rất quan trọng vì có nhiều cách để có được một bí mật "không thể tin được" bên cạnh việc đoán nó.

Tôi có thể ngồi trong cùng một quán cà phê Internet với chính mình, nghe lén kết nối WiFi của bạn khi bạn nhập URL "không thể tin được" của bạn. Vào thời điểm đó, nếu bạn không sử dụng SSL hoặc nếu tôi có thể khai thác lỗi mới nhất trong quá trình triển khai SSL, thì tôi cũng sẽ biết bí mật của bạn.


1
Công bằng mà nói, điều này cũng đúng với xác thực hoặc bất kỳ thông tin liên lạc nào .
Andy

"Nghe lén trên kết nối WiFi của bạn" hoạt động trên mọi thứ: URL, CSRF được bảo vệ <form>, dữ liệu được mã hóa cấp quân sự JavaScript (có thể cần phải đánh hơi chủ động). Thật đơn giản để khắc phục nó: sử dụng HTTPS.
Gustavo

@GustavoRodrigues Trước hết, nếu nghe lén thực sự "làm việc trên bất cứ thứ gì ", thì nó sẽ hoạt động trên HTTPS. Nếu không, "bất cứ điều gì" có nghĩa là gì? Hoặc, ma thuật nào bạn nghĩ là trong HTTPS đặt nó lên trên mọi thứ khác?
Solomon chậm

2
... nhưng có một phép thuật ngăn chặn những kẻ nghe trộm: Đó là mật mã khóa công khai. Đây là một ví dụ đơn giản: Một dịch vụ gửi cho tôi một thử thách chứa một số ngẫu nhiên và dấu thời gian. Tôi ký thử thách với khóa riêng của mình và trả lại. Nếu họ có thể xác thực phản hồi của tôi với khóa công khai đã đăng ký của tôi, thì điều đó chứng tỏ rằng tôi biết bí mật (bí mật là khóa riêng của tôi), nhưng tôi đã chứng minh điều đó mà không bao giờ tiết lộ cho kẻ nghe trộm tiềm năng. Nó sẽ không giúp kẻ nghe trộm phát lại phản hồi của tôi, vì dịch vụ sẽ không bao giờ gửi thử thách tương tự hai lần.
Solomon chậm

HTTPS (Nghĩa là HTTP qua SSL) sử dụng tiền điện tử khóa công khai, nhưng FYI, các triển khai SSL phổ biến nhất có lịch sử lỗi đã cho phép kẻ nghe trộm phá vỡ ngay cả khi mã hóa. Các lỗi mới (hay còn gọi là "khai thác") dường như được phát hiện hai hoặc ba lần mỗi năm và tất cả các nhà phát triển của tất cả các sản phẩm sử dụng SSL phải chạy xung quanh với lửa cho đến khi khai thác mới nhất. (Đừng hỏi tôi làm sao tôi biết!)
Solomon Slow

3

Rất nhiều câu trả lời hay đã có trong chủ đề này, nhưng để trực tiếp giải quyết câu hỏi:

Từ quan điểm của một kẻ bất lương muốn truy cập tài nguyên này, những cách tiếp cận này có tương đương không? Nếu không, điều gì làm cho chúng khác nhau?

Hãy để tôi thiết lập một định nghĩa. "Xác thực" là việc cung cấp thông tin xác thực để chứng minh cho yêu cầu nhận dạng. Kiểm soát truy cập thường dựa trên nhận dạng của người dùng.

URL bí mật của bạn không bị ràng buộc với một người dùng cụ thể. Như những người khác đã chỉ ra, nó có thể kết thúc trong tệp nhật ký của proxy hoặc yêu cầu tìm kiếm được lập chỉ mục bởi google hoặc nhiều cách khác mà nó có thể bị rò rỉ.

Mặt khác, mật khẩu được gắn với một tài khoản người dùng duy nhất. Bạn có khả năng đặt lại hoặc chỉ cho phép nó được sử dụng dưới dạng địa điểm nhà của người dùng hoặc địa chỉ IP đã biết hoặc bất kỳ số điều khiển nào khác.

Tên người dùng / mật khẩu cung cấp cho bạn quyền kiểm soát chi tiết hơn về quyền truy cập.

Kiểm soát truy cập cho phép một danh tính (chủ thể) truy cập vào một tài nguyên (đối tượng). Trong ví dụ URL của bạn, danh tính là "bất kỳ ai từng nhận được URL, thông qua bất kỳ phương tiện nào".

Đi với tên người dùng / mật khẩu nếu bạn có thể. Các URL bị rò rỉ theo tất cả các cách bất ngờ theo thời gian.


1

Một URL bí mật chỉ an toàn như một mật khẩu bí mật. Tuy nhiên, mật khẩu dễ giữ bí mật hơn URL, vì mọi người và chương trình của họ đều biết rằng mật khẩu phải được giữ bí mật.

Chẳng hạn, trình duyệt của bạn sẽ không hiển thị mật khẩu trên màn hình, chỉ lưu trữ mật khẩu với sự cho phép của bạn và cung cấp phương tiện để bảo vệ lưu trữ mật khẩu đó (chẳng hạn như lưu trữ được mã hóa được mở khóa bằng mật khẩu chính). Ngược lại, nó sẽ luôn hiển thị URL trên màn hình, có thể có thể rò rỉ chúng thông qua tiêu đề người giới thiệu và lưu trữ chúng tự động trong lịch sử duyệt web của bạn mà không cần bảo vệ thêm.

Tương tự, proxy HTTP thường không ghi nhật ký mật khẩu, trong khi URL thường được ghi lại.

Sử dụng URL để xác thực cũng có nghĩa là chia sẻ URL chia sẻ xác thực, điều này khiến việc thu hồi (hoặc bản ghi) truy cập cá nhân trở nên khó khăn.

Và tất nhiên, các URL bí mật thừa hưởng tất cả các điểm yếu của mật khẩu bí mật. Cụ thể, sử dụng mật khẩu để xác thực sẽ tiết lộ mật khẩu đó cho máy chủ và bất kỳ ai cũng có thể đọc thông tin liên lạc của bạn.


3
Câu trả lời này đưa ra rất nhiều giả định sai. Nếu bạn đăng nhập vào một trang web bằng HTTPS và nhập tên người dùng và mật khẩu của bạn, bước nhảy ở giữa và proxy sẽ không biết mật khẩu của bạn.
Pieter B

Bằng cách "chặn giao tiếp của bạn" tôi có nghĩa là khả năng xây dựng lại nội dung của nó. Điều này có thể hoặc không thể được ngăn chặn bởi HTTPS. Cụ thể, tin tưởng vào một chứng chỉ xấu duy nhất (ví dụ như một số proxy HTTPS của công ty sử dụng cùng một khóa riêng cho tất cả các cài đặt) cho phép kẻ tấn công điều khiển lưu lượng HTTPS ở giữa.
meriton

2
nhưng bằng cách mã hóa bí mật trong url, về cơ bản, bạn làm cho HTTPS hoàn toàn không sử dụng được. Mỗi bước nhảy giữa máy khách và máy chủ đều có bí mật. Không cần chứng chỉ bị xâm phạm.
Pieter B

4
Vô lý; trong HTTPS, URL chỉ được truyền trong luồng được mã hóa. Bạn phải nhầm lẫn nó với tên miền hoặc IP, tương ứng có thể nhìn thấy trong các trường tìm kiếm DNS và tiêu đề IP.
meriton

1

Một mục khác không được chú ý ở bất cứ đâu là điều tiết 'đoán'. Đối với hầu hết các hệ thống xác thực mật khẩu, bạn nhận được một số lần giới hạn trong việc đoán mật khẩu cho người dùng trước khi các lần xác thực tiếp theo bị khóa hoặc bị giới hạn.

Mặc dù bạn có thể làm điều gì đó tương tự với 'dự đoán' đối với lược đồ URL của mình, nhưng sẽ khó thực hiện hơn một chút. Nếu có một mẫu có thể nhận ra đối với việc tạo URL của bạn, thì có thể khó có thể ngăn ai đó thiết lập để thực hiện theo cách của họ thông qua không gian URL 'ngẫu nhiên' của bạn.


0

Có một khía cạnh khác mà tôi chưa thấy đề cập đến - rút ngắn URL.

Trong một ấn phẩm gần đây (tháng 4 năm 2016), người ta đã tuyên bố rằng các dịch vụ rút ngắn URL hoàn toàn vô hiệu hóa bảo mật gia tăng được cung cấp bởi các URL "vô duyên" được tạo ngẫu nhiên. Không gian URL của dịch vụ rút gọn nhỏ hơn đáng kể so với URL được tạo ngẫu nhiên của bạn - có nghĩa là mọi URL "an toàn" như vậy được chia sẻ với dịch vụ rút gọn có thể được đoán theo cách dễ dàng hơn dự đoán.

Để minh họa - giả sử URL ngẫu nhiên của bạn dài 128 bit (tức là hướng dẫn). Ngoài ra, hãy giả sử rằng trình tạo số ngẫu nhiên của bạn thực sự mạnh và bạn tạo ra các bit đó một cách thống nhất. Đoán một số 128 bit là rất khó và có thể mất một thời gian đáng kể - URL của bạn được bảo vệ khóa 128 bit một cách hiệu quả.

Sau đó, giả sử ai đó đã chia sẻ URL này trên trình rút ngắn URL của google. Ngày nay, dịch vụ đó phát ra một ID dài 10 ký tự, bao gồm các chữ cái và số. (26 + 10) ^ 10 ~ = 3.6 * 10 ^ 15 <2 ^ 52 - vì vậy chúng tôi đã giảm một nửa hiệu quả sức mạnh khóa từ 128 bit xuống 52 bit.

Thêm vào đó, các máy phát điện không sử dụng toàn bộ không gian do sự cân nhắc khác và bạn có thể thực hiện một cuộc tấn công hiệu quả kết hợp lực lượng vũ phu với các kênh bên (rất có thể là bộ đệm URL ngẫu nhiên được phân bổ trước).

Bài viết gốc: http://arxiv.org/pdf/1604.02734v1.pdf
Một bài đăng blog tóm tắt bài viết (của tác giả): https://freedom-to-tinker.com/blog/vitaly/gone-in- sáu ký tự-ngắn-url-được coi là có hại cho dịch vụ đám mây /


2
Vâng, vâng, nhưng người ta sẽ hy vọng bất cứ ai sử dụng các dịch vụ như vậy cho dữ liệu nhạy cảm sẽ biết rõ hơn là đăng URL ở bất cứ đâu , kể cả dịch vụ rút ngắn. Điều này thực sự không khác gì khi nói Gah! My password/private key is too long and complex. I know! I'll just write it in a text document and put that in a zip file with an easier password.Cả hai đều thất bại trong suốt, điều mà người ta hy vọng chống lại hy vọng mọi người sẽ không đủ ngớ ngẩn để làm. Nhưng vâng, trong thực tế, đáng buồn là cảnh báo của bạn có lẽ là cần thiết;)
underscore_d

@underscore_d yeah chính xác - nếu bạn biết chủ đề này đủ chi tiết để bình luận thì đây không phải là một điểm đáng để viết blog.
Robert Grant
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.