Xác thực web bằng cách sử dụng PKI Certs

Tôi hiểu PKI một cách hợp lý từ quan điểm khái niệm - tức là khóa riêng / khóa chung - toán học đằng sau chúng, sử dụng hàm băm & mã hóa để ký chứng chỉ, Ký kết giao dịch hoặc tài liệu kỹ thuật số, v.v. Tôi cũng đã từng làm việc với các dự án mở Thư viện C đã được sử dụng với certs để bảo mật thông tin liên lạc và xác thực. Tôi cũng cực kỳ quen thuộc với các công cụ dòng lệnh openssl.

Tuy nhiên, tôi có rất ít kinh nghiệm với các dự án hỗ trợ PKI dựa trên web và do đó tôi đang cố gắng thiết kế và viết mã dự án cá nhân để hiểu rõ hơn về điều này.

Những yêu cầu

Đây là trang web cho một ngân hàng. Tất cả người dùng Internet Banking đều được phép sử dụng bất kỳ chứng chỉ nào được cấp bởi một vài CA đã biết (verisign, Thawte, ủy thác, v.v.). Ngân hàng không chịu trách nhiệm mua sắm chứng chỉ cho người dùng. Những chứng chỉ này sẽ được sử dụng để xác thực cho trang web của ngân hàng. Các nền tảng / hệ điều hành vv vẫn chưa được sửa.

Thiết kế

Tôi đã tự hỏi cách tốt nhất để xác thực là gì.

1. Tôi thấy rằng Apache có một cách để kích hoạt ssl 2 chiều - trong trường hợp này, tôi nghĩ rằng việc điều hướng đến trang web sẽ tự động yêu cầu chứng nhận từ người dùng. Nhưng tôi không chắc liệu điều này có đủ hay không vì dường như tất cả những gì nó xác minh là liệu chứng chỉ có được ký bởi một CA đáng tin cậy hay không và cũng có thể là liệu nó có nằm trong danh sách trắng các dòng chủ đề của chứng chỉ hay không, nhưng điều này là không đủ đối với trường hợp ngân hàng vì bạn cần có khả năng liên kết ngân hàng với chứng chỉ.

2. IIS dường như có một cách mà tôi có thể có một chứng chỉ được lưu trữ cho mỗi người dùng trong Active Directory. Đây là những gì tôi hiểu từ việc đọc một vài bài báo MSDN. Bạn bật SSL 2 chiều trong IIS và sau đó khi người dùng cố điều hướng đến trang web, IIS sẽ gửi yêu cầu tới trình duyệt với danh sách các CA được phê duyệt và trình duyệt sẽ cho phép người dùng chọn chứng chỉ phù hợp từ cửa hàng chứng nhận của mình và gửi nó để phụ trợ. Tôi giả sử rằng IIS sẽ làm 2 việc

   • Đảm bảo rằng người dùng có khóa riêng tương ứng với chứng chỉ (theo các cuộc đàm phán bao trùm)
   • Dựa trên Ánh xạ chứng chỉ người dùng quảng cáo, IIS sẽ báo cáo tên người dùng cho ứng dụng.

3. Thực hiện khám phá xác thực bằng cách gọi các chức năng của tiền điện tử thay vì tùy thuộc vào máy chủ web để thực hiện.

   • Hiển thị màn hình người dùng nơi anh ta tải lên một chứng chỉ và ứng dụng đảm bảo người dùng có khóa riêng tương ứng với chứng chỉ (bằng cách yêu cầu giao diện người dùng ký một số chuỗi bằng chứng chỉ).
   • Ứng dụng này có một cơ sở dữ liệu một số dữ liệu được lưu trữ cho phép mỗi người dùng được ánh xạ tới userid của mình. Điều này có thể
   • toàn bộ chứng chỉ tương ứng với mỗi userid
   • số sê-ri CA và cert tương ứng với mỗi id người dùng.

Tôi đã tự hỏi đó là phương pháp thường được sử dụng? Các thực hành tốt nhất là gì? Nếu tôi nên đi với số 3, cách tốt nhất để làm điều này là gì?

Một cái gì đó cũng có thể dễ dàng làm việc với các ứng dụng điện thoại thông minh sẽ là một phần thưởng bổ sung.

Cập nhật

Hãy để tôi làm rõ tuyên bố của mình "mã phần xác thực" bởi vì một số câu trả lời dường như chỉ ra rằng nó đã bị hiểu sai - điều xấu của tôi là không rõ ràng.

Điều này không có nghĩa là tôi tự viết tiền điện tử. Nó chỉ có nghĩa là tôi thực sự sẽ gọi các thói quen của tiền điện tử một cách rõ ràng thay vì phụ thuộc vào IIS hoặc bất kỳ máy chủ web nào khác làm điều đó một cách ngầm định.

Mặc dù tôi thực sự muốn trả lời vấn đề theo vấn đề, tôi nghĩ tôi sẽ nhấn chủ đề này theo chủ đề:

Ủy quyền / Xác thực

OK, điều đầu tiên đầu tiên. Ví dụ của bạn, bạn cần cả hai:

• Xác thực - bằng chứng cho thấy người dùng là người mà anh ta nói. Bạn đã chọn PKI, với bằng chứng ngụ ý về khóa riêng là xác thực của bạn.
• Ủy quyền - kết nối của người dùng với những gì anh ta được phép làm. Đây là điểm kết nối giữa đăng nhập và nhận quyền truy cập vào các tài khoản được phép. Việc ánh xạ chứng chỉ vào tài khoản và khả năng truy cập tài khoản là ủy quyền.

Ủy quyền, bạn có vấn đề trong việc tìm ra quy trình mà bạn kết nối DN chủ đề của người dùng với tài khoản ngân hàng của họ. Với trọng lực của giao dịch, bạn chắc chắn muốn có một quy trình mạnh mẽ cho việc này, và không có cách duy nhất đúng ở đây. Bạn phải tham khảo ý kiến ​​của ngân hàng, và có lẽ đó là luật sư, để tìm ra cách thực hiện việc này theo chính sách.

Xác thực SSL, Máy khách / Máy chủ, Bằng chứng về Khóa riêng

Giao thức SSL luôn bao gồm xác thực máy chủ, với một cài đặt tùy chọn bổ sung cho ủy quyền phía máy khách. Bạn đúng với số 1 trong đó Apache cung cấp một cài đặt thêm Xác thực ứng dụng khách bằng PKI và bạn có thể cung cấp cho nó một danh sách các CA đáng tin cậy. Trong quá trình thiết lập phiên SSL yêu cầu Xác thực ứng dụng khách thông qua PKI - bạn sẽ nhận được bằng chứng về khóa riêng.

Tùy chọn # 1 hoặc tùy chọn # 2 sẽ cung cấp điều này - cả Apache và IIS đều có thể được cấu hình theo cách này. Thực hành tốt nhất khôn ngoan, tôi sẽ chọn một trong những giải pháp của riêng bạn. # 3 hoàn toàn gần với quy tắc "không viết tiền điện tử của riêng bạn". Giả sử rằng bạn có thể ràng buộc giao dịch của mình với sự hiện diện của phiên SSL được xác thực, không có lý do gì để bạn thực hiện giao dịch của mình.

Ngoài ra - trong tùy chọn # 1 hoặc tùy chọn # 2, có một cách để bạn có được toàn bộ chứng chỉ và từ đó, đến bất kỳ phần nào của chứng chỉ. Thông thường, số sê-ri của Chủ đề DN và / hoặc chứng chỉ được sử dụng để xác định danh tính người dùng cho mục đích ủy quyền.

Về mặt "sử dụng chung" - tất cả các máy chủ web chính đều khá phổ biến. IIS, Apache, Tomcat và nhiều người khác có thể được cấu hình với SSL auth client. Quyết định từ đó phần lớn dựa trên việc thực hiện tổng thể. Các máy chủ web lớn đều có cách để có quyền truy cập vào chứng chỉ được cung cấp trong phiên SSL, đây là những gì bạn cần để xác minh chi tiết hơn.

Xác nhận chứng chỉ Thêm

Tối thiểu, bạn sẽ cần:

• thiết lập phiên SSL
• lấy chứng chỉ (hầu hết các máy chủ web sẽ kiểm tra chữ ký và bằng chứng của khóa riêng)
• xác minh ngày hiệu lực của chứng chỉ (không phải với bất kỳ máy chủ web nào)
• thực hiện kiểm tra ủy quyền cho những tài khoản mà chứng chỉ này có thể truy cập

Với các cổ phần ngân hàng cao, bạn cũng có thể muốn xác minh trạng thái hủy bỏ chứng chỉ - nếu khóa riêng của người dùng bị mất hoặc bị đánh cắp, chứng chỉ của họ sẽ bị thu hồi.

IIS có thể có các móc nối để xác minh OCSP hoặc CRL - nó có xu hướng là một loại hệ thống (cầm tay!) Toàn diện hơn, nhưng tôi không nhớ ra khỏi đầu. Tôi cũng không nhớ nếu nó sẽ buộc bạn sử dụng các sản phẩm của Microsoft cho việc này. Đối với Apache, bạn gần như chắc chắn sẽ phải mã hóa hoặc thêm vào kiểm tra OCSP / CRL. Tôi tin rằng nó có các móc nối trong quá trình thiết lập phiên SSL - thường thì kiểm tra này được thực hiện một lần khi phiên SSL được thiết lập.

Ủy quyền

Trên # 1 so với # 2 - bạn đúng là IIS có một số chức năng được tích hợp sẵn sẽ gắn chứng chỉ được cung cấp trong phiên SSL vào kho lưu trữ AD. Đây là một trong những trường hợp Microsoft đi xa hơn để dễ dàng mua và sử dụng nhiều sản phẩm hơn. :) Có nhiều sắc thái về cách IIS liên kết với AD vượt ra ngoài phạm vi của câu hỏi này và vượt ra ngoài hồi ức ngay lập tức của tôi. Tôi đã thực hiện một số thứ khá điên rồ với IIS và AD, và suy nghĩ chung của tôi là trong khi bạn đang làm một việc tương đối đơn giản như lấy tên người dùng dựa trên chứng chỉ từ kho lưu trữ AD - có lẽ bạn vẫn ổn. Đó là khi bạn gặp phải các vấn đề phức tạp hơn về lưu trữ dữ liệu, tra cứu AD kỳ quặc và những thứ đặc biệt điên rồ (nhưng hợp pháp) với PKI, bạn '

Với IIS, thậm chí vẫn còn - bạn sẽ cần một cái gì đó được thêm vào cấu trúc AD của mình hoặc ở một nơi khác, nhập tên người dùng vào tài khoản ngân hàng. Thông thường trong ngân hàng, một người dùng có nhiều tài khoản. Và 2 người dùng có thể có một tài khoản chung, vì vậy đây là mối quan hệ nhiều đến nhiều.

Đối với # 1 - yep, bạn cần viết tra cứu của riêng bạn. Bạn cần mã: - cơ sở dữ liệu hoặc phân cấp LDAP kết nối chứng chỉ với người dùng và người dùng với tài khoản ngân hàng người dùng. Phần duy nhất được bảo đảm của chứng chỉ là số sê-ri + nhà phát hành DN. Thường Chủ đề DN sẽ hoạt động, nhưng nó không được bảo đảm trong tất cả các hệ thống PKI.

Đó thường là cách các nhà phát triển sử dụng PKI để xác thực cao cấp với Apache thực hiện điều đó. Đã làm việc trong một số hệ thống này, tôi chưa gặp phải trường hợp tái sử dụng ủy quyền dễ dàng, vì vậy tôi chưa bao giờ thực sự coi đó là một điểm trừ lớn - tôi sẽ phải có một cái gì đó đặc biệt, vì vai trò / đặc quyền là không bao giờ dễ dàng.

Điều này nghe có vẻ như là sự pha trộn giữa # 1 và # 3 - lời khuyên mạnh mẽ của tôi sẽ là - sử dụng các khả năng riêng của bất kỳ ứng dụng / máy chủ web nào bạn sử dụng để tạo phiên SSL. Điều đó sẽ cho phép trình duyệt đến máy chủ thiết lập với truy vấn chứng chỉ diễn ra theo cách chuẩn, cách thực hành tốt nhất. Từ đó, với Apache, bạn sẽ cần cuộn hệ thống ủy quyền của riêng mình. IIS sẽ cung cấp cho Microsoft ý tưởng về cách thức hoạt động của bạn.

Gotchas được biết đến

Làm một loạt các thử nghiệm trình duyệt. Từ năm này sang năm khác, trình duyệt đến trình duyệt, tôi tìm thấy gotchas với xử lý phiên SSL. Xâu chuỗi chính xác phiên SSL vào chuỗi các yêu cầu trang web và đảm bảo rằng đăng xuất được xử lý chính xác là lĩnh vực quan tâm lớn nhất. Và nó có rất nhiều việc phải làm với cả máy chủ và phần mềm trình duyệt. SSL đủ ổn định để khi nó hoạt động, nó thường hoạt động, mặc dù có thể có IE so với các vấn đề khác.

Đặc biệt, lần cuối cùng tôi làm điều này, câu hỏi về mã hóa lực lượng và hết thời gian phiên là một vấn đề lớn.

Điện thoại thông minh

Tốt May mắn là về tất cả những gì tôi có thể nói. Tôi hoàn toàn không phải là nhà phát triển ứng dụng di động, nhưng ấn tượng của tôi cho đến nay là trong điện thoại thông minh trung bình, việc xử lý chứng chỉ PKI là ngang bằng hoặc không tồn tại.

Tôi rất muốn được chứng minh là sai.

Chứng chỉ cá nhân hoạt động tốt để gia hạn chứng chỉ định kỳ (có quá trình khá mạnh mẽ đằng sau nó) và có thể được thực hiện dưới dạng xác thực "không cần mật khẩu" mà khách hàng thích

nhưng nó thất bại ở đâu

• Chi phí cho mỗi chứng chỉ
• tương thích với các trình duyệt hiện đại
• người dùng cuối trích xuất chứng chỉ và lưu trữ khóa riêng không an toàn

lưu ý rằng các chứng chỉ cá nhân hiện đại có ký tên sha-2 không hoạt động với Safari trên iPad và nhiều trình duyệt hiện đại. Điều này là do chứng chỉ cá nhân không bao giờ thực sự cất cánh như các tổ chức thẩm quyền chứng nhận nghĩ rằng nó có thể. Phát hành 30.000 chứng chỉ (những gì chúng tôi làm) có chi phí tương đương với mỗi chứng chỉ như một số loại mã thông báo phần cứng.

Chiến lược của bạn để cho phép khách hàng tìm chứng chỉ của riêng họ là không thực sự hợp lệ. Ngày nay, thật khó để tìm thấy các nhà cung cấp chứng chỉ cá nhân và chúng khá đắt - bạn cần đảm bảo rằng trường hợp kinh doanh hoạt động nếu không khách hàng sẽ không mua vào điều này.

Được rồi, rất nhiều thứ đang diễn ra ở đây. Trước tiên, xác thực chứng chỉ ứng dụng khách là vô ích nếu nó không được hỗ trợ trên điểm cuối. Vì vậy, chúng tôi có một bài đăng tuyệt vời từ Intrepidus bao gồm những điều cơ bản về xác thực ứng dụng khách cho các ứng dụng điện thoại thông minh .

Tiếp theo, hãy để tôi đề nghị bạn không mã hóa thói quen xác thực của riêng bạn. Có rất nhiều thư viện tuyệt vời, được hiệu đính xử lý việc này. Bạn sẽ tiết kiệm cho mình các chức năng và lỗi bảo mật bằng cách chạy với một thư viện trưởng thành để xác thực. Sử dụng một thư viện thuần thục, trưởng thành cho việc này chắc chắn sẽ là cách thực hành tốt nhất.

Thực hành tốt nhất tiếp theo là sử dụng một thư mục để xử lý ứng dụng khách của bạn: ánh xạ chứng chỉ. Vì vậy, bạn sẽ xem xét AD hoặc LDAP. Như bạn đã đề cập, Windows và IIS làm cho điều này khá liền mạch cho bạn. IIS.net có một danh sách tốt về cấu hình ánh xạ chứng chỉ trong IIS .

Nếu bạn cuộn với Apache, điều này không dễ dàng gì. Có vẻ như mod_authz_ldap thực hiện ánh xạ chứng chỉ ứng dụng khách, nhưng tôi chưa từng làm việc với nó.

Vì vậy, điều đó đưa chúng ta đến hậu cần thực sự thực hiện một cái gì đó như thế này. Bạn không ký tên vào tài khoản của người dùng, vì vậy bạn cần một quy trình bằng sắt cho người dùng gửi chứng chỉ của họ và để ứng dụng của bạn xuất bản nó vào thư mục. Tôi muốn xem hai yếu tố cho việc này, với mật khẩu auth và tin nhắn văn bản hoặc gọi đến một số đáng tin cậy. Tôi sẽ gửi email cho người dùng để cho họ biết rằng một chứng chỉ đã được thêm vào tài khoản của họ. Tôi sẽ cho phép người dùng xóa ánh xạ chứng chỉ người dùng thông qua trang quản lý tài khoản của họ trong ứng dụng.

Tôi sẽ xem Google và Facebook làm gì để đặt cookie cho các thiết bị đáng tin cậy để tránh hai yếu tố. Tôi sẽ có các thiết bị mới auth với hai yếu tố trước khi cho phép auth chỉ có chứng chỉ.

Tôi cũng sẽ suy nghĩ về cách xử lý các certs người dùng bị thu hồi. Điều này có nghĩa là kiểm tra danh sách thu hồi chứng chỉ bên ngoài (CRL). Bạn sẽ làm gì nếu chứng chỉ ứng dụng khách không có điểm phân phối CRL được xác định? Bạn có kiểm tra CRL bất cứ khi nào người dùng đăng nhập hoặc trên cơ sở theo lịch trình như một phần của công việc không, vì có khả năng sẽ chỉ có một số ít CRL được sử dụng?

Thực sự, điều này có nghĩa là: làm sao tôi biết rằng tôi có thể tin tưởng rằng các thành phần của người dùng không bị xâm phạm và làm thế nào để tôi tin rằng tôi có thể ánh xạ chứng chỉ X cho người dùng Y.