#137 - Hệ thống xác thực của bạn có thiếu sót gì?
TechTalk #38 - Languages, Technologies, Architectures - different components that make a high performance system
Để xây một ngôi nhà vững chắc thì cần rất nhiều thứ như nền móng, tường, cột, ... Tương tự, để xây một một hệ thống phần mềm vững chắc thì cần sự kết nhiều yếu tố như ngôn ngữ lập trình, công nghệ và kiến trúc phù hợp, ...
Trong Grokking TechTalk #38 lần này, các bạn sẽ được giới thiệu quá trình phân tích hiệu năng của một hệ thống và những phương pháp giải quyết sử dụng từ thiết kế kiến trúc hệ thống cho tới kỹ thuật lập trình.
Ngoài ra bạn cũng có cơ hội tìm hiểu thêm về những stack công nghệ mà một công ty có lượng người dùng lớn như LINE Technology Vietnam thường sử dụng.
Các bạn nào đang ở Hà Nội cố gắng dành thời gian để tham dự Techtalk đầu tiên của Grokking được tổ chức offline ở thủ đô nhé.
- Thời gian: 09:00 - 12:00 Thứ 7, 26/09/2020
- Link đăng ký: http://bit.ly/grokking-techtalk-38-registration
- Địa điểm: LINE Technology Vietnam - Tầng 20, Tòa nhà TNR, 54A Nguyễn Chí Thanh, quận Đống Đa, Hà Nội
Những bài viết hay
Edgar: Solving Mysteries Faster with Observability
Một câu nói bất hủ trong lập trình "không có hệ thống nào là không có lỗi", hay nói cách khác, khi xây dựng một hệ thống phần mềm, không chỉ làm cho nó chạy là đủ mà bạn cần phải luôn sẵn sàng cho việc khắc phục lỗi.
Một khi lỗi xảy, các kỹ sư phải ngay lập tức phải trả lời cho các câu hỏi sau: lỗi là gì, xảy ra ở đâu, và tại sao xảy ra lỗi? Từ đó đưa ra giải pháp xử lý. Thông thường các kỹ sư phải đào bới trong hệ thống logs để tìm kiếm câu trả lời. Công việc này đòi hỏi bạn phải tìm rất nhiều thông tin từ logs. Nó còn trở nên rất phức tạp và tiêu tốn nhiều thời gian trong các hệ thống gồm rất nhiều services kết hợp nhau được như hệ thống phân tán.
Để giải quyết bài toán này, các kỹ sư tại NETFLIX đã phát triển một công cụ mang tên Edgar dựa trên nền tảng request tracing. Edgar giúp các kỹ sư biết được một request nào đó đã được xử lý bởi bao nhiêu services khác nhau, trong thời gian bao lâu. Nếu xảy ra lỗi ở một service nào đó, chi tiết về lỗi đó là gì. Chi tiết hơn về Edgar, mời bạn đọc thêm tại đây.
How Figma’s multiplayer technology works — www.figma.com
Figma là một ứng dụng chuyên về design/prototyping dành cho các UI Designer, nổi bật nhất với tính năng cho phép người dùng chỉnh sửa theo thời gian thực (nhiều người có thể cùng chỉnh sửa một bản design một lúc, tương tự như Google Docs).
Để xây dựng multiplayer protocol phục vụ cho việc chỉnh sửa theo thời gian thực, đội ngũ kĩ sư tại Figma đã quyết định không sử dụng thuật toán Operational Transforms (OTs) như Google Docs vì OTs vốn chỉ tối ưu hóa cho việc chỉnh sửa text theo thời gian thực, việc implement lại cực kì khó khăn. Họ quyết định tự xây dựng một protocol riêng, đơn giản và dễ phát triển hơn, cộng với việc tối ưu cho các operation trên Figma.
Bài viết chia sẻ về quá trình mà team Figma đã nghiên cứu và phát triển một multiplayer protocol từ đầu dựa trên ý tưởng của Conflict-free Replicated Data Types (vốn chỉ hay sử dụng trong các hệ thống phân tán).
What Your Identity Solution Is Missing and Common Attack Surfaces — auth0.com
Theo thống kê OWASP, lỗ hổng xác thực - Broken authentication - đứng thứ 2 trong top 10 rủi ro bảo mật cho ứng dụng web (tính tới thời điểm bài này được viết). Điều này chứng tỏ chúng ta rất mắc dễ sai lầm hoặc thiếu sót trong quá trình xây dựng hệ thống xác thực - Identity System.
Bạn tự xây dựng hệ thống xác thực hay sử dụng third party, hãy cùng nhìn lại xem bạn có bỏ qua các yếu tố nào sau đây:
Đảm bảo sự an toàn cho mật khẩu người dùng: có nhiều vấn đề cần được quan tâm như hashing algorithm, các yêu cầu cho mật khẩu như độ dài, độ phức tạp ..., hay phục hồi mật khẩu khi người dùng quên mật khẩu
Xác thực nhiều lớp (Multi-factor Authentication): những năm gần đây mật khẩu bị đánh cắp đã trở nên phổ biến, để giải quyết rủi ro này các hệ thống cần độ bảo mật cao thiết lập thêm một lớp bảo mật nữa mà chúng ta hay được biết với tên gọi multi-factor authentication (MFA)
Giải pháp cho việc mở rộng: một khi lượng người dùng đủ lớn bạn sẽ phải tính tới việc scale hệ thống để tránh khỏi tình trạng người dùng phải đợi quá lâu cho việc login, điều đó thật khó chấp nhận.
Phát hiện các bất thường: một hệ thống xác thực tốt không chỉ làm nhiệm vụ phòng thủ mà còn có tính năng đoán trước các cuộc tấn công tiềm năng như brute force attack. Các bất thường có thể bao gồm người dùng nhập mật khẩu sai nhiều lần, hay nhiều request đăng kí đến từ cùng một địa chỉ IP, v.v.
Quản lý người dùng và các thông tin chi tiết: việc quản lý tài khoản người dùng là một tính năng thiết yếu
Góc Database
Nhiều người trong chúng ta hẳn đã nghe về định lý CAP (CAP theorem), một trong các định lý phổ biến hay được dùng trong việc lựa chọn/phân tích các công nghệ phân tán hiện đại, đặc biệt là NoSQL. Nhưng định lý này bắt nguồn từ đâu?
Theo định lý CAP, một hệ thống phân tán chỉ có thể chọn được giữa hai trong ba yếu tố (C-Consistency, A-Availability, P-Partial Tolerance), trong đó sự lựa chọn giữa một trong hai yếu tố C-A được xem là một trong những tranh luận cốt lõi.
Thật ra, những cuộc tranh luận về C-A vốn dĩ đã xuất hiện trước đó giữa ACID và BASE trong đó các nhà thiết kế có phần thiên về ACID, tuy nhiên, với sự xuất hiện của càng nhiều công nghệ dữ liệu lớn, các hệ thống càng ngày càng bự với càng nhiều server cùng tham gia hệ thống thì việc đảm bảo ACID không còn là chuyện đơn giản. Từ đó, định lý CAP được nêu ra như một mô hình suy nghĩ phù hợp hơn với thời đại công nghệ và dữ liệu lớn.
Định lý CAP được tác giả Eric Brewer nêu ra trong bài báo vào năm 1999, sau đó được đề cập lần nữa vào năm 2000 trong hội thảo "the Principles of Distributed Computing" trong một bài nói của mình không kèm chứng minh.
Sau đó 2 năm, hai nhà khoa học máy tính là Seth Gilbert và Nancy Lynch đã mô hình hoá và đưa ra công thức chứng minh cho định lý này trong bài báo xuất bản năm 2002 của mình với tiêu đề “Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services” khiến định lý càng ngày càng phổ biến.
Sau 12 năm kể từ ngày định lý CAP được nêu ra ở hội nghị, chính tác giả Eric Brewer đã chia sẻ những suy nghĩ của mình khi nhìn lại định lý này, gồm cả những điểm phù hợp, những điểm mà cộng đồng còn ngộ nhận, ... Mời các bạn cùng đọc bài báo của tác giả Eric Brewer: link
Code & Tools
Sponsor
We’ve built an engineering and AI powerhouse in bustling southern Vietnam, where we tackle AI’s biggest challenges in the public safety space. With cameras that depict truth, automated reporting and evidence management that will triple the amount of time officers can spend serving their communities, and Smart Weapons that protect life in the moment of conflict, Axon has revolutionized the world of public safety - and by working here, you can contribute every day to the mission to protect life.
Opening Jobs:
Quotes
Make it work, make it right, make it fast.
— Kent Beck