Website được tạo ra là để phục vụ người dùng. Có người sử dụng thì website và doanh nghiệp mới có thu nhập. Một trong những việc rắc rối nhất chính là quản lý và bảo mật thông tin người dùng.

Trong bài này, mình chia sẻ những điều cần lưu ý khi thực hiện tính năng này. Khá nhiều khê và phức tạp đấy, các bạn chịu khó đọc kĩ nhé!

Úi giời! Đăng kí đăng nhập có gì khó?

Không như bạn tưởng tượng, việc đăng kí/đăng nhập và quản lý người dùng thật ra không hề đơn giản. Nó có thể trở nên khá loằng ngoằng với những tính năng sau:

• Cho phép người dùng đăng kí, đăng nhập bằng email
• Phân quyền người dùng
• Tích hợp với Gmail, Facebook
• Tích hợp với hệ thống người dùng có sẵn trong doanh nghiệp
• Reset mật khẩu khi người dùng quên
• Block account khi người dùng nhập sai pass nhiều lần
• Bảo mật cho API với app di động
• Bảo mật 2 lớp (Two factor authentication) với các account quan trọng
• Quản lý: Thêm bớt xoá sửa người dùng

Khi tính năng này hoạt động ổn định, không ai khen nó lấy một câu. Tuy nhiên, chỉ cần nó gặp phải chút vấn đề, cam đoan bạn sẽ hứng chịu vô số cơn thịnh nộ từ khách hàng.

Quan trọng nhất – Không lưu mật khẩu!

Developer phải thuộc nằm lòng câu nói sau

Tuyệt đối không bao giờ lưu mật khẩu khách hàng, dù sếp có nói gì đi nữa!

Là một developer có tâm, bạn không bao giờ được lưu mật khẩu của khách hàng vào database (nhắc lại lần thứ ba cho nhớ).

Đến cả web lớn là vietnamwork mà cũng tắc trách đến mức không dùng https khi đăng nhập, không bảo mật dữ liệu đến nỗi làm lộ mật khẩu của người dùng: http://nghenhinvietnam.vn/tin-tuc/web-tim-viec-vietnamwork-bi-tan-cong-23535.html.

Hậu quả của việc này cũng không có gì nghiêm trọng, cùng lắm là mất mặt công ty, mất account khách hàng và làm khách hàng chuyển qua dùng dịch vụ khác thôi.

Nếu không lưu mật khẩu, làm sao người dùng có thể login? Mình đã đề cập tới phương pháp giải quyết trong bài Lỗ hổng bảo mật của Lotte Cinema, các bạn chịu khó đọc lại nhé.

Làm thế nào khi người dùng quên mật khẩu?

Do không lưu mật khẩu trong database, ta không thể gửi mật khẩu về mail cho người dùng khi họ quên mật khẩu. Ở đây ta có 2 cách giải quyết.

Cách 1: Reset mật khẩu mới ngẫu nhiên rồi gửi cho người dùng

Cách này có thể làm lộ mật khẩu vì email có thể bị đọc trộm. Ngoài ra, nếu như biết địa chỉ mail, hacker có thể lợi dụng nó để reset mật khẩu hàng loạt người dùng, nhằm ngăn cản họ đăng nhập vào hệ thống.

Cách 2: Gửi link để người dùng reset

Dựa theo tài khoản, ta tạo reset token rồi gắn nó vào link: http://shop.com/resetpass?token=32343, gửi link này vào mail cho người dùng.

Người dùng sử dụng link này để reset mật khẩu. Với cách này, dù hacker có request reset thì mật khẩu người dùng vẫn giữ nguyên, không bị ảnh hưởng.

Như đã nói phía trên, do email không an toàn nên token này nên được expired ngay sau khi dùng, hoặc sau 24-48 tiếng đồng hồ sau khi email được gửi đi.

Chống việc đoán mò mật khẩu

Để dò mật khẩu, hacker có thể viết một con bot, lần lượt submit username và password cho tới khi đăng nhập được. Để phòng tránh việc này, ta áp dụng những phương pháp sau:

• Khi người dùng đăng nhập sai, đừng báo là sai username hay sai password. Chỉ cần báo username hay password không match, hacker sẽ gặp khó khăn hơn.
• Hacker lợi dụng chức năng reset mật khẩu để dò xem người dùng có email trên trang đó hay không. Dù account có tồn tại hay không, ta vẫn chỉ hiện thông báo: đã gửi message.
• Hạn chế số lần đăng nhập khi nhập mật khẩu sai. Ví dụ sau 3 lần nhập pass sai thì khoá account trong 10 phút. Hacker có thể dùng cách này để khoá tài khoản người dùng, nên cẩn thận. Có thể kết hợp thêm capcha.

Lưu ý: Những cách cách này có thể gây khó chịu cho người dùng, nếu dữ liệu không quá quan trọng (game, web hỏi đáp, giao lưu, giải trí …) thì có thể nới lỏng một số yếu tố.

Biện pháp nho nhỏ tăng cường bảo mật

Một số điểm cần lưu ý khác:

• Với các thao tác quan trọng như đổi email, đổi pass, xoá nick, cần bắt người dùng nhập lại password. Lý do là đôi khi người dùng bị chôm cookie, hoặc lơ là quên khoá máy. Hãy nhìn Facebook và Google, cả 2 trang này đều bắt ta phải nhập lại mật khẩu khi muốn đổi pass.
• Với các ứng dụng cần bảo mật cao, phải có Two-factor verification (Gửi tin nhắn, device tạo authentication token).Mình hiện tại cũng đang dùng nó, dù các bạn có biết mật khẩu Gmail hay WordPress của mình cũng “éo” thể nào đăng nhập được.
• Nên khuyến khích (hoặc bắt buôc) người dùng sử dụng mật khẩu dài, đi kèm chữ và số, viết hoa viết thường và kí tự đặc biệt. Máy móc rất hiện đại khi crack mật khẩu, có thể vào đây để test xem máy mất bao lâu để mò ra mật khẩu của bạn.
• Nếu site của bạn không có HTTPS, hoặc team không có kinh nghiệm làm bảo mật, cứ để cho bọn khác lo. Bạn có thể dùng OAuth, cho phép người dùng đăng nhập từ Google, Facebook.
• Lúc này Google, Facebook sẽ chịu trách nhiệm quản lý mật khẩu và dữ liệu của người dùng. Người dùng thì không cần phải đăng kí nhiều tài khoản, một công đôi việc. Tìm hiểu thêm tại https://oauth.io/ hoặc https://auth0.com/.

Thay lời kết

Đây cũng là bài viết cuối cùng của series “Bảo mật nhập môn”. Chân thành cảm ơn các bạn đã theo dõi và đồng hành cùng blog trong suốt thời gian qua!

Mình chỉ có một hi vọng “nhỏ nhoi” là series này được nhiều người biết tới hơn. Nếu lập trình viên nào cũng biết những lỗi bảo mật cơ bản thế này, ta sẽ không phải gặp những lỗ hổng “ngớ ngẩn” kiểu lottecinema hay vietnamwork nữa.

Hãy nhớ rằng, bảo mật là một chuyên ngành rất lớn, thế giới bảo mật rất bao la. Những lỗi bảo mật mới xuất hiện từng ngày, không thua gì công nghệ mới trong lập trình.

Series “nhập môn” này chỉ cover được một phần rất nhỏ trong đấy (Còn vô số điều hay ho như: social engineering, row hammering … không được nhắc tới trong series).

Do vậy, đừng nghĩ rằng đọc xong series là mình đã biết “tuốt tuồn tuột” những điều cần biết về bảo mật. Hãy tự trau dồi thêm kiến thức bảo mật, áp dụng vào code và thiết kế nhé.