Mức độ bảo mật nào được cung cấp?
.htpasswd không tự cung cấp nhiều bảo mật. Tức là, nó cung cấp một cơ chế đăng nhập, và Apache sẽ không trả lời mà không có thông tin đăng nhập thích hợp, nhưng trừ khi được cấu hình riêng, không có gì về trao đổi được mã hóa (hoặc thậm chí bị làm xáo trộn). Ví dụ, nghe yêu cầu GET với Wireshark mang đến cho bạn một cái nhìn tốt đẹp của tất cả các tiêu đề được gửi bởi các khách hàng, bao gồm:
Authorization: Basic d3BhbG1lcjp0ZXN0dGVzdA==
"d3BhbG1lcjp0ZXN0dGVzdA==" là chỉ là base64 hình thức "wpalmer:testtest" mã hóa. Những ngày này, tin tặc (hoặc nhiều khả năng là vi-rút) có thể ngồi trên kết nối WiFi công cộng và ghi lại bất kỳ yêu cầu nào có chứa Authorization: để xem xét sau này. Nói chung, việc gửi bất kỳ thông tin xác thực nào qua kết nối HTTP không được mã hóa được coi là một ý tưởng tồi, ngay cả khi bạn kết nối qua dây hoặc Wi-Fi an toàn. Nó sẽ không, ví dụ, đáp ứng các yêu cầu của PCI Compliance nếu bạn đang lưu trữ dữ liệu khách hàng, thông tin thanh toán, vv sau khóa .htpasswd.
Thêm https vào hỗn hợp, và bạn hoàn toàn loại bỏ vấn đề cụ thể, tuy nhiên ...
.htpasswd xác thực như thực hiện bởi Apache httpd không cung cấp bất kỳ hình thức bảo vệ hạn chế tỷ lệ hoặc brute-force. Bạn có thể thực hiện nhiều lần thử đồng thời với một mật khẩu đoán vì Apache sẵn sàng phục vụ các trang đồng thời và Apache sẽ trả lời thành công/thất bại ngay khi có thể. Bạn có thể sử dụng một số thứ như Fail2Ban để giới hạn số lần thử không thành công trước khi máy khách bị chặn nói chuyện với máy chủ, nhưng điều đó sẽ không nhất thiết cung cấp bất kỳ sự bảo vệ hữu ích nào đối với botnet. địa chỉ. Điều này có thể dẫn đến quyết định của "tôi có để bản thân mình dễ bị tấn công từ các botnet hay không, hoặc tôi có dễ bị tấn công từ chối dịch vụ hay không, khi toàn bộ tài khoản bị khóa do lỗi từ nhiều khách hàng?"
Các góc tấn công này có thể bị giới hạn bằng cách thêm các hạn chế dựa trên IP vào tệp .htaccess của bạn, chỉ cho phép kết nối từ một số địa chỉ nhất định. Tùy thuộc vào cách bạn hoạt động, điều này có thể bất tiện, nhưng nó cũng hạn chế nghiêm trọng các loại mối đe dọa mà bạn sẽ dễ bị tổn thương. Bạn sẽ vẫn có nguy cơ từ một người nào đó nhắm mục tiêu cụ thể đến trang web của bạn hoặc một phần lây nhiễm trên một phần cơ sở hạ tầng mạng. Tùy thuộc vào loại nội dung bạn đang bảo vệ, điều này có thể là "đủ tốt".Ví dụ về loại giới hạn này là:
Order deny,allow
Deny from all
Allow from 127.0.0.1
Điều này có nghĩa là "chỉ cho phép kết nối từ máy chủ cục bộ". Theo từng dòng, điều này có nghĩa là:
Order deny,allow xác định thứ tự xử lý quy tắc, với kết quả cuối cùng được ưu tiên.Deny from all bắt đầu bằng cách giả định rằng tất cả các khách hàng bị từ chốiAllow from 127.0.0.1 nếu khách hàng có IP 127.0.0.1, sau đó nó được phép
Đối với một số mức độ, hạn chế dựa trên IP cũng sẽ bảo vệ bạn tới điểm mà HTTPS có thể được coi là tùy chọn. Những kẻ tấn công/virus vẫn có thể nhìn thấy thông tin đăng nhập của bạn, nhưng khó có thể sử dụng các thông tin đăng nhập đó trên chính trang đó. Một lần nữa, điều này sẽ không được tuân thủ PCI, và nó sẽ không phù hợp cho thông tin "quan trọng", nhưng có một số tình huống mà điều này có thể được coi là "đủ tốt". Lưu ý rằng nhiều người sử dụng lại thông tin đăng nhập trên nhiều trang web, vì vậy việc không bảo vệ chi tiết đăng nhập thường được coi là rất nguy hiểm cho người dùng, ngay cả khi trang web được bảo vệ.
Cuối cùng, chính tệp .htaccess là một phần trách nhiệm pháp lý. Xem câu trả lời cho "họ có cần ở ngoài thư mục công cộng không?" để biết thêm chi tiết về điều đó.
Có thể bỏ qua dễ dàng không?
Không. Không có lý do gì để mong đợi máy chủ, khi được cấu hình đúng, sẽ không bao giờ yêu cầu chi tiết đăng nhập để truy cập nội dung được bảo vệ. Trong khi xác thực HTTP cơ bản có những sai sót của nó, Apache httpd rất mạnh mẽ và là một trong những phần mềm được thử nghiệm kỹ lưỡng nhất trên thế giới. Nếu bạn nói với Apache rằng xác thực HTTP cơ bản là bắt buộc để truy cập một số nội dung nhất định, nó sẽ được yêu cầu.
Nếu Apache theo mặc định không cho phép người dùng truy cập một trong hai tệp trực tiếp, họ có cần nằm ngoài thư mục công cộng không?
Có một vài điểm cho điều này. Thứ nhất, Apache thực hiện không mặc định để ngăn truy cập vào một trong các tệp này. Nhiều bản phân phối Apache httpd bao gồm cấu hình ban đầu để ngăn truy cập (sử dụng "Từ chối từ tất cả" quy tắc), tùy thuộc vào phân phối, .htaccess/.htpasswd tệp, .ht* tệp hoặc .* tệp. Nó là rất phổ biến, nhưng có rất nhiều lý do tại sao điều này có thể không phải là trường hợp. Bạn có thể thêm một quy tắc cho mình để ngăn chặn những tập tin này, nếu chúng chưa được chặn:
<FilesMatch "^.(htaccess|htpasswd)$">
Order Allow,Deny
Deny from all
</FilesMatch>
Thứ hai, cần phải chỉ ra rằng cách .htaccess file làm việc, chúng được xử lý khi thư mục họ đang ở là lần xuất hiện . Điều đó có nghĩa là: .htpasswd có thể ở nơi khác, nhưng .htaccess cần phải nằm trong cùng một thư mục. Điều đó nói rằng, hãy xem phần "tốc độ tác động" để biết thêm chi tiết hơn một chút.
Vì vậy, vì chúng có thể bị chặn dễ dàng như vậy, tại sao giữ .htpasswd bên ngoài thư mục công cộng? Bởi vì những sai lầm xảy ra và tệp .htpasswd là trách nhiệm lớn. Ngay cả khi bạn đang sử dụng HTTPS, việc hiển thị tệp .htpasswd có nghĩa là mật khẩu của bạn có thể dễ dàng bị bẻ khóa thông qua các cuộc tấn công bạo lực.Những ngày này, GPU cấp người tiêu dùng có thể tạo ra hàng triệu lần đoán mật khẩu mỗi giây. Điều này có thể làm cho mật khẩu thậm chí "mạnh" rơi trong thời gian tương đối ít. Một lần nữa, đối số này thường chỉ áp dụng cho một cuộc tấn công được nhắm mục tiêu, nhưng thực tế vẫn là nếu kẻ tấn công có tệp .htpasswd của bạn và muốn truy cập vào hệ thống của bạn, những ngày này, họ có thể làm như vậy một cách dễ dàng. Xem Speed Hashing về Mã hóa Kinh dị cho một tổng quan tương đối gần đây (tháng 4 năm 2012) về trạng thái của sự vật.
Với ý nghĩ đó, khả năng vô tình (tạm thời) hiển thị tệp .htaccess của bạn đáng để di chuyển đến đâu đó mà không bao giờ được xem xét khi httpd đang tìm kiếm nội dung để phân phối. Có, vẫn có những thay đổi cấu hình có thể phơi bày nó nếu đó là "một cấp" thay vì "trong thư mục công cộng", nhưng những thay đổi đó ít có khả năng xảy ra vô tình hơn.
Có bất kỳ tác động tốc độ nào không?
Một số.
Trước hết, việc sử dụng các tệp .htaccess làm chậm phần nào. Cụ thể hơn, chỉ thị AllowOverride all gây ra rất nhiều tiềm năng làm chậm. Điều này khiến Apache tìm kiếm các tập tin .htaccess trong mỗi thư mục, và mọi phụ huynh của một thư mục, được truy cập (lên đến và bao gồm cả DocumentRoot). Điều này có nghĩa là truy vấn hệ thống tệp cho một tệp (hoặc cập nhật tệp), cho mọi yêu cầu. So với việc thay thế khả năng không bao giờ đánh vào hệ thống tệp, điều này hoàn toàn khác biệt.
Vì vậy, tại sao .htaccess tồn tại? Có nhiều lý do có thể khiến nó "đáng giá":
- tùy thuộc vào tải trên máy chủ của bạn, bạn có thể không bao giờ nhận thấy sự khác biệt. Máy chủ của bạn có thực sự cần phải ép mỗi mili giây cuối cùng trong mỗi yêu cầu không? Nếu không, thì đừng lo lắng về nó. Như mọi khi, đừng lo lắng về ước tính và dự đoán. Hồ sơ các tình huống trong thế giới thực của bạn và xem liệu nó có tạo nên sự khác biệt hay không.
.htaccess có thể được sửa đổi mà không cần khởi động lại máy chủ. Trong thực tế, đây là những gì làm cho nó quá chậm Apache kiểm tra các thay đổi hoặc sự hiện diện của một tập tin .htaccess trên mọi yêu cầu, do đó, các thay đổi được áp dụng ngay lập tức.- Lỗi trong
.htaccess sẽ gỡ thư mục chứ không phải máy chủ. Điều này làm cho nó ít hơn nhiều so với việc thay đổi tệp httpd.conf.
.htaccess có thể được sửa đổi ngay cả khi bạn chỉ có quyền ghi vào một thư mục duy nhất. Điều này làm cho nó lý tưởng cho các môi trường lưu trữ được chia sẻ. Không cần truy cập vào httpd.conf hoặc truy cập để khởi động lại máy chủ..htaccess có thể giữ nguyên quy tắc truy cập bên cạnh các tệp mà chúng có ý định thực hiện. Điều này có thể làm cho chúng dễ tìm hơn và chỉ giữ mọi thứ được tổ chức tốt hơn.
Không muốn sử dụng .htaccess, thậm chí xem xét tất cả những điều trên? Bất kỳ quy tắc nào áp dụng cho .htaccess đều có thể được thêm trực tiếp vào httpd.conf hoặc tệp được bao gồm.
Điều gì về .htpasswd? Điều đó tùy thuộc vào số lượng người dùng bạn có. Đó là dựa trên tệp và tối thiểu về mặt triển khai.Từ The docs for httpd 2.2:
Do cách mà xác thực cơ bản được quy định, tên người dùng và mật khẩu của bạn phải được xác nhận mỗi khi bạn yêu cầu một tài liệu từ máy chủ. Điều này thậm chí nếu bạn đang tải lại cùng một trang và cho mọi hình ảnh trên trang (nếu chúng đến từ thư mục được bảo vệ ). Như bạn có thể tưởng tượng, điều này làm chậm một chút. Số tiền làm chậm mọi thứ xuống theo tỷ lệ thuận với kích thước của tệp mật khẩu , vì nó phải mở tệp đó và đi xuống danh sách người dùng cho đến khi nó được đặt cho tên của bạn. Và nó phải làm điều này mỗi thời gian một trang được tải.
Hậu quả của việc này là có giới hạn thực tế đối với số người dùng bạn có thể đặt vào một tệp mật khẩu. Giới hạn này sẽ thay đổi tùy theo về hiệu suất của máy chủ cụ thể của bạn, nhưng bạn có thể mong đợi thấy sự chậm lại khi bạn nhận được trên vài trăm mục và có thể xem xét phương thức xác thực khác tại thời điểm đó.
Tóm lại, .htpasswd là chậm. Nếu bạn chỉ có một số ít người dùng cần xác thực, bạn sẽ không bao giờ nhận thấy, nhưng đó vẫn là một xem xét khác.
Tóm tắt
Securing một phần admin với .htpasswd không phải là lý tưởng cho tất cả các tình huống. Với sự đơn giản của nó, nó có thể là giá trị rủi ro và các vấn đề mà an ninh và hiệu suất không phải là ưu tiên cao nhất. Đối với nhiều tình huống, với một chút tinh chỉnh, nó có thể được coi là "đủ tốt". Những gì cấu thành "đủ tốt" là một cuộc gọi phán quyết để bạn thực hiện.