Xác thực dựa trên mẫu cho các trang web

Chúng tôi tin rằng Stack Overflow không chỉ là một tài nguyên cho các câu hỏi kỹ thuật rất cụ thể mà còn cho các hướng dẫn chung về cách giải quyết các biến thể trong các vấn đề phổ biến. "Xác thực dựa trên mẫu cho các trang web" phải là một chủ đề tốt cho một thử nghiệm như vậy.

Nó nên bao gồm các chủ đề như:

• Cách đăng nhập
• Cách đăng xuất
• Làm thế nào để duy trì trạng thái đăng nhập
• Quản lý cookie (bao gồm các cài đặt được đề xuất)
• Mã hóa SSL / HTTPS
• Cách lưu trữ mật khẩu
• Sử dụng câu hỏi bí mật
• Quên tên người dùng / chức năng mật khẩu
• Sử dụng nonces để ngăn chặn giả mạo yêu cầu cross-site (CSRF)
• OpenID
• Hộp kiểm "Nhớ tôi"
• Trình duyệt tự động hoàn thành tên người dùng và mật khẩu
• URL bí mật ( URL công khai được bảo vệ bởi thông báo)
• Kiểm tra cường độ mật khẩu
• Xác thực thư điện tử
• và nhiều hơn nữa về xác thực dựa trên hình thức ...

Nó không nên bao gồm những thứ như:

• Vai trò và ủy quyền
• Xác thực cơ bản HTTP

Hãy giúp chúng tôi bằng cách:

1. Đề xuất chủ đề nhỏ
2. Gửi bài viết hay về chủ đề này
3. Chỉnh sửa câu trả lời chính thức

PHẦN I: Cách đăng nhập

Chúng tôi sẽ cho rằng bạn đã biết cách tạo một biểu mẫu HTML đăng nhập + mật khẩu để gửi các giá trị thành tập lệnh ở phía máy chủ để xác thực. Các phần dưới đây sẽ xử lý các mẫu cho auth thực tế âm thanh và cách tránh các cạm bẫy bảo mật phổ biến nhất.

Đến HTTPS hay không HTTPS?

Trừ khi kết nối đã được bảo mật (nghĩa là được truyền qua HTTPS bằng SSL / TLS), các giá trị biểu mẫu đăng nhập của bạn sẽ được gửi trong Cleartext, cho phép bất kỳ ai nghe lén trên dòng giữa trình duyệt và máy chủ web sẽ có thể đọc thông tin đăng nhập khi chúng đi qua xuyên qua. Kiểu nghe lén này được các chính phủ thực hiện thường xuyên, nhưng nói chung, chúng tôi sẽ không giải quyết các dây 'thuộc sở hữu' ngoài việc nói điều này: Chỉ cần sử dụng HTTPS.

Về bản chất, cách thực tế duy nhất để bảo vệ chống lại việc nghe lén / phát hiện gói tin trong khi đăng nhập là sử dụng HTTPS hoặc một chương trình mã hóa dựa trên chứng chỉ khác (ví dụ: TLS ) hoặc sơ đồ phản hồi thử thách đã được kiểm chứng & thử nghiệm (ví dụ: Diffie-Hellman dựa trên SRP). Bất kỳ phương pháp nào khác có thể dễ dàng bị phá vỡ bởi một kẻ tấn công nghe lén.

Tất nhiên, nếu bạn sẵn sàng nhận được một chút không thực tế, bạn cũng có thể sử dụng một số dạng sơ đồ xác thực hai yếu tố (ví dụ: ứng dụng Google Authenticator, một cuốn sách mã 'kiểu chiến tranh lạnh' hoặc khóa máy tạo khóa RSA). Nếu được áp dụng chính xác, điều này có thể hoạt động ngay cả với kết nối không bảo mật, nhưng thật khó để tưởng tượng rằng một nhà phát triển sẽ sẵn sàng thực hiện xác thực hai yếu tố nhưng không phải SSL.

(Không) Cuộn mã hóa / băm JavaScript của riêng bạn

Do chi phí (mặc dù có thể tránh được ) và khó khăn về kỹ thuật khi thiết lập chứng chỉ SSL trên trang web của bạn, một số nhà phát triển đã cố gắng thực hiện các phương pháp băm hoặc mã hóa trong trình duyệt của riêng họ để tránh truyền thông tin đăng nhập rõ ràng qua một dây không bảo mật.

Mặc dù đây là một suy nghĩ cao quý, nhưng về cơ bản nó là vô dụng (và có thể là một lỗ hổng bảo mật ) trừ khi nó được kết hợp với một trong những điều trên - nghĩa là bảo vệ dòng bằng mã hóa mạnh hoặc sử dụng phản hồi thử thách đã được thử nghiệm cơ chế (nếu bạn không biết đó là gì, chỉ cần biết rằng đó là một trong những điều khó chứng minh nhất, khó thiết kế nhất và khó thực hiện nhất trong các khái niệm trong bảo mật kỹ thuật số).

Mặc dù việc băm mật khẩu có thể có hiệu quả đối với việc tiết lộ mật khẩu , nhưng nó rất dễ bị tấn công lại, các cuộc tấn công / tấn công Man-In-The-Middle (nếu kẻ tấn công có thể tiêm một vài byte vào trang HTML không bảo mật của bạn trước khi nó đến tay bạn Trình duyệt, họ có thể chỉ cần bình luận về việc băm trong JavaScript) hoặc các cuộc tấn công vũ phu (vì bạn đang trao cho kẻ tấn công cả tên người dùng, mật khẩu và mật khẩu băm).

CAPTCHAS chống lại loài người

CAPTCHA có nghĩa là để ngăn chặn một loại tấn công cụ thể: từ điển tự động / thử nghiệm và lỗi không có người vận hành. Không có nghi ngờ rằng đây là một mối đe dọa thực sự, tuy nhiên, có nhiều cách để xử lý nó một cách liền mạch mà không yêu cầu CAPTCHA, các kế hoạch điều chỉnh đăng nhập phía máy chủ được thiết kế đặc biệt - chúng ta sẽ thảo luận về những vấn đề này sau.

Biết rằng việc triển khai CAPTCHA không được tạo giống nhau; chúng thường không thể hòa tan được với con người, hầu hết chúng thực sự không hiệu quả với bot, tất cả chúng đều không hiệu quả đối với lao động thế giới thứ ba rẻ tiền (theo OWASP , tỷ lệ đổ mồ hôi hiện tại là 12 đô la trên 500 thử nghiệm), và một số triển khai có thể là về mặt kỹ thuật bất hợp pháp ở một số quốc gia (xem Bảng cheat xác thực OWASP ). Nếu bạn phải sử dụng CAPTCHA, hãy sử dụng reCAPTCHA của Google , vì định nghĩa đó là OCR-hard (vì nó sử dụng quét sách đã phân loại sai OCR) và rất cố gắng thân thiện với người dùng.

Cá nhân, tôi có xu hướng thấy CAPTCHAS gây phiền nhiễu và chỉ sử dụng chúng như là phương sách cuối cùng khi người dùng không đăng nhập được một số lần và độ trễ điều chỉnh được tối đa hóa. Điều này sẽ hiếm khi đủ để được chấp nhận và nó củng cố toàn bộ hệ thống.

Lưu mật khẩu / Xác minh thông tin đăng nhập

Đây cuối cùng có thể là kiến ​​thức phổ biến sau khi tất cả các vụ hack và rò rỉ dữ liệu người dùng được công bố rộng rãi mà chúng ta đã thấy trong những năm gần đây, nhưng phải nói rằng: Không lưu trữ mật khẩu trong văn bản rõ ràng trong cơ sở dữ liệu của bạn. Cơ sở dữ liệu người dùng thường xuyên bị hack, rò rỉ hoặc lượm lặt thông qua SQL SQL và nếu bạn đang lưu trữ mật khẩu thô, thô, đó là trò chơi tức thì để bảo mật đăng nhập của bạn.

Vì vậy, nếu bạn không thể lưu trữ mật khẩu, làm thế nào để bạn kiểm tra xem kết hợp đăng nhập + mật khẩu được gửi từ biểu mẫu đăng nhập có đúng không? Câu trả lời là băm bằng cách sử dụng hàm phái sinh chính . Bất cứ khi nào người dùng mới được tạo hoặc thay đổi mật khẩu, bạn lấy mật khẩu và chạy nó thông qua một KDF, chẳng hạn như Argon2, bcrypt, scrypt hoặc PBKDF2, biến mật khẩu Cleartext ("chính xác là" tìm kiếm ngẫu nhiên ") , an toàn hơn rất nhiều để lưu trữ trong cơ sở dữ liệu của bạn. Để xác minh đăng nhập, bạn chạy cùng hàm băm trên mật khẩu đã nhập, lần này chuyển qua muối và so sánh chuỗi băm kết quả với giá trị được lưu trữ trong cơ sở dữ liệu của bạn. Argon2, bcrypt và scrypt lưu trữ muối với hàm băm đã có. Kiểm tra bài viết này trên sec.stackexchange để biết thêm thông tin chi tiết.

Lý do một loại muối được sử dụng là bản thân việc băm là không đủ - bạn sẽ muốn thêm cái gọi là 'muối' để bảo vệ hàm băm chống lại các bảng cầu vồng . Một muối có hiệu quả ngăn chặn hai mật khẩu khớp chính xác với việc được lưu trữ dưới cùng một giá trị băm, ngăn toàn bộ cơ sở dữ liệu được quét trong một lần chạy nếu kẻ tấn công đang thực hiện một cuộc tấn công đoán mật khẩu.

Không nên sử dụng hàm băm mật mã để lưu trữ mật khẩu vì mật khẩu do người dùng chọn không đủ mạnh (nghĩa là thường không chứa đủ entropy) và một cuộc tấn công đoán mật khẩu có thể được hoàn thành trong một thời gian tương đối ngắn bởi kẻ tấn công có quyền truy cập vào bảng băm. Đây là lý do tại sao các KDF được sử dụng - những cách này "kéo dài khóa" một cách hiệu quả , điều đó có nghĩa là mọi mật khẩu đoán kẻ tấn công gây ra nhiều lần lặp lại thuật toán băm, ví dụ 10.000 lần, khiến kẻ tấn công đoán mật khẩu chậm hơn 10.000 lần.

Dữ liệu phiên - "Bạn đã đăng nhập với tư cách Người nhện69"

Khi máy chủ đã xác minh thông tin đăng nhập và mật khẩu đối với cơ sở dữ liệu người dùng của bạn và tìm thấy sự trùng khớp, hệ thống cần một cách để nhớ rằng trình duyệt đã được xác thực. Thực tế này chỉ nên được lưu trữ phía máy chủ trong dữ liệu phiên.

Nếu bạn không quen với dữ liệu phiên, thì đây là cách nó hoạt động: Một chuỗi được tạo ngẫu nhiên duy nhất được lưu trữ trong một cookie hết hạn và được sử dụng để tham chiếu bộ sưu tập dữ liệu - dữ liệu phiên - được lưu trữ trên máy chủ. Nếu bạn đang sử dụng một khung công tác MVC, điều này chắc chắn đã được xử lý.

Nếu có thể, hãy đảm bảo cookie phiên có cờ an toàn và chỉ HTTP được đặt khi được gửi tới trình duyệt. Cờ httpOnly cung cấp một số bảo vệ chống lại cookie được đọc thông qua cuộc tấn công XSS. Cờ bảo mật đảm bảo rằng cookie chỉ được gửi lại qua HTTPS và do đó bảo vệ chống lại các cuộc tấn công đánh hơi mạng. Giá trị của cookie không nên dự đoán được. Khi một cookie tham chiếu phiên không tồn tại được trình bày, giá trị của nó phải được thay thế ngay lập tức để ngăn việc sửa phiên .

PHẦN II: Cách duy trì đăng nhập - Hộp kiểm "Nhớ tôi" khét tiếng

Cookies đăng nhập liên tục (chức năng "nhớ tôi") là một khu vực nguy hiểm; một mặt, chúng hoàn toàn an toàn như thông tin đăng nhập thông thường khi người dùng hiểu cách xử lý chúng; và mặt khác, chúng là một rủi ro bảo mật rất lớn trong tay của những người dùng bất cẩn, những người có thể sử dụng chúng trên máy tính công cộng và quên đăng xuất và ai có thể không biết cookie trình duyệt là gì hoặc cách xóa chúng.

Cá nhân, tôi thích đăng nhập liên tục cho các trang web tôi truy cập thường xuyên, nhưng tôi biết cách xử lý chúng một cách an toàn. Nếu bạn khẳng định rằng người dùng của bạn biết điều tương tự, bạn có thể sử dụng thông tin đăng nhập liên tục với một lương tâm trong sạch. Nếu không - tốt, thì bạn có thể đăng ký triết lý rằng người dùng bất cẩn với thông tin đăng nhập của họ đã tự mang nó nếu họ bị hack. Không giống như chúng ta đến nhà của người dùng và xé tất cả những ghi chú Post-It gây ra bằng mặt với mật khẩu mà họ đã xếp hàng trên cạnh màn hình của họ.

Tất nhiên, một số hệ thống không đủ khả năng để có bất kỳ tài khoản nào bị hack; Đối với các hệ thống như vậy, không có cách nào bạn có thể biện minh cho việc đăng nhập liên tục.

Nếu bạn quyết định triển khai cookie đăng nhập liên tục, đây là cách bạn thực hiện:

1. Trước tiên, hãy dành chút thời gian để đọc bài viết của Paragon Initiative về chủ đề này. Bạn sẽ cần phải có một loạt các yếu tố đúng, và bài viết làm rất tốt công việc giải thích từng yếu tố.

2. Và chỉ để nhắc lại một trong những cạm bẫy phổ biến nhất, ĐỪNG LƯU TRỮ COOKIE ĐĂNG KÝ NGHIÊM TÚC (TOKEN) TRONG CƠ SỞ DỮ LIỆU CỦA BẠN, CHỈ CÓ MỘT VẤN ĐỀ CỦA NÓ! Mã thông báo đăng nhập là Mật khẩu tương đương, vì vậy nếu kẻ tấn công có được cơ sở dữ liệu của bạn, họ có thể sử dụng mã thông báo để đăng nhập vào bất kỳ tài khoản nào, giống như chúng là các kết hợp mật khẩu đăng nhập rõ ràng. Do đó, sử dụng băm (theo https://security.stackexchange.com/a/63438/5002 một hàm băm yếu sẽ làm tốt cho mục đích này) khi lưu trữ mã thông báo đăng nhập liên tục.

PHẦN III: Sử dụng câu hỏi bí mật

Đừng thực hiện 'những câu hỏi bí mật' . Tính năng 'câu hỏi bí mật' là mô hình chống bảo mật. Đọc bài viết từ liên kết số 4 từ danh sách PHẢI-ĐỌC. Bạn có thể hỏi Sarah Palin về điều đó, sau Yahoo! tài khoản email đã bị hack trong một chiến dịch tranh cử tổng thống trước đó vì câu trả lời cho câu hỏi bảo mật của cô là ... "Trường trung học Wasilla"!

Ngay cả với các câu hỏi do người dùng chỉ định, rất có khả năng hầu hết người dùng sẽ chọn:

• Một câu hỏi bí mật 'tiêu chuẩn' như tên thời con gái của mẹ hoặc thú cưng yêu thích

• Một mẩu chuyện nhỏ đơn giản mà bất cứ ai cũng có thể nâng lên từ blog, hồ sơ LinkedIn hoặc tương tự của họ

• Bất kỳ câu hỏi nào dễ trả lời hơn là đoán mật khẩu của họ. Mà, đối với bất kỳ mật khẩu phong nha, là mọi câu hỏi bạn có thể tưởng tượng

Tóm lại, các câu hỏi bảo mật vốn không an toàn trong hầu hết tất cả các dạng và biến thể của chúng, và không nên được sử dụng trong sơ đồ xác thực vì bất kỳ lý do nào.

Lý do thực sự tại sao các câu hỏi bảo mật thậm chí tồn tại ngoài tự nhiên là vì chúng thuận tiện tiết kiệm chi phí cho một vài cuộc gọi hỗ trợ từ những người dùng không thể truy cập email của họ để nhận mã kích hoạt lại. Điều này với chi phí bảo mật và danh tiếng của Sarah Palin. Có đáng không? Chắc là không.

PHẦN IV: Chức năng mật khẩu bị quên

Tôi đã đề cập tại sao bạn không bao giờ nên sử dụng các câu hỏi bảo mật để xử lý mật khẩu người dùng bị quên / mất; cũng không cần phải nói rằng bạn không bao giờ nên gửi email cho người dùng mật khẩu thực tế của họ. Có ít nhất hai cạm bẫy quá phổ biến cần tránh trong lĩnh vực này:

1. Không đặt lại mật khẩu đã quên thành mật khẩu mạnh được tạo tự động - những mật khẩu đó rất khó nhớ, điều đó có nghĩa là người dùng phải thay đổi hoặc ghi lại - giả sử, trên Post-It màu vàng sáng trên cạnh màn hình của họ. Thay vì đặt mật khẩu mới, chỉ cần cho phép người dùng chọn một mật khẩu mới ngay lập tức - đó là những gì họ muốn làm bằng mọi cách. (Một ngoại lệ cho điều này có thể là nếu người dùng đang sử dụng phổ biến trình quản lý mật khẩu để lưu trữ / quản lý mật khẩu mà thông thường không thể nhớ được nếu không ghi lại).

2. Luôn băm mã mật khẩu / mã thông báo bị mất trong cơ sở dữ liệu. LẠI , mã này là một ví dụ khác về Mật khẩu tương đương, vì vậy nó PHẢI được băm trong trường hợp kẻ tấn công có được cơ sở dữ liệu của bạn. Khi mã mật khẩu bị mất được yêu cầu, hãy gửi mã bản rõ đến địa chỉ email của người dùng, sau đó băm nó, lưu mã băm trong cơ sở dữ liệu của bạn - và vứt bỏ bản gốc . Giống như mật khẩu hoặc mã thông báo đăng nhập liên tục.

Lưu ý cuối cùng: luôn đảm bảo giao diện của bạn để nhập 'mã mật khẩu bị mất' ít nhất là an toàn như chính hình thức đăng nhập của bạn, hoặc kẻ tấn công sẽ chỉ sử dụng điều này để có quyền truy cập thay thế. Đảm bảo rằng bạn tạo rất lâu 'mã mật khẩu bị mất' (ví dụ: 16 ký tự chữ và số phân biệt chữ hoa chữ thường) là một khởi đầu tốt, nhưng hãy xem xét thêm sơ đồ điều chỉnh giống như bạn làm cho chính biểu mẫu đăng nhập.

PHẦN V: Kiểm tra cường độ mật khẩu

Trước tiên, bạn sẽ muốn đọc bài viết nhỏ này để kiểm tra thực tế: 500 mật khẩu phổ biến nhất

Được rồi, vì vậy, có thể danh sách này không phải là danh sách chính thức của các mật khẩu phổ biến nhất trên bất kỳ hệ thống nào ở mọi nơi , nhưng đó là một dấu hiệu tốt về việc mọi người sẽ chọn mật khẩu kém như thế nào khi không có chính sách bắt buộc. Thêm vào đó, danh sách trông đáng sợ gần nhà khi bạn so sánh nó với các phân tích có sẵn công khai về mật khẩu bị đánh cắp gần đây.

Vì vậy: Không có yêu cầu về độ mạnh mật khẩu tối thiểu, 2% người dùng sử dụng một trong 20 mật khẩu phổ biến nhất. Ý nghĩa: nếu kẻ tấn công chỉ nhận được 20 lần thử, 1 trong 50 tài khoản trên trang web của bạn sẽ bị bẻ khóa.

Việc ngăn chặn điều này đòi hỏi phải tính toán entropy của mật khẩu và sau đó áp dụng ngưỡng. Ấn bản đặc biệt của Viện Tiêu chuẩn và Công nghệ (NIST) 800-63 có một loạt các đề xuất rất tốt. Điều đó, khi kết hợp với phân tích bố cục từ điển và bàn phím (ví dụ: 'qwertyuiop' là mật khẩu xấu), có thể từ chối 99% tất cả mật khẩu được chọn kém ở mức 18 bit của entropy. Đơn giản chỉ cần tính toán cường độ mật khẩu và hiển thị máy đo cường độ thị giác cho người dùng là tốt, nhưng không đủ. Trừ khi nó được thi hành, rất nhiều người dùng rất có thể sẽ bỏ qua nó.

Và để làm mới về tính thân thiện của người dùng đối với mật khẩu có độ entropy cao, Mật khẩu Sức mạnh xkcd của Randall Munroe rất được khuyến khích.

Sử dụng API đã được kiểm tra của Troy Hunt để kiểm tra mật khẩu của người dùng đối với mật khẩu bị xâm phạm trong các vi phạm dữ liệu công khai.

PHẦN VI: Nhiều hơn nữa - Hoặc: Ngăn chặn các nỗ lực đăng nhập nhanh

Trước tiên, hãy xem các con số: Tốc độ khôi phục mật khẩu - Mật khẩu của bạn sẽ đứng trong bao lâu

Nếu bạn không có thời gian để xem qua các bảng trong liên kết đó, thì đây là danh sách của chúng:

1. Phải mất hầu như không có thời gian để crack một mật khẩu yếu, ngay cả khi bạn đang nứt nó với một bàn tính

2. Phải mất hầu như không có thời gian để crack mật khẩu 9 ký tự chữ và số nếu nó là trường hợp nhạy cảm

3. Phải mất hầu như không có thời gian để crack một phức tạp, biểu tượng và chữ cái-và-con số, mật khẩu trên-và-chữ thường nếu nó là dài ít hơn 8 ký tự (một máy tính để bàn có thể tìm kiếm toàn bộ keyspace lên đến 7 ký tự trong một vấn đề của ngày hoặc thậm chí giờ)

4. Tuy nhiên, sẽ mất một lượng thời gian không đáng có để bẻ khóa ngay cả mật khẩu 6 ký tự, nếu bạn bị giới hạn một lần thử mỗi giây!

Vậy chúng ta có thể học được gì từ những con số này? Chà, rất nhiều, nhưng chúng ta có thể tập trung vào phần quan trọng nhất: thực tế là ngăn chặn số lượng lớn các nỗ lực đăng nhập liên tiếp nhanh chóng (ví dụ như cuộc tấn công vũ phu ) thực sự không khó. Nhưng ngăn chặn nó đúng không dễ như bạn tưởng.

Nói chung, bạn có ba lựa chọn hoàn toàn hiệu quả trước các cuộc tấn công vũ phu (và tấn công từ điển, nhưng vì bạn đã sử dụng chính sách mật khẩu mạnh, nên chúng không phải là vấn đề) :

• Trình bày CAPTCHA sau khi N thất bại (khó chịu như địa ngục và thường không hiệu quả - nhưng tôi đang lặp lại ở đây)

• Khóa tài khoản và yêu cầu xác minh email sau khi N thất bại (đây là một cuộc tấn công DoS đang chờ xảy ra)

• Và cuối cùng, đăng nhập điều chỉnh : nghĩa là thiết lập độ trễ thời gian giữa các lần thử sau N lần thử thất bại (vâng, các cuộc tấn công DoS vẫn có thể xảy ra, nhưng ít nhất chúng có khả năng giảm đi rất nhiều và phức tạp hơn rất nhiều).

Thực tiễn tốt nhất # 1: Độ trễ thời gian ngắn tăng theo số lần thử thất bại, như:

• 1 lần thất bại = không chậm trễ
• 2 lần thất bại = chậm 2 giây
• 3 lần thất bại = chậm 4 giây
• 4 lần thất bại = chậm 8 giây
• 5 lần thất bại = chậm 16 giây
• Vân vân.

DoS tấn công sơ đồ này sẽ rất không thực tế, vì thời gian khóa kết quả lớn hơn một chút so với tổng số lần khóa trước đó.

Để làm rõ: Sự chậm trễ không phải là sự chậm trễ trước khi trả lại phản hồi cho trình duyệt. Nó giống như một khoảng thời gian chờ hoặc thời gian chịu lửa trong đó đăng nhập cố gắng vào một tài khoản cụ thể hoặc từ một địa chỉ IP cụ thể sẽ không được chấp nhận hoặc đánh giá. Đó là, thông tin đăng nhập chính xác sẽ không trở lại trong một lần đăng nhập thành công và thông tin đăng nhập không chính xác sẽ không kích hoạt sự gia tăng độ trễ.

Cách thực hành tốt nhất # 2: Độ trễ thời gian dài trung bình có hiệu lực sau N lần thử thất bại, như:

• 1-4 lần thất bại = không chậm trễ
• 5 lần thất bại = chậm 15-30 phút

DoS tấn công sơ đồ này sẽ không thực tế, nhưng chắc chắn có thể thực hiện được. Ngoài ra, có thể có liên quan để lưu ý rằng một sự chậm trễ lâu như vậy có thể rất khó chịu cho một người dùng hợp pháp. Người dùng hay quên sẽ không thích bạn.

Cách thực hành tốt nhất # 3: Kết hợp hai cách tiếp cận - có thể là độ trễ thời gian ngắn cố định có hiệu lực sau N lần thử thất bại, như:

• 1-4 lần thất bại = không chậm trễ
• Hơn 5 lần thử thất bại = độ trễ 20 giây

Hoặc, độ trễ tăng dần với giới hạn trên cố định, như:

• 1 lần thử thất bại = chậm 5 giây
• 2 lần thất bại = chậm 15 giây
• Hơn 3 lần thất bại = độ trễ 45 giây

Lược đồ cuối cùng này được lấy từ các đề xuất thực tiễn tốt nhất của OWASP (liên kết 1 từ danh sách MUST-READ) và nên được coi là thực tiễn tốt nhất, ngay cả khi nó được thừa nhận ở phía hạn chế.

Tuy nhiên, theo nguyên tắc thông thường, tôi sẽ nói: chính sách mật khẩu của bạn càng mạnh thì bạn càng ít phải sửa lỗi người dùng bị chậm trễ. Nếu bạn yêu cầu mạnh (chữ số và chữ số phân biệt chữ hoa chữ thường + số và ký hiệu bắt buộc) 9+ mật khẩu ký tự, bạn có thể cung cấp cho người dùng 2-4 lần thử mật khẩu không bị trì hoãn trước khi kích hoạt điều chỉnh.

DoS tấn công chương trình điều chỉnh đăng nhập cuối cùng này sẽ rất không thực tế. Và như là một liên lạc cuối cùng, luôn cho phép các thông tin đăng nhập (cookie) liên tục (và / hoặc một hình thức đăng nhập được xác minh CAPTCHA) đi qua, vì vậy người dùng hợp pháp thậm chí sẽ không bị trì hoãn trong khi cuộc tấn công đang diễn ra . Theo cách đó, cuộc tấn công DoS rất không thực tế trở thành một cuộc tấn công cực kỳ không thực tế.

Ngoài ra, thật hợp lý khi thực hiện điều tiết mạnh mẽ hơn trên tài khoản quản trị viên, vì đó là những điểm vào hấp dẫn nhất

PHẦN VII: Tấn công Brute Force phân tán

Chỉ là một bên, những kẻ tấn công tiên tiến hơn sẽ cố gắng phá vỡ thông tin đăng nhập bằng cách 'truyền bá hoạt động của chúng':

• Phân phối các nỗ lực trên botnet để ngăn chặn gắn cờ địa chỉ IP

• Thay vì chọn một người dùng và thử 50.000 mật khẩu phổ biến nhất (mà họ không thể, vì điều chỉnh của chúng tôi), họ sẽ chọn Mật khẩu phổ biến nhất và thay vào đó thử với 50.000 người dùng. Bằng cách đó, không chỉ họ có được các biện pháp thử tối đa như CAPTCHA và điều chỉnh đăng nhập, cơ hội thành công của họ cũng tăng lên, vì mật khẩu phổ biến số 1 nhiều hơn nhiều so với số 49.995

• Khoảng cách các yêu cầu đăng nhập cho mỗi tài khoản người dùng, giả sử, cách nhau 30 giây, để lẻn dưới radar

Ở đây, cách tốt nhất là ghi nhật ký số lần đăng nhập thất bại, toàn hệ thống và sử dụng tần suất đăng nhập xấu của trang web của bạn làm cơ sở cho giới hạn trên mà bạn áp đặt cho tất cả người dùng.

Quá trừu tượng? Hãy để tôi viết lại:

Giả sử trang web của bạn đã có trung bình 120 thông tin đăng nhập xấu mỗi ngày trong 3 tháng qua. Sử dụng mức đó (trung bình đang chạy), hệ thống của bạn có thể đặt giới hạn toàn cầu thành 3 lần - tức là. 360 lần thất bại trong khoảng thời gian 24 giờ. Sau đó, nếu tổng số lần thử thất bại trên tất cả các tài khoản vượt quá con số đó trong vòng một ngày (hoặc thậm chí tốt hơn, hãy theo dõi tốc độ tăng tốc và kích hoạt trên ngưỡng tính toán), nó sẽ kích hoạt điều chỉnh đăng nhập trên toàn hệ thống - nghĩa là độ trễ ngắn cho TẤT CẢ người dùng (tuy nhiên, ngoại trừ thông tin đăng nhập cookie và / hoặc thông tin đăng nhập CAPTCHA dự phòng).

Tôi cũng đã đăng một câu hỏi với nhiều chi tiết hơn và một cuộc thảo luận thực sự tốt về cách tránh những kẻ lừa đảo gian xảo trong việc chống lại các cuộc tấn công vũ phu phân tán

PHẦN VIII: Nhà cung cấp xác thực và xác thực hai yếu tố

Thông tin có thể bị xâm phạm, cho dù bằng cách khai thác, mật khẩu bị ghi và mất, máy tính xách tay có khóa bị đánh cắp hoặc người dùng nhập thông tin đăng nhập vào các trang web lừa đảo. Đăng nhập có thể được bảo vệ thêm bằng xác thực hai yếu tố, sử dụng các yếu tố ngoài băng như mã sử dụng một lần nhận được từ một cuộc gọi điện thoại, tin nhắn SMS, ứng dụng hoặc dongle. Một số nhà cung cấp cung cấp dịch vụ xác thực hai yếu tố.

Xác thực hoàn toàn có thể được ủy quyền cho một dịch vụ đăng nhập một lần, trong đó nhà cung cấp khác xử lý việc thu thập thông tin xác thực. Điều này đẩy vấn đề đến một bên thứ ba đáng tin cậy. Google và Twitter đều cung cấp dịch vụ SSO dựa trên tiêu chuẩn, trong khi Facebook cung cấp giải pháp độc quyền tương tự.

PHẢI-LIÊN KẾT ĐỌC VỀ Xác thực Web

1. Hướng dẫn OWASP để xác thực / Bảng xác thực OWASP
2. Dos và Don'ts of Client xác thực trên web (tài liệu nghiên cứu MIT rất dễ đọc)
3. Wikipedia: cookie HTTP
4. Câu hỏi kiến ​​thức cá nhân để xác thực dự phòng: Câu hỏi bảo mật trong kỷ nguyên của Facebook (tài liệu nghiên cứu Berkeley rất dễ đọc)

Điều dứt khoát

Gửi thông tin đăng nhập

Cách thực tế duy nhất để gửi thông tin xác thực 100% an toàn là sử dụng SSL . Sử dụng JavaScript để băm mật khẩu không an toàn. Cạm bẫy phổ biến cho băm mật khẩu phía khách hàng:

• Nếu kết nối giữa máy khách và máy chủ không được mã hóa, mọi thứ bạn làm đều dễ bị tấn công giữa chừng . Kẻ tấn công có thể thay thế javascript đến để phá vỡ băm hoặc gửi tất cả thông tin đăng nhập đến máy chủ của họ, họ có thể lắng nghe phản hồi của khách hàng và mạo danh người dùng một cách hoàn hảo, v.v.
• Mật khẩu băm mà máy chủ nhận được sẽ kém an toàn hơn nếu bạn không làm thêm, công việc dư thừa trên máy chủ.

Có một phương pháp bảo mật khác gọi là SRP , nhưng nó được cấp bằng sáng chế (mặc dù nó được cấp phép tự do ) và có rất ít triển khai tốt.

Lưu trữ mật khẩu

Đừng bao giờ lưu trữ mật khẩu dưới dạng văn bản gốc trong cơ sở dữ liệu. Ngay cả khi bạn không quan tâm đến bảo mật của trang web của riêng bạn. Giả sử rằng một số người dùng của bạn sẽ sử dụng lại mật khẩu của tài khoản ngân hàng trực tuyến của họ. Vì vậy, lưu trữ mật khẩu băm, và vứt bỏ bản gốc. Và đảm bảo mật khẩu không hiển thị trong nhật ký truy cập hoặc nhật ký ứng dụng. OWASP khuyến nghị sử dụng Argon2 làm lựa chọn đầu tiên của bạn cho các ứng dụng mới. Nếu điều này không có sẵn, PBKDF2 hoặc scrypt nên được sử dụng thay thế. Và cuối cùng nếu không có cái nào ở trên có sẵn, hãy sử dụng bcrypt.

Băm mình cũng không an toàn. Chẳng hạn, mật khẩu giống hệt nhau có nghĩa là băm giống hệt nhau - điều này làm cho các bảng tra cứu băm trở thành một cách hiệu quả để bẻ khóa nhiều mật khẩu cùng một lúc. Thay vào đó, lưu trữ băm muối . Muối là một chuỗi được gắn vào mật khẩu trước khi băm - sử dụng một loại muối (ngẫu nhiên) khác nhau cho mỗi người dùng. Muối là một giá trị công khai, vì vậy bạn có thể lưu trữ chúng với hàm băm trong cơ sở dữ liệu. Xem ở đây để biết thêm về điều này.

Điều này có nghĩa là bạn không thể gửi cho người dùng mật khẩu đã quên của họ (vì bạn chỉ có hàm băm). Không đặt lại mật khẩu của người dùng trừ khi bạn đã xác thực người dùng (người dùng phải chứng minh rằng họ có thể đọc email được gửi đến địa chỉ email được lưu trữ (và được xác thực).)

Câu hỏi bảo mật

Các câu hỏi bảo mật không an toàn - tránh sử dụng chúng. Tại sao? Bất cứ điều gì một câu hỏi bảo mật làm, một mật khẩu làm tốt hơn. Đọc PHẦN III: Sử dụng Câu hỏi Bí mật trong @Jens Roland trả lời tại đây trong wiki này.

Cookie phiên

Sau khi người dùng đăng nhập, máy chủ sẽ gửi cho người dùng cookie phiên. Máy chủ có thể truy xuất tên người dùng hoặc id từ cookie, nhưng không ai khác có thể tạo cookie như vậy (cơ chế giải thích TODO).

Cookies có thể bị tấn công : chúng chỉ an toàn như phần còn lại của máy khách và các liên lạc khác. Chúng có thể được đọc từ đĩa, đánh hơi trong lưu lượng mạng, được nâng lên bởi một cuộc tấn công kịch bản chéo trang, lừa đảo từ một DNS bị nhiễm độc để khách hàng gửi cookie của họ đến các máy chủ sai. Đừng gửi cookie liên tục. Cookies sẽ hết hạn vào cuối phiên khách (đóng trình duyệt hoặc rời khỏi miền của bạn).

Nếu bạn muốn tự động đăng nhập người dùng của mình, bạn có thể đặt cookie liên tục, nhưng nó phải khác biệt với cookie toàn phiên. Bạn có thể đặt cờ bổ sung mà người dùng đã đăng nhập tự động và cần đăng nhập thực sự cho các hoạt động nhạy cảm. Điều này phổ biến với các trang web mua sắm muốn cung cấp cho bạn trải nghiệm mua sắm liền mạch, được cá nhân hóa nhưng vẫn bảo vệ các chi tiết tài chính của bạn. Ví dụ: khi bạn quay lại truy cập Amazon, họ sẽ hiển thị cho bạn một trang trông giống như bạn đã đăng nhập, nhưng khi bạn đặt hàng (hoặc thay đổi địa chỉ giao hàng, thẻ tín dụng, v.v.), họ yêu cầu bạn xác nhận mật khẩu của bạn.

Mặt khác, các trang web tài chính như ngân hàng và thẻ tín dụng chỉ có dữ liệu nhạy cảm và không cho phép tự động đăng nhập hoặc chế độ bảo mật thấp.

Danh sách các nguồn lực bên ngoài

• 
  Bài viết học thuật 21 trang của Dos và Don'ts trên Web (PDF) với nhiều lời khuyên tuyệt vời.
• Hỏi YC: Thực tiễn tốt nhất để
  thảo luận Diễn đàn xác thực người dùng về chủ đề này
• Có lẽ bạn đang lưu trữ mật khẩu
  Bài viết giới thiệu không chính xác về việc lưu trữ mật khẩu
• Thảo luận: Kinh dị mã hóa: Có lẽ bạn đang lưu trữ mật khẩu
  Thảo luận trên diễn đàn không chính xác về một bài viết Kinh dị mã hóa.
• Không bao giờ lưu trữ mật khẩu trong cơ sở dữ liệu!
  Một cảnh báo khác về việc lưu trữ mật khẩu trong cơ sở dữ liệu.
• Mật khẩu bẻ khóa
  bài viết Wikipedia về điểm yếu của một số kế hoạch băm mật khẩu.
• Đủ với các bảng cầu vồng: Những điều bạn cần biết về lược đồ mật khẩu an toàn
  Thảo luận về các bảng cầu vồng và cách phòng thủ chống lại chúng, và chống lại các luồng khác. Bao gồm thảo luận rộng rãi.

Đầu tiên, một lời cảnh báo mạnh mẽ rằng câu trả lời này không phù hợp nhất cho câu hỏi chính xác này. Nó chắc chắn không phải là câu trả lời hàng đầu!

Tôi sẽ tiếp tục và đề cập đến BrowserID được đề xuất của Mozilla (hoặc có lẽ chính xác hơn là Giao thức email được xác minh ) trên tinh thần tìm đường dẫn nâng cấp để tiếp cận tốt hơn để xác thực trong tương lai.

Tôi sẽ tóm tắt theo cách này:

1. Mozilla là một tổ chức phi lợi nhuận với các giá trị phù hợp với việc tìm giải pháp tốt cho vấn đề này.
2. Thực tế ngày nay là hầu hết các trang web sử dụng xác thực dựa trên mẫu
3. Xác thực dựa trên mẫu có một nhược điểm lớn, làm tăng nguy cơ lừa đảo . Người dùng được yêu cầu nhập thông tin nhạy cảm vào một khu vực được kiểm soát bởi một thực thể từ xa, thay vì một khu vực được kiểm soát bởi Tác nhân người dùng (trình duyệt) của họ.
4. Vì các trình duyệt được tin tưởng hoàn toàn (toàn bộ ý tưởng của Tác nhân Người dùng là thay mặt Người dùng), nên chúng có thể giúp cải thiện tình trạng này.
5. Lực lượng chính giữ lại tiến độ ở đây là bế tắc triển khai . Các giải pháp phải được phân tách thành các bước mang lại một số lợi ích gia tăng.
6. Phương pháp phi tập trung đơn giản nhất để thể hiện một danh tính được tích hợp vào cơ sở hạ tầng internet là tên miền.
7. Là cấp độ thứ hai để thể hiện danh tính, mỗi tên miền quản lý bộ tài khoản riêng của mình.
8. @Tên miền của tài khoản có tên là tôn trọng và được hỗ trợ bởi một loạt các giao thức và sơ đồ URI. Tất nhiên, một định danh như vậy hầu hết được công nhận là địa chỉ email.
9. Các nhà cung cấp email đã là nhà cung cấp nhận dạng chính trên thực tế trực tuyến. Các luồng đặt lại mật khẩu hiện tại thường cho phép bạn kiểm soát tài khoản nếu bạn có thể chứng minh rằng bạn kiểm soát địa chỉ email được liên kết của tài khoản đó.
10. Giao thức email được xác minh đã được đề xuất để cung cấp một phương thức bảo mật, dựa trên mật mã khóa công khai, để hợp lý hóa quá trình chứng minh cho miền B rằng bạn có tài khoản trên miền A.
11. Đối với các trình duyệt không hỗ trợ Giao thức email được xác minh (hiện tại là tất cả chúng), Mozilla cung cấp một shim thực hiện giao thức trong mã JavaScript phía máy khách.
12. Đối với các dịch vụ email không hỗ trợ Giao thức email được xác minh, giao thức cho phép các bên thứ ba hoạt động như một trung gian đáng tin cậy, khẳng định rằng họ đã xác minh quyền sở hữu tài khoản của người dùng. Không mong muốn có một số lượng lớn các bên thứ ba như vậy; khả năng này chỉ nhằm mục đích cho phép một đường dẫn nâng cấp và được ưu tiên hơn nhiều là các dịch vụ email tự cung cấp các xác nhận này.
13. Mozilla cung cấp dịch vụ riêng của họ để hành động như một bên thứ ba đáng tin cậy như vậy. Nhà cung cấp dịch vụ (nghĩa là các bên dựa trên) thực hiện Giao thức email được xác minh có thể chọn tin tưởng các xác nhận của Mozilla hay không. Dịch vụ của Mozilla xác minh quyền sở hữu tài khoản của người dùng bằng các phương thức gửi email thông thường bằng liên kết xác nhận.
14. Tất nhiên, Nhà cung cấp dịch vụ có thể cung cấp giao thức này như một tùy chọn bên cạnh bất kỳ phương thức xác thực nào khác mà họ có thể muốn cung cấp.
15. Một lợi ích giao diện người dùng lớn đang được tìm kiếm ở đây là bộ chọn nhận dạng nhận dạng. Khi người dùng truy cập vào một trang web và chọn xác thực, trình duyệt của họ sẽ hiển thị cho họ một lựa chọn địa chỉ email (cá nhân, các công việc, các hoạt động chính trị, một cách khác, họ có thể sử dụng để nhận dạng trang web đó.
16. Một lợi ích giao diện người dùng lớn khác đang được tìm kiếm như một phần của nỗ lực này là giúp trình duyệt biết nhiều hơn về phiên của người dùng - hiện tại họ đang đăng nhập, vì vậy nó có thể hiển thị trong chrome trình duyệt.
17. Do tính chất phân tán của hệ thống này, nó tránh được việc khóa các trang web lớn như Facebook, Twitter, Google, v.v. Bất kỳ cá nhân nào cũng có thể sở hữu tên miền của riêng mình và do đó đóng vai trò là nhà cung cấp nhận dạng của riêng họ.

Đây không hoàn toàn là xác thực dựa trên hình thức của Wikipedia cho các trang web. Nhưng đó là một nỗ lực để chuyển từ định mức hiện tại của xác thực dựa trên biểu mẫu sang một thứ an toàn hơn: xác thực được trình duyệt hỗ trợ.

Tôi chỉ nghĩ rằng tôi chia sẻ giải pháp này mà tôi thấy hoạt động tốt.

Tôi gọi nó là Trường giả (mặc dù tôi chưa phát minh ra điều này nên không tin tưởng tôi).

Nói tóm lại: bạn chỉ cần chèn cái này vào <form>và kiểm tra xem nó có trống không khi xác thực:

<input type="text" name="email" style="display:none" />

Bí quyết là đánh lừa bot nghĩ rằng nó phải chèn dữ liệu vào một trường bắt buộc, đó là lý do tại sao tôi đặt tên đầu vào là "email". Nếu bạn đã có một trường được gọi là email mà bạn đang sử dụng, bạn nên thử đặt tên cho trường giả là một cái gì đó khác như "công ty", "điện thoại" hoặc "emailaddress". Chỉ cần chọn một cái gì đó bạn biết bạn không cần và những thứ nghe có vẻ như mọi người thường thấy hợp lý để điền vào biểu mẫu web. Bây giờ hãy ẩn inputtrường bằng CSS hoặc JavaScript / jQuery - bất cứ điều gì phù hợp nhất với bạn - chỉ cần không đặt đầu vào typethành hiddennếu không bot sẽ không thuộc về nó.

Khi bạn xác thực biểu mẫu (phía máy khách hoặc phía máy chủ) hãy kiểm tra xem trường giả của bạn đã được điền để xác định xem nó được gửi bởi người hay bot chưa.

Thí dụ:

Trong trường hợp của một con người: Người dùng sẽ không nhìn thấy trường giả (trong trường hợp của tôi có tên là "email") và sẽ không cố gắng điền vào nó. Vì vậy, giá trị của trường giả vẫn nên trống khi biểu mẫu đã được gửi.

Trong trường hợp bot: Bot sẽ thấy một trường có loại textvà tên email(hoặc bất cứ thứ gì bạn gọi nó) và sẽ cố gắng điền vào nó với dữ liệu thích hợp. Sẽ không quan tâm nếu bạn tạo kiểu biểu mẫu đầu vào với một số CSS ưa thích, các nhà phát triển web sẽ làm điều đó mọi lúc. Dù giá trị trong trường giả là gì, chúng tôi không quan tâm miễn là nó lớn hơn 0ký tự.

Tôi đã sử dụng phương pháp này trên sổ lưu bút kết hợp với CAPTCHA và tôi chưa thấy một bài đăng spam nào. Tôi đã sử dụng một giải pháp chỉ CAPTCHA trước đây, nhưng cuối cùng, nó đã dẫn đến khoảng năm bài đăng spam mỗi giờ. Thêm trường giả trong biểu mẫu đã dừng (ít nhất là cho đến bây giờ) tất cả các thư rác xuất hiện.

Tôi tin rằng điều này cũng có thể được sử dụng tốt với một hình thức đăng nhập / xác thực.

Cảnh báo : Tất nhiên phương pháp này không thể đánh lừa được 100%. Bots có thể được lập trình để bỏ qua các trường đầu vào với kiểu display:noneđược áp dụng cho nó. Bạn cũng phải suy nghĩ về những người sử dụng một số hình thức tự động hoàn thành (như hầu hết các trình duyệt đã tích hợp sẵn!) Để tự động điền vào tất cả các trường mẫu cho họ. Họ cũng có thể nhặt một cánh đồng giả.

Bạn cũng có thể thay đổi điều này một chút bằng cách để trường giả hiển thị nhưng bên ngoài ranh giới của màn hình, nhưng điều này hoàn toàn phụ thuộc vào bạn.

Sáng tạo!

Tôi không nghĩ câu trả lời trên là "sai" nhưng có những lĩnh vực xác thực lớn không được đề cập đến (hay đúng hơn là nhấn mạnh vào "cách triển khai phiên cookie", chứ không phải "tùy chọn nào có sẵn và giao dịch là gì -offs ".

Các chỉnh sửa / câu trả lời được đề xuất của tôi là

• Vấn đề nằm ở việc thiết lập tài khoản nhiều hơn là kiểm tra mật khẩu.
• Việc sử dụng xác thực hai yếu tố an toàn hơn nhiều so với các phương tiện mã hóa mật khẩu thông minh hơn

• KHÔNG cố gắng thực hiện lưu trữ mật khẩu hoặc cơ sở dữ liệu lưu trữ mật khẩu của riêng bạn, trừ khi dữ liệu được lưu trữ là vô giá trị khi tạo tài khoản và tự tạo (nghĩa là, kiểu web 2.0 như Facebook, Flickr , v.v.)

  1. Xác thực Digest là một cách tiếp cận dựa trên tiêu chuẩn được hỗ trợ trong tất cả các trình duyệt và máy chủ chính, sẽ không gửi mật khẩu ngay cả trên một kênh bảo mật.

Điều này tránh mọi nhu cầu phải có "phiên" hoặc cookie vì chính trình duyệt sẽ mã hóa lại thông tin liên lạc mỗi lần. Đó là cách tiếp cận phát triển "nhẹ" nhất.

Tuy nhiên, tôi không khuyến nghị điều này, ngoại trừ các dịch vụ công cộng, giá trị thấp. Đây là một vấn đề với một số câu trả lời khác ở trên - không thử thực hiện lại các cơ chế xác thực phía máy chủ - vấn đề này đã được giải quyết và được hầu hết các trình duyệt chính hỗ trợ. Không sử dụng cookie. Không lưu trữ bất cứ điều gì trong cơ sở dữ liệu cuộn tay của riêng bạn. Chỉ cần hỏi, mỗi yêu cầu, nếu yêu cầu được xác thực. Mọi thứ khác nên được hỗ trợ bởi cấu hình và phần mềm đáng tin cậy của bên thứ ba.

Vì thế ...

Đầu tiên, chúng tôi nhầm lẫn giữa việc tạo tài khoản ban đầu (bằng mật khẩu) với việc kiểm tra lại mật khẩu sau đó. Nếu tôi là Flickr và tạo trang web của bạn lần đầu tiên, người dùng mới có quyền truy cập vào giá trị 0 (không gian web trống). Tôi thực sự không quan tâm nếu người tạo tài khoản nói dối về tên của họ. Nếu tôi tạo một tài khoản của bệnh viện intranet / extranet, những lời dối trá giá trị trong tất cả các hồ sơ y tế, và vì vậy tôi làm việc chăm sóc về bản sắc (*) của người tạo tài khoản.

Đây là phần rất khó. Các chỉ giải pháp phù hợp là một trang web tin cậy. Ví dụ, bạn tham gia bệnh viện với tư cách là bác sĩ. Bạn tạo một trang web được lưu trữ ở đâu đó với ảnh của bạn, số hộ chiếu và khóa công khai và băm tất cả chúng bằng khóa riêng. Sau đó, bạn đến bệnh viện và quản trị viên hệ thống nhìn vào hộ chiếu của bạn, xem ảnh có khớp với bạn không, sau đó băm trang web / ảnh băm bằng khóa riêng của bệnh viện. Từ giờ chúng ta có thể trao đổi khóa và mã thông báo một cách an toàn. Như bất cứ ai có thể tin tưởng vào bệnh viện (có nước sốt bí mật BTW). Quản trị viên hệ thống cũng có thể cung cấp cho bạn khóa RSA hoặc xác thực hai yếu tố khác.

Nhưng điều này là rất nhiều rắc rối, và không phải là web 2.0. Tuy nhiên, đó là cách an toàn duy nhất để tạo tài khoản mới có quyền truy cập vào thông tin có giá trị không tự tạo.

1. Kerberos và SPNEGO - các cơ chế đăng nhập một lần với bên thứ ba đáng tin cậy - về cơ bản người dùng xác minh chống lại bên thứ ba đáng tin cậy. (NB đây không phải là OAuth đáng tin cậy )

2. SRP - loại xác thực mật khẩu thông minh mà không cần bên thứ ba đáng tin cậy. Nhưng ở đây, chúng ta đang đi vào cõi "an toàn hơn khi sử dụng xác thực hai yếu tố, ngay cả khi điều đó tốn kém hơn"

3. Phía máy khách SSL - cung cấp cho khách hàng chứng chỉ khóa chung (hỗ trợ trong tất cả các trình duyệt chính - nhưng đặt ra câu hỏi về bảo mật máy khách).

Cuối cùng, đó là một sự đánh đổi - chi phí của vi phạm an ninh so với chi phí thực hiện các phương pháp an toàn hơn. Một ngày nào đó, chúng ta có thể thấy một PKI thích hợp được chấp nhận rộng rãi và do đó không còn các biểu mẫu và cơ sở dữ liệu xác thực cuộn riêng. Một ngày...

Khi băm, không sử dụng các thuật toán băm nhanh như MD5 (tồn tại nhiều triển khai phần cứng). Sử dụng một cái gì đó như SHA-512. Đối với mật khẩu, băm chậm là tốt hơn.

Bạn có thể tạo băm càng nhanh, bất kỳ trình kiểm tra lực lượng vũ phu nào cũng có thể hoạt động nhanh hơn. Do đó, băm chậm hơn sẽ làm chậm việc ép buộc vũ phu. Một thuật toán băm chậm sẽ làm cho việc ép buộc không thực tế đối với mật khẩu dài hơn (8 chữ số +)

Một bài viết tốt về ước tính cường độ mật khẩu thực tế là:

Dropbox Tech Blog »Lưu trữ Blog» zxcvbn: ước tính cường độ mật khẩu thực tế

Quy tắc yêu thích của tôi liên quan đến các hệ thống xác thực: sử dụng cụm mật khẩu, không phải mật khẩu. Dễ nhớ, khó bẻ khóa. Thông tin thêm: Mã hóa kinh dị: Mật khẩu so với cụm từ vượt qua

Tôi muốn thêm một đề xuất mà tôi đã sử dụng, dựa trên phòng thủ theo chiều sâu. Bạn không cần phải có cùng hệ thống xác thực & xác thực cho quản trị viên như người dùng thông thường. Bạn có thể có một biểu mẫu đăng nhập riêng trên một url riêng thực thi mã riêng cho các yêu cầu sẽ cấp đặc quyền cao. Điều này có thể đưa ra lựa chọn sẽ là một nỗi đau tổng thể cho người dùng thường xuyên. Một cách mà tôi đã sử dụng là thực sự xáo trộn URL đăng nhập để truy cập quản trị viên và gửi email cho quản trị viên URL mới. Dừng mọi cuộc tấn công vũ phu ngay lập tức vì URL mới của bạn có thể khó tùy ý (chuỗi ngẫu nhiên rất dài) nhưng người dùng quản trị viên của bạn chỉ gặp sự bất tiện khi theo liên kết trong email của họ. Kẻ tấn công không còn biết nơi để thậm chí POST.

Tôi không biết tốt nhất nên trả lời đây là câu trả lời hay bình luận. Tôi đã chọn cho tùy chọn đầu tiên.

Liên quan đến bài thơ PHẦN IV: Chức năng mật khẩu bị lãng quên trong câu trả lời đầu tiên, tôi sẽ đưa ra quan điểm về Tấn công thời gian.

Trong biểu mẫu Ghi nhớ mật khẩu của bạn , kẻ tấn công có khả năng kiểm tra danh sách đầy đủ các email và phát hiện được đăng ký vào hệ thống (xem liên kết bên dưới).

Về Mẫu mật khẩu bị lãng quên, tôi sẽ nói thêm rằng đó là một ý tưởng tốt cho thời gian bằng nhau giữa các truy vấn thành công và không thành công với một số chức năng trì hoãn.

https://crypto.stanford.edu/~dabo/ con / webtiming.pdf

Tôi muốn thêm một nhận xét rất quan trọng: -

• "Trong một thiết lập công ty, nội mạng", hầu hết nếu không phải tất cả những điều đã nói ở trên có thể không áp dụng!

Nhiều tập đoàn triển khai các trang web "chỉ sử dụng nội bộ", một cách hiệu quả, "các ứng dụng của công ty" đã được triển khai thông qua các URL. Các URL có thể (được cho là ...) chỉ được giải quyết trong vòng "mạng nội bộ của công ty." (Mạng nào kỳ diệu bao gồm tất cả các 'chiến binh đường bộ' được kết nối VPN.)

Khi người dùng được kết nối chặt chẽ với mạng nói trên, danh tính của họ ("xác thực") là [đã ...] "được biết một cách thuyết phục", như sự cho phép của họ ("ủy quyền") để làm một số việc ... chẳng hạn như. .. "để truy cập trang web này."

Dịch vụ "xác thực + ủy quyền" này có thể được cung cấp bởi một số công nghệ khác nhau, chẳng hạn như LDAP (Microsoft OpenDirectory) hoặc Kerberos.

Từ quan điểm của bạn, bạn chỉ cần biết điều này: rằng bất kỳ ai kết nối hợp pháp tại trang web của bạn đều phải kèm theo [một biến môi trường có chứa ma thuật ...] một "mã thông báo". ( tức là sự vắng mặt của một mã thông báo như vậy phải là căn cứ ngay lập tức 404 Not Found.)

Giá trị của mã thông báo không có ý nghĩa gì với bạn, nhưng, nếu nhu cầu nảy sinh, "phương tiện thích hợp tồn tại" mà trang web của bạn có thể "[có thẩm quyền] hỏi ai đó biết (LDAP ... vv)" về bất kỳ và mọi (!) câu hỏi mà bạn có thể có. Nói cách khác, bạn không tận dụng bất kỳ "logic trồng tại nhà" nào . Thay vào đó, bạn hỏi thăm The Author và hoàn toàn tin tưởng vào phán quyết của nó.

Uh huh ... đó là khá một tinh thần-chuyển từ "Internet hoang dã-and-wooly."

Sử dụng OpenID Connect hoặc Quyền truy cập do người dùng quản lý .

Vì không có gì hiệu quả hơn là không làm gì cả.