Vì sao xác minh email quan trọng hơn bạn tưởng

Hãy bắt đầu với chữ "vì sao" — bởi hiểu mục đích của việc xác minh email thay đổi mức độ cẩn thận bạn dành cho việc xây dựng nó. Lý do đầu tiên là tính chính xác cơ bản: nó xác nhận rằng người dùng thực sự kiểm soát địa chỉ họ đã cung cấp. Lỗi gõ trong trường email cực kỳ phổ biến. Một người dùng gõ [email protected] thay vì [email protected] sẽ không bao giờ nhận được email của bạn, và nếu không có xác minh, bạn sẽ không bao giờ biết cho đến khi họ gửi một yêu cầu hỗ trợ nhiều tuần sau. Bắt lỗi địa chỉ sai ngay tại thời điểm đăng ký rẻ hơn nhiều so với việc truy tìm chúng sau này.

Lý do thứ hai là ngăn chặn gian lận. Các bot tạo tài khoản tự động thường dùng địa chỉ dùng một lần hoặc bịa đặt vì con người sẽ không thực sự kiểm tra những hộp thư đó. Một tài khoản chưa xác minh là một gánh nặng — nó chiếm tài nguyên, thổi phồng số lượng người dùng của bạn bằng dữ liệu rác, và có thể bị dùng để lạm dụng những tính năng không đòi hỏi tương tác qua email. Yêu cầu xác minh email nâng chi phí tạo tài khoản hàng loạt lên đủ để răn đe phần lớn hành vi lạm dụng thông thường.

Lý do thứ ba là điều mà các nhà phát triển thường đánh giá thấp nhất: một địa chỉ email đã xác minh là điều kiện tiên quyết về bảo mật cho việc đặt lại mật khẩu. Hãy nghĩ kỹ. Nếu bạn cho phép đặt lại mật khẩu tới bất kỳ địa chỉ nào mà không trước tiên xác minh địa chỉ đó thuộc về chủ tài khoản, kẻ tấn công có thể đăng ký bằng email của người khác, không bao giờ xác minh nó, và vẫn kích hoạt được luồng đặt lại mật khẩu. Email đặt lại đi đến chủ sở hữu thật của địa chỉ đó — điều này để lộ rằng một tài khoản đã được tạo dưới tên họ mà họ không hề hay biết. Đó tối thiểu là một rò rỉ quyền riêng tư, và có khả năng là một vectơ cho việc lạm dụng thêm nữa. OWASP Authentication Cheat Sheet đề cập đến điều này và nhiều hơn nữa — đó là tài liệu bắt buộc phải đọc với bất kỳ ai xây dựng luồng xác thực.

Và cuối cùng, có câu hỏi thực tế về việc gửi: nếu bạn gửi email tới người dùng — thông báo, biên nhận, cập nhật — bạn cần biết những địa chỉ đó là thật và có thể tiếp cận được. Gửi tới các địa chỉ không hợp lệ làm tăng tỷ lệ trả lại (bounce rate) của bạn, gây hại cho uy tín người gửi của bạn, nghĩa là email tương lai của bạn sẽ rơi vào spam đối với mọi người trong danh sách của bạn. Xác minh là nền tảng khiến toàn bộ chương trình email của bạn hoạt động đáng tin cậy theo thời gian.

Luồng xác minh đầy đủ, từng bước một

Hãy đi qua từng bước của một hệ thống xác minh được xây dựng đúng đắn. Khái niệm thì đơn giản; giá trị nằm ở việc làm mỗi bước cho đúng. Bản thân email tuân theo một giao thức truyền tải được định nghĩa rõ ràng — RFC 5321 định nghĩa SMTP một cách chi tiết nếu bạn cần hiểu điều gì đang diễn ra ở lớp truyền tải — nhưng các quyết định ở lớp ứng dụng hoàn toàn thuộc về bạn, và chúng quan trọng vô cùng.

1. Người dùng gửi biểu mẫu đăng ký. Chấp nhận địa chỉ email của họ. Thực hiện xác thực định dạng cơ bản ở phía máy chủ — không chỉ ở phía máy khách. RFC 5321 thực ra dễ dãi hơn hầu hết các mẫu regex mà mọi người dùng, vì vậy đừng từ chối các địa chỉ hợp lệ bằng một mẫu quá nghiêm ngặt.
2. Tạo một token ngẫu nhiên về mặt mật mã học. Đây không phải là UUID, không phải ID tuần tự, không phải dấu thời gian. Nó phải đến từ một nguồn ngẫu nhiên mật mã với ít nhất 32 byte entropy. Chi tiết hơn về điều này ở phần tiếp theo.
3. Lưu hash của token (không phải token thô) vào cơ sở dữ liệu của bạn. Lưu hash SHA-256 của token, ID người dùng mà nó thuộc về, dấu thời gian tạo, dấu thời gian hết hạn, và một cờ boolean "đã dùng".
4. Gửi email xác minh. Liên kết chứa token thô như một tham số truy vấn: https://yourapp.com/verify?token=abc123.... Luôn dùng HTTPS. Không bao giờ HTTP.
5. Người dùng nhấp vào liên kết. Máy chủ của bạn nhận một yêu cầu GET với token thô trong chuỗi truy vấn.
6. Tra cứu và xác thực token. Băm token đến, tìm bản ghi khớp trong cơ sở dữ liệu. Kiểm tra nó tồn tại. Kiểm tra nó chưa hết hạn. Kiểm tra cờ "đã dùng" là false.
7. Khi thành công: đánh dấu địa chỉ email là đã xác minh trên bản ghi người dùng, đặt cờ "đã dùng" của token thành true (hoặc xóa hẳn hàng token), rồi đăng nhập người dùng hoặc chuyển hướng đến trang đăng nhập với một thông báo thành công rõ ràng.
8. Khi thất bại: hiển thị một lỗi cụ thể, có thể hành động, giải thích điều gì đã sai — đã hết hạn, đã được dùng, hoặc không tìm thấy — với một lối đi rõ ràng để yêu cầu một email xác minh mới.

Mỗi bước đều quan trọng. Những lối tắt phổ biến nhất — bỏ qua xác thực phía máy chủ, dùng token yếu, không băm trước khi lưu trữ, bỏ đi cờ "đã dùng" — mỗi cái đều đưa vào một lớp tấn công hoặc thất bại về trải nghiệm người dùng. Làm mỗi bước cho đúng và bạn có một hệ thống xác minh thực sự trụ vững trong sản xuất.

Tạo token an toàn — theo cách đúng đắn

Đây là nơi một số lượng đáng ngạc nhiên các triển khai đi sai. Lỗi phổ biến nhất tôi thấy là dùng UUID v4 làm token xác minh. UUID tốt cho các định danh cơ sở dữ liệu — chúng độc nhất, chống va chạm — nhưng chúng không phải là token bảo mật được thiết kế riêng cho mục đích đó. Một UUID v4 cho bạn 122 bit ngẫu nhiên ở một định dạng nổi tiếng, dễ nhận biết. Điều đó có lẽ ổn trong thực tế, nhưng bạn có thể làm tốt hơn với gần như không tốn thêm công sức, và không có lý do chính đáng nào để không làm.

Cách tiếp cận đúng là dùng bộ tạo số ngẫu nhiên mật mã của ngôn ngữ hoặc runtime của bạn. Trong Node.js: crypto.randomBytes(32).toString('hex') — điều này cho bạn 64 ký tự hex biểu diễn 256 bit entropy. Trong Python: secrets.token_urlsafe(32) — mô-đun secrets được thiết kế đặc biệt để tạo token mật mã và là công cụ đúng cho công việc này. Trong .NET: RandomNumberGenerator.GetBytes(32) từ System.Security.Cryptography. Trong Go: crypto/rand.Read(). OWASP Authentication Cheat Sheet khuyến nghị ít nhất 32 byte (256 bit) entropy cho token xác minh. Ở mức đó, việc dò tìm token bằng vét cạn là bất khả thi về mặt tính toán — ngay cả với một kẻ tấn công dồi dào tài nguyên có quyền truy cập trực tiếp vào cơ sở dữ liệu để thấy có bao nhiêu token đang lưu hành.

Giờ đến câu hỏi lưu trữ: bạn nên lưu token thô hay một hash của nó? Riêng với token xác minh email, mô hình mối đe dọa là kẻ tấn công có được quyền truy cập chỉ-đọc vào cơ sở dữ liệu của bạn — qua SQL injection, một bản sao lưu bị rò rỉ, hoặc một thông tin đăng nhập cơ sở dữ liệu bị xâm phạm. Nếu bạn lưu token thô, họ có thể đọc giá trị token và tạo một URL xác minh hợp lệ cho bất kỳ tài khoản chưa xác minh nào. Nếu bạn lưu một hash SHA-256 của token, việc đọc cơ sở dữ liệu không để lộ gì có thể dùng được. Mẫu hình là: lưu SHA256(token) trong cơ sở dữ liệu, gửi token thô trong liên kết email. Khi xác thực, băm token đến và so sánh với các hash đã lưu. Đó là một bước nhỏ bổ sung cải thiện đáng kể tư thế bảo mật của bạn với chi phí hiệu năng không đáng kể.

Một chi tiết nữa đáng lưu ý: hãy đảm bảo việc so sánh token của bạn là thời gian-hằng (constant-time). Dùng một phép kiểm tra bằng chuỗi ngây thơ khi so sánh các token đã băm cho phép các cuộc tấn công thời gian (timing attack) — kẻ tấn công có thể đo thời gian phản hồi để suy ra bao nhiêu ký tự trong phỏng đoán của họ đã khớp. Hầu hết các ngôn ngữ đều cung cấp hàm so sánh thời gian-hằng: hmac.compare_digest() trong Python, crypto.timingSafeEqual() trong Node.js. Hãy dùng chúng.

Thời hạn của token — làm đúng các chi tiết

Hai mươi bốn đến bốn mươi tám giờ là tiêu chuẩn cho thời hạn token xác minh, và đó là một tiêu chuẩn tốt cho hầu hết các ứng dụng. Đủ dài để một người dùng đăng ký lúc đêm khuya có thể kiểm tra email vào sáng hôm sau mà không gặp trở ngại nào. Đủ ngắn để một token bị đánh cắp hoặc rò rỉ chỉ có một cửa sổ hữu dụng hạn chế. Một số ứng dụng dùng 72 giờ để giảm trở ngại khi onboarding — điều đó hợp lý cho các ứng dụng B2C nơi việc bỏ dở đăng ký là mối lo thực sự. Một số ứng dụng bảo mật cao chỉ dùng một giờ. Hãy chọn dựa trên ngữ cảnh người dùng và mức độ chấp nhận rủi ro của bạn.

Dù bạn chọn gì, hãy nói rõ điều đó ngay trong email. "Liên kết xác minh này hết hạn sau 24 giờ." Những người kiểm tra email ngay lập tức có thể không để ý, nhưng những người lưu email và quay lại sau sẽ để ý. Đặt kỳ vọng đó trong phần thân email tiết kiệm được các yêu cầu hỗ trợ. Và khi một token thực sự hết hạn, thông báo lỗi của bạn cần cụ thể và có thể hành động — không phải "token không hợp lệ" (điều này chẳng nói cho người dùng biết gì về việc gì đã sai) mà "Liên kết xác minh này đã hết hạn. Nhấp vào đây để yêu cầu một liên kết mới." Lối gửi lại rõ ràng đó là thiết yếu.

Cũng xử lý trạng thái "đã xác minh" một cách rõ ràng. Nếu một người dùng nhấp vào liên kết xác minh họ đã dùng, đừng hiển thị một lỗi chung chung — hãy hiển thị một thông báo thành công hoặc chuyển hướng họ thẳng vào ứng dụng. Họ có thể đã nhấp đúp, hoặc họ có thể đã mở lại email vì thực sự không chắc mình đã hoàn thành bước đó chưa. UX đúng đắn là cho họ vào một cách suôn sẻ, chứ không phải trình bày một lỗi khó hiểu khiến họ băn khoăn liệu tài khoản của mình có thực sự được thiết lập hay không.

Cũng hãy cân nhắc điều gì xảy ra với những tài khoản chưa xác minh và cũ. Nếu ai đó đăng ký, không bao giờ xác minh, và bỏ dở quá trình — điều gì xảy ra với bản ghi đó? Để nó vô thời hạn tiêu tốn dung lượng lưu trữ và có thể chặn chính địa chỉ email đó đăng ký lại. Một tác vụ dọn dẹp gỡ bỏ các tài khoản chưa xác minh đang chờ sau bảy ngày (kèm một email thông báo vào ngày thứ sáu) là một giải pháp gọn gàng cân bằng giữa UX và vệ sinh dữ liệu.

Viết chính email xác minh

Email xác minh thường là thứ đầu tiên một người dùng mới nhận được từ dịch vụ của bạn. Nó không cần phải cầu kỳ — thực ra, đơn giản và rõ ràng tốt hơn đáng kể so với phức tạp và nặng thương hiệu. Dòng chủ đề: "Vui lòng xác minh địa chỉ email của bạn" hoặc "Xác nhận địa chỉ email của bạn cho [App]" — trực tiếp, không mơ hồ. Không phải "Chào mừng đến với [App]!" (đó là email chào mừng sau khi xác minh). Không phải "Yêu cầu hành động!!!" (mồi cho bộ lọc spam, và người dùng đã được huấn luyện để nghi ngờ ngôn ngữ khẩn cấp hung hăng trong dòng chủ đề email).

Cấu trúc phần thân: hai hoặc ba câu ngữ cảnh ("Bạn vừa tạo một tài khoản tại [App]. Nhấp vào nút bên dưới để xác minh địa chỉ email của bạn và hoàn tất đăng ký."), một nút kêu gọi hành động lớn, được gắn nhãn rõ ràng ("Xác minh địa chỉ email"), và URL thô được in bên dưới nó như một phương án dự phòng cho những người dùng có ứng dụng email không hiển thị HTML hoặc phần mềm bảo mật loại bỏ nút. Điểm cuối này quan trọng hơn hầu hết các nhà phát triển nhận ra — môi trường email doanh nghiệp thường xuyên loại bỏ các phần tử có thể nhấp, và người dùng doanh nghiệp sẽ sao chép và dán URL thô nếu nó có sẵn.

Một phiên bản văn bản thuần túy không phải là tùy chọn. Luôn kèm theo nó. Một số hệ thống email doanh nghiệp loại bỏ HTML, và các bộ lọc spam nhìn email chỉ-HTML với sự nghi ngờ. Phiên bản văn bản thuần túy chỉ cần URL xác minh trên dòng riêng của nó — nó không cần đẹp. Ngoài ra: đừng dùng công cụ rút gọn URL trong email xác minh. Các máy chủ thư nhận đánh dấu các liên kết rút gọn là các vectơ lừa đảo tiềm năng, và người dùng (một cách đúng đắn) được huấn luyện để nghi ngờ việc nhấp vào các URL rút gọn trong những email họ không yêu cầu rõ ràng.

Cấu hình người gửi cũng rất quan trọng. Tên "from" của bạn nên là thương hiệu hoặc tên ứng dụng của bạn — không phải một địa chỉ email thô. Địa chỉ reply-to của bạn nên dẫn đến đội hỗ trợ của bạn hoặc một hộp thư được theo dõi. Tránh no-reply@... cho cả from và reply-to — nó truyền đạt rằng bạn không muốn nghe từ người dùng, và một số ứng dụng email sẽ cảnh báo người nhận về các địa chỉ no-reply. Cũng hãy kèm địa chỉ thư tín vật lý của bạn ở chân trang nếu bạn thuộc diện điều chỉnh bởi các quy định tiếp thị email CAN-SPAM hoặc GDPR — điều đó được yêu cầu về mặt pháp lý ở một số khu vực tài phán ngay cả với email giao dịch.

Kiểm thử luồng xác minh của bạn cho đúng cách

Đây là nơi nhiều nhà phát triển đi một lối tắt khiến họ phải trả giá sau này. Cách tiếp cận điển hình là: gửi email xác minh tới địa chỉ của chính bạn, xác nhận nó đến, nhấp liên kết một lần — xong. Điều đó chỉ bao quát riêng con đường thuận lợi (happy path). Nó không bao quát bất kỳ chế độ thất bại nào mà người dùng thật sẽ thực sự gặp phải, và nó không kiểm thử gì về cách email của bạn hành xử bên ngoài hộp thư của chính bạn, thứ thường có lọc spam thoải mái và có thể không phản ánh chính xác điều xảy ra ở Gmail, Outlook, hay Yahoo.

Mọi thay đổi đối với luồng xác minh của bạn nên được kiểm thử bằng một email thật tới một hộp thư thật. Mở một địa chỉ email tạm thời, sao chép nó vào biểu mẫu đăng ký của bạn, đăng ký một tài khoản thử nghiệm, và xem email xác minh đến theo thời gian thực. Điều này cho bạn xác nhận dứt khoát rằng email của bạn thực sự đang được gửi đi — không chỉ được xếp hàng, không chỉ được API của nhà cung cấp gửi thư chấp nhận, mà được gửi đến một hộp thư. Nó cũng cho phép bạn kiểm tra xem nó đến hộp thư chính hay đến spam, điều mà các unit test và nhật ký gọi API không bao giờ có thể cho bạn biết.

Ngoài con đường thuận lợi, đây là những kịch bản cụ thể bạn nên kiểm thử trước khi phát hành bất kỳ thay đổi nào cho luồng xác minh của bạn:

• Con đường thuận lợi: đăng ký với một địa chỉ mới, nhận email trong vài giây, nhấp liên kết, xác nhận tài khoản được đánh dấu là đã xác minh và bạn có thể đăng nhập
• Token hết hạn: tự tay đặt dấu thời gian hết hạn của token về quá khứ trong cơ sở dữ liệu của bạn (hoặc tạm thời hạ cửa sổ hết hạn của bạn trong cấu hình), rồi nhấp liên kết — xác nhận thông báo lỗi rõ ràng, cụ thể, và có kèm một liên kết gửi lại hoạt động
• Token đã dùng: hoàn tất xác minh thành công, rồi nhấp cùng liên kết đó lần thứ hai — xác nhận bạn thấy một thông báo "đã xác minh" suôn sẻ hoặc được chuyển hướng đến ứng dụng, không phải một lỗi khó hiểu
• Token bị giả mạo: sửa đổi giá trị token trong URL (đổi vài ký tự) — xác nhận bạn thấy một lỗi "liên kết không hợp lệ" rõ ràng chứ không phải một sự cố sập máy chủ hay stack trace
• Token không tồn tại: dựng một URL với một token hoàn toàn bịa đặt — xác nhận nó trả về một lỗi "không tìm thấy" phù hợp và ghi nhật ký một cách thích đáng
• Luồng gửi lại: yêu cầu một email xác minh mới, xác nhận email mới đến với một liên kết mới hoạt động, xác nhận liên kết cũ không còn hoạt động (token cũ nên bị vô hiệu hóa khi một token mới được cấp)
• Phân biệt hoa thường: nếu các token của bạn là hex hoặc base64, hãy kiểm thử xem việc xác thực của bạn có xử lý đầu vào hoa thường lẫn lộn một cách suôn sẻ không — một số ứng dụng email thay đổi hoa thường của URL

Một hộp thư email tạm thời làm cho việc kiểm thử này nhanh chóng vì bạn có thể tạo một địa chỉ mới cho mỗi kịch bản mà không cần một tập hợp các tài khoản thử nghiệm ở một nhà cung cấp email thật. Bạn cũng có thể kiểm tra các tiêu đề email thô trực tiếp trong hộp thư để kiểm tra trạng thái đạt/không đạt của SPF và DKIM — cực kỳ hữu ích để chẩn đoán các vấn đề gửi thư trước khi chúng trở thành vấn đề sản xuất.

Xác thực email: SPF, DKIM, và DMARC

Email xác minh của bạn chỉ hữu ích nếu nó thực sự đến hộp thư. Nhiều nhà phát triển viết logic xác minh hoàn hảo rồi phát hiện email của họ đi thẳng vào spam vì họ chưa cấu hình xác thực email. Đây là một bước cấu hình ở mức DNS, không phải ở mức ứng dụng — nhưng đó hoàn toàn là trách nhiệm của bạn với tư cách là nhà phát triển triển khai hệ thống.

SPF (Sender Policy Framework) là một bản ghi DNS TXT ủy quyền cho các máy chủ thư cụ thể gửi email thay mặt cho miền của bạn. Khi Gmail nhận một email từ [email protected], nó tra cứu bản ghi SPF của bạn và kiểm tra xem địa chỉ IP của máy chủ gửi có nằm trong danh sách được phê duyệt không. Không có SPF, email trông đáng ngờ theo mặc định. Ví dụ bản ghi: v=spf1 include:sendgrid.net ~all nếu bạn dùng SendGrid làm nhà cung cấp gửi thư của bạn. Tài liệu của mỗi nhà cung cấp chỉ rõ giá trị include SPF chính xác cần dùng.

DKIM (DomainKeys Identified Mail) thêm một chữ ký mật mã vào mỗi email đi ra, chứng minh nó đến từ miền của bạn và không bị sửa đổi khi truyền đi. Nhà cung cấp gửi thư của bạn tạo một cặp khóa và cấp cho bạn một khóa công khai để thêm vào như một bản ghi DNS TXT. Việc ký diễn ra tự động trên hạ tầng của họ một khi được cấu hình. Không có DKIM, việc các người gửi khác giả mạo miền của bạn dễ dàng hơn đáng kể. Hãy kiểm tra tài liệu xác thực email để có hướng dẫn chi tiết về thiết lập DKIM cho các nhà cung cấp phổ biến.

DMARC gắn kết cả hai với nhau và định nghĩa một chính sách về việc các máy chủ nhận nên làm gì khi một email không đạt SPF hoặc DKIM. Hãy bắt đầu với p=none (chỉ giám sát), xem xét các báo cáo tổng hợp mà các máy chủ nhận gửi trở lại địa chỉ báo cáo DMARC của bạn trong vài tuần, rồi chuyển sang p=quarantine (thư mục spam) hoặc p=reject (từ chối thẳng thừng) một khi bạn tự tin email hợp lệ của bạn vượt qua cả hai kiểm tra. Hãy dùng MXToolbox để xác minh các bản ghi SPF, DKIM, và DMARC của bạn được cấu hình đúng — nó chỉ ra các vấn đề một cách chính xác và cho bạn biết chính xác cần sửa gì.

Những lỗi phổ biến — và cách tránh chúng

Đây là những lỗi tôi thấy thường xuyên nhất trong các hệ thống xác minh sản xuất, theo thứ tự đại khái về mức độ thiệt hại chúng gây ra:

• Không vô hiệu hóa token sau khi dùng. Nếu một token đã dùng có thể được nhấp lần thứ hai và vẫn thành công, bạn có một lỗi logic. Một kẻ tấn công chặn được URL xác minh trong chốc lát (chẳng hạn, từ lịch sử trình duyệt hoặc một yêu cầu được ghi nhật ký) có thể xác minh lại một tài khoản sang một trạng thái khác. Luôn đặt một cờ "đã dùng" trên token và kiểm tra nó ở mỗi lần xác thực.
• Gửi email chào mừng hoặc onboarding trước khi xác minh hoàn tất. Nếu một người dùng đăng ký nhưng không bao giờ xác minh, họ sẽ nhận các chuỗi onboarding cho một tài khoản mà họ có thể không định tạo — hoặc một tài khoản họ cố tạo bằng địa chỉ của người khác. Hãy xếp hàng những email đó cho đến khi xác minh được xác nhận.
• Giới hạn tốc độ không đầy đủ trên endpoint gửi lại. Không có giới hạn tốc độ trên các yêu cầu gửi lại, bất kỳ ai cũng có thể dùng endpoint gửi lại xác minh của bạn để spam một địa chỉ email tùy ý. Hãy giới hạn số lần gửi lại trên mỗi địa chỉ email ở mức như ba lần mỗi giờ. Ghi nhật ký mọi yêu cầu gửi lại.
• Gửi liên kết xác minh qua HTTP. Luôn bắt buộc HTTPS. Một liên kết xác minh HTTP có thể bị chặn trên một mạng dùng chung hoặc bị xâm phạm, cho phép một kẻ tấn công bắt được token trước khi người dùng hợp lệ nhấp vào. Không có lý do hợp lệ nào để chạy các luồng xác thực sản xuất qua HTTP thuần vào năm 2025.
• Không ghi nhật ký các sự kiện xác minh. Khi một người dùng sản xuất báo cáo một vấn đề với email xác minh của họ, bạn cần nhật ký: khi nào token được tạo, khi nào nó được gửi, liệu email có được gửi đi không, khi nào liên kết được nhấp (hoặc không được nhấp), và từ IP nào. Không có dữ liệu này, chẩn đoán các vấn đề sản xuất chỉ là đoán mò.
• Giả định nhà cung cấp email của bạn luôn đáng tin cậy. Việc gửi email có thể thất bại vì nhiều lý do — nhà cung cấp gián đoạn, các vấn đề DNS thoáng qua, dương tính giả của bộ lọc spam. Luôn cung cấp một tùy chọn "gửi lại email xác minh" thủ công mà người dùng có thể tự kích hoạt mà không cần liên hệ hỗ trợ.
• Dùng cùng một token cho nhiều mục đích. Token xác minh, token đặt lại mật khẩu, và token xác nhận đổi email là các ngữ cảnh bảo mật riêng biệt với các mức độ tin cậy và hồ sơ rủi ro khác nhau. Hãy tạo các token riêng biệt với các chính sách hết hạn riêng biệt cho mỗi mục đích.
• Không xác thực định dạng email ở phía máy chủ. Xác thực phía máy khách là một tiện lợi về UX. Nó không phải là một biện pháp kiểm soát bảo mật. Một người dùng hoặc kẻ tấn công vượt qua JavaScript frontend của bạn có thể gửi dữ liệu tùy ý đến API của bạn. Luôn xác thực định dạng email ở phía máy chủ trước khi tạo và lưu bất kỳ token nào.

Một lưu ý về quyền riêng tư và tối thiểu hóa dữ liệu

Xác minh email đòi hỏi lưu trữ dữ liệu nhạy cảm — địa chỉ email và token bảo mật. Hãy áp dụng nguyên tắc tối thiểu hóa dữ liệu xuyên suốt. Xóa các token xác minh ngay khi chúng được dùng — không có lý do gì để giữ lại chúng. Xóa các token hết hạn và không dùng theo một lịch dọn dẹp thường xuyên thay vì để chúng tích tụ. Nếu một người dùng đăng ký nhưng không bao giờ xác minh, hãy gỡ bỏ tài khoản đang chờ của họ sau một khoảng thời gian hợp lý (bảy ngày là một lựa chọn phổ biến) thay vì giữ lại địa chỉ email của họ vô thời hạn.

Electronic Frontier Foundation cung cấp ngữ cảnh hữu ích về các nguyên tắc tối thiểu hóa dữ liệu và vì sao giữ ít dữ liệu hơn là thực hành bảo mật tốt hơn — dữ liệu bạn không giữ thì không thể bị xâm phạm. Và về chủ đề xâm phạm: liệu địa chỉ email bạn đang thu thập đã có trong một vụ vi phạm dữ liệu đã biết chưa? API Have I Been Pwned miễn phí cho sử dụng phi thương mại và có thể phục vụ như một tín hiệu hữu ích trong việc phát hiện gian lận — một địa chỉ đã xuất hiện trong hàng chục vụ vi phạm có thể đáng được xem xét kỹ hơn trong quá trình đăng ký.

Ghép tất cả lại với nhau

Xác minh email là một trong những tính năng trông có vẻ tầm thường trong một hướng dẫn và có chiều sâu thực sự khi bạn xây dựng nó cho sản xuất. Tạo token an toàn về mặt mật mã, lưu trữ dựa trên hash, so sánh thời gian-hằng, thời hạn hợp lý, vô hiệu hóa cờ đã-dùng một cách rõ ràng, thông báo lỗi rõ ràng và cụ thể, kiểm thử đa kịch bản toàn diện, và cấu hình xác thực email đúng đắn — mỗi cái là một mối quan tâm riêng biệt, và làm đúng tất cả chúng là điều tách biệt một hệ thống chất lượng sản xuất khỏi một hệ thống mong manh.

Tin tốt là một khi bạn đã xây dựng nó đúng một lần, bạn có một mẫu hình vững chắc, tái sử dụng được. Tạo token mật mã, lưu trữ dựa trên hash, và xác thực có ràng buộc thời gian áp dụng như nhau cho các luồng đặt lại mật khẩu, đăng ký thiết bị xác thực hai yếu tố, và xác nhận đổi email. Xây dựng hệ thống xác minh cho tốt, và cùng mẫu hình đó sẽ chuyển tiếp gọn gàng qua phần còn lại của việc triển khai xác thực của bạn. Hãy kiểm tra việc triển khai của bạn dựa trên các hướng dẫn của OWASP định kỳ — bối cảnh mối đe dọa tiến hóa, các khuyến nghị bảo mật được cập nhật, và luôn cập nhật là một phần của việc xây dựng phần mềm trụ vững theo thời gian.