Làm thế nào để kiến ​​trúc sư xác thực người dùng từ các ứng dụng khách?

Tôi đã phát triển một ứng dụng sẽ hỗ trợ nhiều người dùng. Vấn đề là tôi không thể tìm ra cách xác thực ứng dụng khách / người dùng.

Tôi đang xây dựng một ứng dụng như http://quickblox.com/ nơi tôi sẽ cung cấp thông tin cho người dùng của tôi và họ sẽ sử dụng để xây dựng những tồn các ứng dụng mà họ không thể đặt tên truy cập và mật khẩu của họ để có được chứng thực.

Hãy giả sử nó đi như sau. (Giống như QuickBlox)

1. Người dùng tạo tài khoản trên trang web của tôi.
2. Người dùng có thể tạo khóa N API và tiết lộ thông tin đăng nhập. (Đối với nhiều ứng dụng)
3. Người dùng sẽ sử dụng các thông tin đăng nhập này trong các ứng dụng của họ (Android, iOS, Javascript, v.v.) để nói chuyện với API REST của tôi.
(API REST có quyền truy cập đọc và ghi.)

Nỗi lo của tôi?

Người dùng sẽ đặt thông tin đăng nhập của họ (khóa API và khóa bí mật) trong các ứng dụng họ xây dựng, nếu ai đó nhận được các khóa này và cố gắng bắt chước người dùng thì sao? (Bằng cách dịch ngược APK hoặc trực tiếp tìm mã JavaScript.

Tôi có sai ở đâu đó không?
Tôi bối rối để kiến ​​trúc sư cơ chế người dùng ba cấp này.

Tôi đã thiết kế API REST trong vài năm qua. Bạn đang lo lắng quá nhiều. Gần đây, một người dùng khác trong diễn đàn này đã hỏi một câu hỏi, nơi anh ta lo lắng về việc lưu trữ các điểm cuối URI trong mã phía máy khách JavaScript của mình .

Các quy tắc tương tự áp dụng cho bạn như áp dụng cho nhà phát triển JavaScript. Nếu bạn cho phép mọi người từ bên ngoài tích hợp API của mình, API của bạn có khả năng hiển thị giống như một trang web thông thường và bạn nên đối xử với nó theo cùng một cách.

Trích dẫn từ câu trả lời ban đầu:

Khi bạn đang tạo một trang web và bạn không muốn người dùng làm điều gì đó, bạn không thực hiện chức năng đó hoặc cấm một số người dùng sử dụng nó. Với API REST cần có các điểm cuối công khai, nó khá giống nhau, bạn cần coi nó như một trang web công cộng.

API REST của bạn phải đủ mạnh để không cho phép các hoạt động không hợp lệ, chẳng hạn như truy cập dữ liệu từ một người dùng khác.

Bạn nên thiết kế mã thông báo truy cập ứng dụng của mình để chỉ cho phép các hoạt động mà bạn muốn được cho phép. Bạn có thể có hai loại mã thông báo truy cập:

• mã thông báo chính : có thể được người tạo ứng dụng sử dụng và cung cấp thêm chức năng từ API của bạn,
• mã thông báo ứng dụng : mã thông báo thực sự sẽ được lưu trữ trong các ứng dụng và sẽ chỉ có quyền truy cập hạn chế vào API của bạn, chỉ cho các hoạt động không thể làm hỏng dữ liệu của bạn hoặc lập trình viên ứng dụng.

Nhưng những gì ai đó giải mã mã nguồn, lấy mã thông báo ra khỏi ứng dụng, tìm ra các điểm cuối công khai là gì và lạm dụng dịch vụ web của bạn?

Trừ khi bạn trực tiếp quản lý việc phát triển các ứng dụng tiêu thụ API của mình, không có gì thực sự cấm mọi người lạm dụng API của bạn theo cùng một cách trực tiếp từ ứng dụng.

Vấn đề của bạn không phải là một vấn đề kỹ thuật nhiều như một doanh nghiệp.

Hãy nói rằng bạn có API của mình, mà bạn bán cho khách hàng của mình (nhà phát triển ứng dụng) với mức giá cố định là 100 bảng mỗi năm, truy cập không giới hạn.

Rõ ràng, tôi có thể mua dịch vụ của bạn với giá 100 bảng và bán cho 10 người với giá 50 đô la mỗi cái. Bạn không muốn điều đó! vì vậy bạn cố gắng nghĩ ra một hạn chế sẽ cho phép bạn bán API của mình mà không bị mở để phân xử.

• Nếu bạn chỉ giới hạn số lượng Ứng dụng, khách hàng có thể tạo một ứng dụng duy nhất chấp nhận kết nối từ các ứng dụng khác và chuyển chúng vào.

• Nếu bạn giới hạn người dùng, một lần nữa, khách hàng có thể ẩn người dùng đằng sau xác thực của chính mình và dường như là một người dùng duy nhất.

Những gì bạn cần làm là chuyển chi phí của mỗi lệnh gọi API cho khách hàng của bạn. tức là tính phí cho mỗi cuộc gọi API hoặc đặt hạn mức cuộc gọi mỗi năm.

Điều này đẩy cùng một vấn đề về chênh lệch giá lên khách hàng của bạn. Nó buộc họ phải đưa ra biện pháp để ngăn chặn người dùng của họ lấy cắp chìa khóa của họ. Trong trường hợp này, ẩn api của bạn đằng sau api xác thực người dùng của họ.

Các câu trả lời khác dường như đều gợi ý rằng vấn đề lưu trữ bí mật trong một ứng dụng trên các thiết bị tiêu dùng là không thể giải quyết được.

Chắc chắn đó là.

Hai nguyên tắc (chi tiết thực hiện sẽ tuân theo):

1. Các điểm cuối xác thực thực tế cần được ẩn danh công khai.
2. Máy chủ phải bằng cách nào đó phải tham gia vào việc xác thực ứng dụng khách và cung cấp khóa API.

Do đó, nếu máy khách đưa ra yêu cầu đến điểm cuối xác thực bằng thông tin xác thực và máy chủ xác thực nó, máy chủ có thể tạo mã thông báo tạm thời động (tạm thời dựa trên thời gian). Mã thông báo này cần được ghi nhớ trong máy khách và được gửi với các yêu cầu tiếp theo.

Bạn sẽ cần một cơ chế để định kỳ "làm mới" mã thông báo, nghĩa là lấy một cái mới. Chỉ cần xây dựng điểm cuối REST cho phép tạo mã thông báo mới từ mã hiện có, để tránh phải xác thực lại từ thông tin đăng nhập.

Nếu bạn đang cố gắng tránh người dùng cuối tự xác thực lại thì xác thực này có thể là thiết lập một lần đầu tiên trong ứng dụng khi được cài đặt.

Giải pháp này chỉ đơn giản là tránh sự cần thiết phải lưu trữ mã thông báo tĩnh được nhúng trong tệp nhị phân của ứng dụng. Một mã thông báo được tạo bởi máy chủ chỉ khi đáp ứng với xác thực thành công. Để người dùng độc hại kiểm tra ứng dụng của bạn và cố gắng truy cập API trái phép, họ vẫn cần xác thực giống như bất kỳ ai khác.

Nếu bạn có các khóa trên mỗi ứng dụng duy nhất, bạn chỉ có thể sử dụng các khóa đó trong khi xác thực kết nối ban đầu, do khách hàng khởi tạo, sau đó bạn chuyển sang mã thông báo xác thực duy nhất cho mỗi ứng dụng.

Thỉnh thoảng, máy chủ của bạn thay đổi (cuộn) mã thông báo cho từng ứng dụng khách (ví dụ cộng / trừ một số độ trễ ngẫu nhiên / mờ ngẫu nhiên). Mã thông báo chỉ được biết giữa máy chủ và máy khách được xác thực.

Các mã thông báo mới được trả lại dựa trên các câu trả lời thông thường. Bất cứ khi nào câu trả lời chứa mã thông báo mới, ứng dụng nhận cần chuyển sang sử dụng nó trong các yêu cầu tiếp theo.

Bất cứ khi nào trao đổi với khách hàng không đồng bộ (một số lỗi giao thức nào đó), máy chủ của bạn sẽ yêu cầu xác thực lại (thông qua phản hồi lỗi cho yêu cầu của khách hàng tiếp theo, hoặc ủng hộ phản hồi hợp lệ cho yêu cầu của khách hàng, cho thí dụ).

Xác thực ban đầu được khởi tạo bởi khách hàng trong khi mã thông báo đang được sử dụng tích cực nên được xem xét với sự nghi ngờ - rất có thể là một nỗ lực bắt chước. Tôi chỉ cho phép nó nếu việc trao đổi không hoạt động trong khoảng thời gian dài hơn dự kiến, ví dụ, có thể do sự cố ngừng hoạt động / khởi động lại của khách hàng với một phiên bản mới không có mã thông báo.

Sẽ tốt hơn nữa nếu duy trì mã thông báo ở phía máy khách để máy khách được khởi động lại có thể tiếp tục từ nơi mà người tiền nhiệm của nó rời đi - thu hẹp đáng kể việc mở để bắt chước.

Sơ đồ như vậy sẽ khiến việc bắt chước ít nhất trở nên khá khó khăn - ứng dụng khách bắt chước sẽ phải dự đoán chính xác cửa sổ khi máy khách được ủy quyền dừng gửi yêu cầu đủ lâu để máy chủ quyết định chấp nhận xác thực ứng dụng khách mới với khóa được chỉ định. Các yêu cầu như vậy bên ngoài cửa sổ được phép có thể được sử dụng để phát hiện các nỗ lực bắt chước và có thể bắt đầu một số biện pháp đối phó (danh sách đen IP, v.v.).

Từ những gì tôi biết, những gì bạn đề cập là cách duy nhất để làm điều này. Ứng dụng lưu trữ khóa chắc chắn là một rủi ro, nhưng có nhiều cách khác nhau để phá vỡ nó. Bạn luôn có thể sử dụng kho khóa để lưu trữ khóa, hơn mã hóa cứng, do đó buộc phải đăng nhập một lần.

Ngoài ra, bạn nên xem xét việc ràng buộc một khóa với máy khách, do đó, nếu ai đó bắt chước, bạn nên có một lớp bảo mật để kiểm tra máy khách, khóa và tác nhân người dùng để chặn yêu cầu ngay lập tức. Có một trường hợp sử dụng để cấp lại hoặc đảm bảo lại rằng các khóa không được bắt chước.

Nếu bạn phụ thuộc vào việc cấp mã thông báo ủy quyền cho khách hàng của mình để đưa vào ứng dụng của họ, về mặt lý thuyết, người nào đó sẽ luôn có thể đảo ngược ứng dụng và trích xuất chúng. Để ngăn chặn điều này, bạn sẽ cần một cơ chế không yêu cầu bí mật trong ứng dụng khách. Đó là khó khăn. Tôi có thể đề xuất một số tùy chọn để bạn suy nghĩ về mặc dù.

Bạn gặp vấn đề khi bạn đã cung cấp thông tin đăng nhập, bạn không kiểm soát được mức độ an toàn của chúng được lưu trữ. Ngoài ra, nếu bạn yêu cầu người dùng gửi thông tin đăng nhập cho bạn thì ai đó có thể MITM kết nối của bạn và lấy cắp mã thông báo trực tiếp mà không cần bận tâm về kỹ thuật đảo ngược ứng dụng.

Một cách làm cho việc trích xuất mã thông báo ủy quyền của bạn trở nên khó khăn hơn là làm xáo trộn nó. Điều này chỉ làm tăng thanh, nhưng không làm cho nó không thể, và để làm điều đó bạn sẽ phải giữ quyền kiểm soát bí mật. Bạn có thể triển khai một thư viện chứa thông tin bí mật và dành riêng cho từng khách hàng. Bạn có thể sử dụng thư viện để liên lạc với máy chủ của mình và thậm chí bạn có thể không phải cho người dùng biết thông tin bí mật, nó chỉ có thể được nhúng trong thư viện. Điều này không giải quyết được vấn đề ai đó đảo ngược kỹ thuật thư viện của bạn, nhưng nó giúp bạn kiểm soát mức độ khó hiểu. Một nhược điểm là một khi một người đã phá vỡ sự xáo trộn trong thư viện, họ có thể tấn công bất kỳ thư viện nào của bạn, trừ khi bạn viết mã khiến mỗi thư viện khác nhau đáng kể. Điều đó giới thiệu bộ vấn đề của riêng mình.

Điều này có thể đi lạc một chút từ phạm vi câu hỏi của bạn, nhưng nó có liên quan đến tính bảo mật của mã thông báo của bạn vì vậy tôi sẽ đề cập đến nó. Để ngăn chặn hành vi trộm cắp tầm thường của mã thông báo qua dây, bạn có thể không muốn gửi mã thông báo trực tiếp, thay vào đó bạn có thể ký lưu lượng truy cập bằng chức năng HMAC. Bạn có thể kiểm tra tính hợp lệ của tin nhắn bằng cách tính toán HMAC của tin nhắn trên máy chủ và so sánh nó với HMAC được gửi từ máy khách. Bạn sẽ sử dụng mã thông báo làm chìa khóa cho chức năng HMAC để chỉ những người biết mã thông báo mới có thể đăng nhập lưu lượng. Điều này tốt hơn cho việc bảo mật mã thông báo của bạn vì bạn không bao giờ gửi trực tiếp đến máy chủ để nó không thể bị chặn và đánh cắp trực tiếp. Để biết thêm thông tin về HMACS, hãy xem câu hỏi này: /security/20129/how-and-when-do-i-use-hmac/20301

Không có giải pháp bảo mật nào là bất khả xâm phạm, bạn phải quyết định sẽ tốn bao nhiêu tiền để thực hiện so với khả năng và chi phí bị xâm phạm.

Trích dẫn bản thân:

Tôi không thể tìm ra cách xác thực ứng dụng khách / người dùng ... trong đó họ không thể đặt tên người dùng và mật khẩu để được xác thực.

Bây giờ đó là một chút mâu thuẫn, phải không? ;)

Như những người khác nói, bạn không thể. Nếu một ứng dụng sử dụng khóa API, người ta có thể dịch ngược nó như bạn nói để lấy (các) khóa đó và cũng sử dụng nó.

Ngoài việc yêu cầu xác thực người dùng phù hợp bổ sung, bạn chỉ có thể hạn chế thiệt hại:

• IP danh sách trắng / danh sách đen
• tiết lưu
• Phát hiện "hoạt động bất thường" và nguồn của nó
• đổi mới chìa khóa dễ dàng