Hướng dẫn đầy đủ về xác thực người dùng

Bài viết này được dịch từ bài The Complete Guide to Authentication của tác giả Lindsay Brunner, đăng trên blog của Stormpath

Xác thực là một quá trình mà trong đó ứng dụng xác minh danh tính của người dùng. Việc xác thực của ứng dụng sử dụng rất nhiều giao thức khác nhau, từ mật khẩu, các giải pháp xác thực một lần đến kiểm tra chữ ký, thẻ RFID, quét vân tay, vân vân.

Xác thực là một tính năng quan trọng đối với ứng dụng của bạn vì để bảo mật dữ liệu của bạn và cho phép người dùng truy cập, bạn cần biết những người dùng đó là ai. Dữ liệu có thể chỉ đơn giản bao gồm dữ liệu cá nhân mà người dùng của bạn cung cấp, nội dung trên cơ sở dữ liệu mà họ truy cập để đọc hay chỉnh sửa, hoặc có thể là một kiến trúc backend mà bạn sử dụng để giám sát hệ thống.

Hãy ghi nhớ: Định quyền KHÔNG phải là một phần của xác thực. Xác thực chỉ gồm việc xác minh danh tính của người dùng, trong khi định quyền là việc xác định/xác minh quyền thuộc về một người dùng. (Chúng tôi nói về định quyền khá nhiều trên blog của mình, nhưng đây là một nơi tuyệt vời để bắt đầu.)

Tóm lại, bạn cần biết chắc rằng người dùng đúng là người mà họ tự nhận. Đó là xác thực.

Xác thực hoạt động như thế nào?

Các ứng dụng xác thực bằng cách so sánh thông tin xác thực mà người dùng cung cấp với thông tin xác thực được lưu trên cơ sở dữ liệu. (Psst... Stormpath cung cấp giải pháp lưu trữ cơ sở dữ liệu người dùng cũng như một số API và SDK tuyệt vời giúp truy cập dữ liệu lưu trữ ở Stormpath). Nếu các thông tin xác thực trùng khớp, người dùng được xác minh và quyền truy cập sẽ được trao cho người dùng dựa trên tập các quyền dành cho người dùng đó.

Có rất nhiều các phương pháp xác thực, dựa trên kiểu thông tin xác thực được cung cấp. Mỗi phương pháp có lợi ích, giới hạn và trường hợp sử dụng riêng biệt. Hãy cùng xem xét các phương pháp chính.

Mật khẩu thỉnh thoảng nhận được chỉ trích, nhưng đó là phương pháp xác thực được sử dụng rộng rãi nhất. Có một số phương pháp mới hơn (từ xác thực bằng token đến API key và xác thực nhiều nhân tố mà chúng ta sẽ thảo luận bên dưới), vậy tại sao các nhà phát triển lại hỗ trợ mật khẩu? Có 2 lý do:

• Không có thứ gì tiện dụng và dễ dàng triển khai như mật khẩu, cho cả phía các nhà phát triển khi xây dựng phần quản lý người dùng và phía người dùng khi đăng nhập.
• Mật khẩu có thể cung cấp mức bảo mật cần thiết cho hầu hết các ứng dụng nếu giao thức cơ bản được triển khai đúng đắn ở cả phía client và phía server.

Viết một giao thức mật khẩu bảo mật cho người dùng của bạn

Phần lớn các vi phạm bảo mật không phải là kết quả của việc một kẻ tấn công khai thác một lỗ hổng bảo mật mà xuất phát từ những sai lầm và thiểu sót đơn giản. Một trong những thiết sót thông thường là giao thức bảo mật mật khẩu. Hệ thông quản lý người dùng tốt sẽ băm tất cả dữ liệu mật khẩu và yêu cầu người dùng đặt mật khẩu "mạnh" có chứa số, chữ cái, hoa-thường và các ký tự đặc biệt.

Hãy đọc thêm về các bí ẩn về việc bảo mật mật khẩu và các cách làm tốt nhất dành cho nhà phát triển mà bạn có thể triển khai tự động ở Stormpath.

Xây dựng tính năng bảo mật mật khẩu tốt hơn ở phía backend

Một trong những vấn đề lớn nhất là rất nhiều ứng dụng web lưu mật khẩu dưới dạng văn bản rõ, và/hoặc xác thực người dùng qua HTTP.

• Cùng với việc yêu cầu người dùng đặt mật khẩu "mạnh", bạn cũng cần để ý tới việc bảo mật các mật khẩu đó. Chúng tôi khuyên bạn:
• Băm mật khẩu với một thuật toán một chiều mạnh.
• Thêm "salt" vào quá trình băm mật khẩu. Salt là một chuỗi bit ngẫu nhiên được thêm vào bản rõ của mật khẩu và băm. Bằng cách thêm salt vào quá trình băm, bạn có thể đảm bảo rằng khi ứng dụng của bạn nhận được mật khẩu giống nhau từ nhiều người dùng, mỗi mật khẩu sẽ được băm ra thành các kết quả khác nhau.
• Thêm work-factor vào quá trình băm mật khẩu. Work-factor sẽ thêm độ phức tạp tính toán, tăng thời gian khi brute-force một mật khẩu. Thời gian thêm vào này chỉ là một vài mili giây (nên nó sẽ không ảnh hưởng tới người dùng) nhưng nó có thể tăng cấp số nhân thời gian mà kẻ tấn công cần để tìm ra nhiều mật khẩu.
• Mã hóa bản mật khẩu đã được băm. Luôn sử dụng khóa bí mật được lưu ở một nơi riêng biệt. Thay thế khóa để đảm bảo chúng không bao giờ được dùng lại.
• Thường xuyên tự động cập nhật bản mã hóa của mật khẩu. Đây là chỗ mà chúng tôi thường thấy việc bảo mật mật khẩu bị gián đoạn. Mặc dù một thuật toán mã hóa có thể là một công nghệ bảo mật mới hôm nay, 18 tháng sau nó có thể sẽ bị tổn thương. Luôn sử dụng các cách làm tốt nhất về băm mật khẩu và mã hóa mới nhất, và ưu tiên thực hiện nâng cấp các biện pháp bảo mật của bạn.

Xác thực bằng token là một phương pháp hiện đại hơn, được thiết kế để giải quyết các vấn đề không thể giải quyết bằng session ID được lưu ở phía server. Xác thực bằng token tăng khả năng mở rộng của ứng dụng của bạn, làm giảm tải cho server và hỗ trợ tốt hơn cho các microservice phân tán hoặc cloud-based.

Token Access và Refresh được sử dụng rộng rãi nhất, và liên quan nhất tới thảo luận về xác thực của chúng ta. Về cơ bản: khi một người dùng lần đầu tiên yêu cầu xác thực với ứng dụng của bạn, họ sẽ nhận được cả hai token. Token Access sẽ hết hạn sau một khoảng thời gian ngắn (bạn sẽ kiểm soát khoảng thời gian này, "ngắn" chỉ đơn giản là một cách làm tốt) và khi nó hết hạn thì token Refresh sẽ hướng dẫn ứng dụng sinh ra một token Access mới cho người dùng. Token Refresh có một thời hạn sử dụng, cho phép token này sử dụng không giới hạn đến khi token này hết hạn sử dụng.

Stormpath có thể sinh, quản lý, kiểm tra và thu hồi cả token Access và Refresh.

API key có chức năng như một công cụ có thể theo dõi được dành cho việc xác thực mà không bao giờ hiện diện ở phía giao diện người dùng. API key là một thứ thay thế mật khẩu được máy sinh ra mà ứng dụng gửi tới để có thể truy cập đến API của bạn. Nó còn có thể cho phép nhiều thiết bị truy cập vào hệ thống. API key làm tăng tính bảo mật của API (đặc biệt khi so sánh với các phương pháp xác thực giữa máy với máy sử dụng username/password) theo nhiều cách:

• Khó thu hồi username. API key dễ thu hồi hơn vì nó không liên kết với một định danh người dùng nào cả.
• API key được sinh ra ngẫu nhiên, dài hơn username nhiều và không bao giờ chứa các từ có thể tìm thấy trong từ điển. Điều này loại bỏ hầu hết cách kiểu tấn công thông thường.
• Một API key bị rò rỉ vẫn giữ cho người dùng được bảo vệ vì nó không chứa thông tin định danh nào cả.

Lời khuyên từ chuyên gia: API key rất quan trọng với việc bảo mật ứng dụng của bạn, vì thế đừng lưu chúng ở những nơi dễ dàng truy cập được (ví dụ như hòm thư điện tử, hoặc trong một tập tin mã nguồn được đẩy lên trên một kho chứa git). Cách tốt nhất là bạn nên sử dụng biến môi trường hoặc một tập tin chỉ có quyền đọc bởi ứng dụng của bạn.

Xác thực nhiều nhân tố là một trong những chủ đề nóng đối với các nhà phát triển ứng dụng đang tìm cách xây dựng chức năng quản lý người dùng. Một "nhân tố" trong việc xác thực đơn giản là một phần thông tin chứng minh rằng bạn là người mà bạn tự nhận. Do vậy, xác thực nhiều nhân tố đơn giản là việc xác thực yêu cầu cung cấp 2 hay nhiều thông tin xác thực độc lập với nhau.

Một trong những nhân tố thứ 2 phổ biến là Google Authenticator, thứ có thể tích hợp với hầu hết các ứng dụng. Nếu Google Authenticator được tích hợp với một ứng dụng bạn muốn truy cập, bạn sẽ được yêu cầu nhập một mã đi kèm với mật khẩu hoặc nhập sau khi nhập mật khẩu. Mã này sẽ được gửi tới thông qua ứng dụng Google Authenticator dành cho iOS và Android hoặc qua một tin nhắn SMS.

Một nhân tố xác thực thứ 2 chắc chắn cải thiện tính bảo mật cho dữ liệu của bạn, bằng cách áp dụng việc kiểm soát truy cập nghiêm ngặt hơn. Lấy Google Authenticator làm ví dụ, một người có ý định xấu sẽ cần cả mật khẩu của người dùng và cả việc truy cập một cách vật lý tới điện thoại của người đó để có thể truy cập vào ứng dụng. Đây là kiểu xác thực dựa trên sở hữu, trong đó chỉ có một nhân tố xác thực mà bạn có thể xác minh. Hãy xem xét các nhân tố:

Tri thức

Nhân tố tri thức này sử dụng thứ gì đó mà người dùng của bạn biết. Thông thường đó là một cặp username/password, nhưng cũng có thể là một mã PIN hoặc câu trả lời cho một câu hỏi bí mật. Bạn và người dùng đều biết thông tin được yêu cầu. Do đó, ứng dụng của bạn có thể xác minh chúng.

Sở hữu

Xác thực dựa trên sở hữu thêm một nhân tố, trong đó người dùng được yêu cầu đưa ra một thông tin xác thực cụ thể mà họ sở hữu. Các thông tin xác thực này nằm ở 2 dạng, kết nối và không kết nối, cho biết trạng thái của chúng so với chiếc máy mà người dùng đang sử dụng để xác thực.

Chúng ta đã lấy Google Authenticator làm một ví dụ về xác thực dựa trên sở hữu, ngoài ra còn có rất nhiều chương trình khác. Chương trình xác thực của battle.net là một ví dụ về một tài nguyên được kết nối được sử dụng để đăng nhập vào battle.net trên một trình duyệt di động trên cùng thiết bị. (For the Horde!)

Nhân tố tự nhiên

Nhân tố tự nhiên là thứ kết nối một cách vật lý với người dùng, và thông thường liên quan đến sinh học. Hai ví dụ tuyệt vời về nhân tố này là hệ thống iOS Touch ID và chương trình phân tích keystroke Honor Code của Coursera.

Khi bạn muốn "xây dựng chức năng xác thực", thực sự bạn sẽ phải "xây dựng chức năng quản lý người dùng", vậy những chức năng nào có thể sẽ đi kèm với chức năng xác thực và định quyền? Thông thường đó là:

Tự đăng ký

Luồng đăng ký là nền tảng của bất cứ hệ thống quản lý người dùng nào. Chức năng tự đăng ký cho phép người dùng tạo tài khoản của mình, bao gồm thông tin đăng nhập và mật khẩu, mà không cần đến sự trợ giúp hay can thiệp của đội hỗ trợ hay vận hành hệ thống của bạn. Giao thức tự đăng ký có thể được tùy biến để cho phép thu thập các thông tin đa dạng dựa trên yêu cầu của tổ chức hay người dùng của bạn.

Quá trình tự đăng ký không phải là một hệ thống làm-ra-rồi-bỏ-quên. Bằng cách theo dõi mức độ tương tác, tỉ lệ chuyển đổi và dữ liệu hồ sơ giả mạo, bạn có thể tối ưu hệ thống để giảm thiểu bất đồng, tạo sự tích cực trong trải nghiệm của người dùng. Kết nối với các mạng xã hội và tối ưu quá trình đăng ký cho các khách hàng sử dụng di động và cách nhân tố quan trọng khác có thể bị bỏ qua.

Email xác minh

Chuyện gì xảy ra khi một người dùng mới đã hoàn tất quá trình đăng ký? Đã đến lúc gửi cho họ một email xác minh. Thêm bước xác minh tự động này vào luồng đăng ký của bạn đã trở thành một cách làm phổ biến, được sử dụng để đảm bảo rằng những người dùng mới tuyệt vời mà bạn vừa có thêm là người thực sự với những địa chỉ email đang hoạt động mà qua đó bạn có thể tiếp tục liên lạc. Dữ liệu này là vô giá đối với sự toàn vẹn của cơ sở dữ liệu và các nỗ lực tiếp thị đối với thương hiệu của bạn.

Đặt lại mật khẩu

Không có nhiều sự đảm bảo trong cuộc sống, nhưng chúng ta có thể đảm bảo một điều: người dùng của bạn sẽ quên mất mật khẩu của họ. Chỉ có một số ít các thành phần trong một hệ thống quản lý người dùng mạnh mẽ quan trọng hơn một giao thức tự động cho phép người dùng của bạn đặt lại mật khẩu của họ mà không phụ thuộc vào đội trợ giúp IT của bạn. Đây là lý do:

Theo khảo sát của Norton, 25% người dùng quên mất 3 mật khẩu hoặc nhiều hơn mỗi tháng. Điều này không hề sốc nếu bạn biết rằng trung bình một người cần thường xuyên nhớ tới 19 mật khẩu hoặc nhiều hơn (theo tờ Daily Mail). Tờ Daily Mail còn khẳng định rằng quên mật khẩu kích thích sự thất vọng tột độ, bao gồm "khóc, la hét và đập đầu vào bàn".

Ouch.

Nhưng chờ đã, còn nữa: tập đoàn truyền thông Cox Communication của Mỹ đã báo cáo rằng 20% số yêu cầu trợ giúp IT của họ là các vấn đề liên quan đến mật khẩu! (Và đã có một giao thức tự động ở đó rồi đấy!)

Vậy bạn cần làm gì?

Dễ thôi, tích hợp những yêu cầu này vào trong luồng tự đăng ký của bạn. Thu thập bất cứ thông tin xác thực nào bạn cần để xác minh người dùng ngay từ lúc họ tạo tài khoản. Cách làm tốt nhất sau khi giao thức "Quên mật khẩu" được kích hoạt là cung cấp một link sử-dụng-một-lần dẫn tới một trang web bảo mật cho người dùng để họ có thể tạo mật khẩu mới.

Cập nhật tài khoản

Người dùng ngày nay bị ảnh hưởng bởi các phương tiện truyền thông và mong muốn một mức truy cập và kiểm soát dữ liệu cá nhân của họ, đặc biệt là nếu trang web hay ứng dụng của bạn bao gồm các tính năng cộng đồng. Người dùng được trao quyền kiểm soát dữ liệu mà họ có thể chia sẻ càng lớn thì họ sẽ có xu hướng chia sẻ nhiều dữ liệu hơn, và bằng cách cập nhật hồ sơ cá nhân của mình, họ sẽ tăng giá trị tổng thể của cơ sở dữ liệu của bạn.

Lời khuyên của chuyên gia: Đừng bỏ mặc, không bảo mật những thông tin vô giá này. Xem xét các quy tắc và điều lệ của bạn cùng với các giao thức có thể liên quan đến ứng dụng của bạn. (Xin chào HIPAA!)

Giờ hãy quay lại với xác thực. Trong phạm vi của việc phát triển di động và API, bạn có thể tiếp cận việc xác thực theo rất nhiều cách:

Như chúng ta đã thấy, các ứng dụng giao tiếp với khách hàng cần một tập các tính năng cốt lõi liên quan đến quản lý và xác thực người dùng. Các ứng dụng cần cung cấp các mức truy cập khác nhau dựa vào người dùng. Nhiều kỹ sư lãnh đạo tin rằng các giải pháp tự phát triển là cách làm đúng, và những người khác không hay biết đến các giải pháp của bên thứ ba như Stormpath.

Hầu hết các nhà phát triển có thể xử lý các luồng chính như tạo tài khoản, đăng nhập, đặt lại mật khẩu, nhưng các tính năng cao cấp hơn như vai trò, quyền, hỗ trợ xác thực một lần, phân chia dữ liệu khách hàng, xác thực bằng token, xác thực nhiều nhân tố, đăng nhập bằng mạng xã hội, và tích hợp LDAP/Active Directory, cần một sự nỗ lực đáng kể. Các nhà phát triển thường đánh giá thấp sự phức tạp của việc xây dựng một hệ thông quản lý người dùng tinh vi và bảo mật, cũng như sự cần thiết của những kỹ năng chuyên ngành, điều khiến deadline dồn dập và nợ kỹ thuật tăng cao.

Các nhà phát triển yêu Stormpath vì dịch vụ cao cấp và tập trung vào nhà phát triển, và cũng bởi nó khiến cuộc sống của họ dễ dàng hơn: họ có thể triển khai Stormpath trong vài phút. CTO có thể nghỉ ngơi và biết rằng dữ liệu người dùng và luồng thực thi được xử lý đúng cách, trong khi người dùng có một trải nghiệm liền mạch, bảo mật xuyên suốt ứng dụng.

Lợi ích của việc quản lý người dùng với Stormpath bao gồm:

• Tốc độ phát triển, phát hành ứng dụng lớn
• Giảm chi phí phát triển và bảo trì ứng dụng
• Giúp đội phát triển tự do tập trung vào các tính năng cốt lõi của ứng dụng
• Tính mở rộng và tin cậy tối đa
• Giảm rủi ro thông qua các biện pháp bảo mật tiên tiến nhằm bảo vệ dữ liệu người dùng của bạn

Hãy xem các tài nguyên sau để tìm hiểu thêm:

• Hướng dẫn về REST Product của Stormpath
• Build vs. Buy Whitepaper của chúng tôi
• User Identity as a Service

Hoặc là bắt đầu ngay! API của chúng tôi có thể cung cấp cho bạn một cơ sở dữ liệu người dùng và dịch vụ xác thực mạnh mẽ ngay lập tức, chỉ trong 15 phút.