#164 - Tại sao xác thực thông qua SMS vẫn được sử dụng?
Những bài viết hay
How GitHub Actions renders large-scale logs
Render log trên Web UI thoạt đầu nghe qua có vẻ đơn giản: chỉ việc in ra những dòng plain text log. Tuy nhiên, có rất nhiều tính năng bổ sung cần thiết để làm cho chúng tiện dụng hơn cho người dùng: coloring, grouping, search, permanent link,... nhưng quan trọng nhất là việc render sẽ cần phải được đảm bảo là sẽ hoạt động mượt mà ngay cả khi dữ liệu có tới hàng chục nghìn dòng log. Trình duyệt rất dễ bị crash trong lần load đầu nếu việc render một lượng lớn log không được thiết kế đúng cách.
Các kĩ sư ở Github đã đối mặt với các thử thách trên trong quá trình xây dựng Github Actions, và họ đã sử dụng một kĩ thuật gọi là "virtualization": chỉ render một lượng dữ liệu nhỏ đủ để vừa với màn hình của user, sau đó tính toán vị trí layout và dựa theo việc user scroll để trigger việc cập nhật thêm dữ liệu.
Thiết kế Data Warehouse hiệu quả — lewisdgavin.medium.com
Những năm gần đây, việc thu thập và lưu trữ dữ liệu đã có nhiều sự thay đổi và phát triển nhờ sự ra đời và tiếp quản của các công nghệ NoSQL, “Big Data”, Graphing và Streaming. Tuy nhiên, một số nguyên tắc cơ bản vẫn tồn tại và hữu ích trong quá trình thiết kế Data Warehouse.
Trong bài viết, tác giả đề cập đề cập chi tiết đến 3 bước của quá trình này, bao gồm: Staging, Master và Reporting
Trước khi đến với 3 bước kể trên, chúng ta cần có thao tác pre-processing. Để đối phó với sự phức tạp của dữ liệu bên ngoài, một số quá trình thao tác tiền xử lý là hầu như không thể tránh khỏi, đặc biệt là khi thu thập từ một số nguồn khác nhau. Mục tiêu chính của bước tiền xử lý là đưa dữ liệu vào một định dạng nhất quán để kho dữ liệu có thể tải được.
Staging: Một data warehouse thường lấy dữ liệu từ nhiều nguồn khác nhau. Mỗi nguồn dữ liệu đi kèm với các sắc thái, phong cách và quy ước đặt tên riêng. Staging area là nơi đưa tất cả dữ liệu đầu vào sau giai đoạn pre-processing và lưu trữ nó tạm thời cho đến khi nó được xử lý tiếp. Lời khuyên của tác giả là dữ liệu lưu trữ tại đây nên gần với dữ liệu raw ban đầu nhất có thể và giữ lại dữ liệu trong một khoảng thời gian đã chọn nhất định.
Master: Đây là nơi dữ liệu được định hình cấu trúc và schema mọi cách rõ ràng. Các bảng cần được mô hình hóa chính xác, được đặt tên thích hợp. Tên cột cũng nên được sửa cùng với kiểu dữ liệu của chúng. Một vài yếu tố cần được tiêu chuẩn hoá khi xử lý dữ liệu từ Stage vào Master như format ngày tháng, địa chỉ, quy ước làm tròn số thập phân, làm sạch các String, ...
Reporting: Các công việc cơ bản đã được thực hiện sau khi chuẩn bị, thu nhập, lập mô hình và làm sạch dữ liệu. Reporting là nơi chúng ta sử dụng dữ liệu nhằm phục vụ các mục đích khác nhau trong business. Ở bước này, chúng ta có thể mô hình hoá các bảng theo row-based hoặc columnar-based để phù hợp với các query khác nhau.
Tại sao xác thực thông qua SMS vẫn được sử dụng — www.twilio.com
Xác thực người dùng thông qua tin nhắn SMS (OTP - One Time Password) đã phổ biến từ lâu. Tuy nhiên, thực tế đã có nhiều vụ án Đánh cắp tiền trong tài khoản ngân hàng qua khai thác điểm yếu của OTP đã xảy ra. Thông qua lỗ hổng của xác thực qua tin nhắn, attacker có thể sử dụng thủ thuật SIM SWAPPING (In SIM card swap scam, thieves steal your identity by hacking your phone) - giả danh người dùng để nhận OTP code.
Mặc dù SMS OTP có những lo ngại bảo mật chính đáng, tại sao SMS vẫn được sử dụng phổ biến bất chấp các rủi ro mà nó mang lại?
Sử dụng mật khẩu tệ. Chúng ta dùng mật khẩu như là một tiêu chuẩn để tiến hành xác thực người dùng từ khi có internet, tuy nhiên con người ta thường hay quên, do đó có xu hướng sử dụng mật khẩu ngắn, dễ nhớ. Chính vì vậy, các công ty công nghệ bắt đầu giới thiệu các biện pháp an ninh bổ sung khác và SMS-OTP là một trong các giải pháp đó.
Hầu hết mọi người đều có thể nhận tin nhắn do đó sử dụng SMS để gửi OTP đến người dùng được xem là một giải pháp khả dụng và tiện lợi nhất.
Xác thực 2 yếu tố (2FA - two factor-authentication) thông qua SMS vẫn đáp ứng tốt cho các doanh nghiệp chú trọng sự tiện lợi hơn là bảo mật tốt.
Mặc dù giải pháp Authenticator App (Google Authenticator, Authy, Google Authenticator) cung cấp tính năng bảo mật an toàn hơn, thật không may phần lớn người dùng sẽ không dành thời gian để tải các ứng dụng này nếu không bắt buộc bởi công ty hay ứng dụng.
NIST (The National Institute of Standards and Technology) vẫn chấp nhận SMS 2FA như là một giải pháp nâng cao bảo mật hơn là mật khẩu.
Góc Database
Halloween Problem
System R là một trong những hệ thống cơ sở dữ liệu sớm nhất được xây dựng như một dự án nghiên cứu tại phòng thí nghiệm của IBM vào đầu những năm 1970. Với System R, lần đầu tiên SQL được triển khai và từ đó trở thành ngôn ngữ truy vấn dữ liệu quan hệ tiêu chuẩn như chúng ta đã thấy ngày nay.
Vào năm 1976, khi các kỹ sư của IBM đang thử nghiệm một số lý thuyết để xây dựng bộ query optimizer cho SQL thì vô tình phát hiện ra một vấn đề khá thú vị. Vấn đề được mô tả lại như sau.
Cho trước bảng dữ liệu:
Truy vấn sau sẽ thực hiện việc tăng lương 10% cho tất cả nhân viên mà có lương < $25000.
Các kỹ sư của IBM kỳ vọng kết quả sẽ như bên dưới:
Tuy nhiên, thực tế cuối cùng thu được là tất cả nhân viên đều được nâng lương lên mức ≥ $25000. Tại sao lại như vậy?
Quá trình UPDATE xảy ra qua 3 giai đoạn: (1) tìm kiếm bản ghi phù hợp với điều kiện trong WHERE; (2) tính toán giá trị mới cho trường dữ liệu cần cập nhật; (3) ghi giá trị mới vào database, đồng thời cập nhật index liên quan. Quá trình này thực hiện tuần tự cho từng bản ghi và lặp lại tới khi không còn bản ghi nào thỏa mãn điều kiện WHERE được tìm thấy.
Hãy chú ý tới index idx_salary, có dạng cấu trúc B-Tree, giúp tăng tốc tìm kiếm bản ghi ở giai đoạn (1). Việc tìm kiếm sẽ duyệt từ bên trái của cây index, các bản ghi có salary nhỏ nhất sẽ được xử lý trước (cụ thể, bản ghi với id=1). Khi đến giai đoạn (3), do giá trị salary đã thay đổi (10000 → 11000) nên vị trí của bản ghi trong index cũng thay đổi theo (di chuyển về bên phải của cây index, nằm phía sau vị trí của bản ghi có id=2). Sau đó, khi xử lý xong quá trình UPDATE cho bản ghi id=2, bản ghi id=1 sẽ lại được UPDATE thêm lần nữa. Quá trình này lặp đi lặp lại khiến giá trị salary của 2 bản ghi được cập nhật nhiều lần cho tới khi giá trị của chúng ≥ $25000 thì dừng.
Trong thực tế, vấn đề này có thể có nhiều cách để xử lý, ví dụ như thay vì cập nhật index sau mỗi lần cập nhật từng bản ghi thì chỉ thực hiện cập nhật index sau khi toàn bộ bản ghi được tính toán và ghi vào database.
Tuy không phản ánh nội dung liên quan, nhưng vì được phát hiện đúng dịp lễ Halloween nên Halloween Problem trở thành cái tên chính thức được đặt cho vấn đề này.
Bạn đọc có thể tìm hiểu thêm về vấn đề này tại đây và tham khảo loạt bài viết ở đây để rõ hơn về cách mà Microrsoft SQL Server xử lý Halloween Problem.
Code & Tools
This Week Sponsors
Remitano là một trong các sàn giao dịch P2P năng động tại nhiều quốc gia, Remitano cung cấp thị trường uy tín, an toàn tối đa và đơn giản cho hoạt động mua bán tiền mã hóa của hàng triệu khách hàng, với sản phẩm đầu tư đa dạng, giao dịch tức thời và đội ngũ hỗ trợ 24/7 bao gồm các chuyên gia ngân hàng có nhiều kinh nghiệm trong các sản phẩm tài chính, tiền điện tử, và hệ thống thanh toán, đảm bảo mang đến trải nghiệm tốt với mức phí thấp nhất cho người dùng.
Quotes
Theory is when you know something, but it doesn’t work. Practice is when something works, but you don’t know why. Programmers combine theory and practice: Nothing works and they don’t know why."
- Unknown