E-posta doğrulaması neden düşündüğünüzden daha önemli

E-posta doğrulamasının üç temel amacı vardır. Birincisi, kullanıcının sağladığı adresi gerçekten kontrol ettiğini doğrular — [email protected] gibi yazım hataları şaşırtıcı derecede yaygındır. İkincisi, sahte veya tek kullanımlık adresler kullanan botların toplu otomatik hesap oluşturmasını azaltır. Üçüncüsü — ve en çok küçümsenen neden — doğrulanmış bir e-posta adresi, şifre sıfırlamanın güvenlik ön koşuludur. Doğrulama olmadan, saldırgan başkasının adresini kaydedip sıfırlama e-postasını tetikleyebilir. OWASP Authentication Cheat Sheet bu riskleri ayrıntılı şekilde ele alır.

Tam doğrulama akışı adım adım

E-posta aktarım protokolü RFC 5321'de tanımlanmıştır — ancak uygulama katmanındaki kararlar tamamen geliştiriciye aittir. Her adım önemlidir:

1. Kullanıcı kayıt formunu gönderir. E-posta formatını sunucu tarafında doğrulayın — yalnızca istemci tarafında değil.
2. Kriptografik olarak rastgele token oluşturun. UUID değil, sıralı ID değil, zaman damgası değil — en az 32 bayt entropili gerçek kriptografik rastgelelik.
3. Token hash'ini veritabanında saklayın. Ham token değil, SHA-256 hash'ini — kullanıcı ID, oluşturma zaman damgası, son kullanma tarihi ve "kullanıldı" bayrağıyla birlikte.
4. Doğrulama e-postasını gönderin. Bağlantı, ham tokeni sorgu parametresi olarak içerir. Her zaman HTTPS kullanın.
5. Kullanıcı bağlantıya tıklar. Sunucu, sorgu dizisinden ham tokeni alır.
6. Token'i doğrulayın. Gelen tokeni hash'leyin, veritabanında eşleşmeyi bulun, son kullanma ve "kullanıldı" durumunu kontrol edin.
7. Başarı durumunda: e-posta adresini doğrulanmış olarak işaretleyin, token'i kullanıldı olarak işaretleyin, kullanıcıyı giriş yaptırın.
8. Hata durumunda: yeni e-posta talep etme bağlantısı içeren spesifik ve eyleme geçirilebilir hata mesajı gösterin.

Güvenli token oluşturma

En yaygın hata, UUID v4'ü doğrulama tokeni olarak kullanmaktır. UUID'ler veritabanı tanımlayıcıları için iyidir, ancak güvenlik tokenleri olarak tasarlanmamıştır. Doğru yaklaşım: runtime'ınızın kriptografik rastgele sayı üreticisini kullanın. Node.js: crypto.randomBytes(32).toString('hex'). Python: secrets.token_urlsafe(32). .NET: RandomNumberGenerator.GetBytes(32). OWASP Authentication Cheat Sheet, doğrulama tokenleri için en az 32 bayt (256 bit) entropi önerir.

Doğrulama akışını doğru test etme

Doğrulama akışındaki her değişiklik, gerçek bir gelen kutusuna gerçek bir e-posta göndererek test edilmelidir. Bir geçici e-posta adresi açın, kayıt formuna kopyalayın, test hesabı oluşturun ve doğrulama e-postasının gerçek zamanlı olarak ulaşmasını izleyin. Bu, e-postanın gerçekten teslim edildiğini kesin olarak kanıtlar.

E-posta kimlik doğrulama: SPF, DKIM ve DMARC

Doğru e-posta kimlik doğrulaması olmadan, doğrulama e-postaları spam'e düşer. SPF, gönderme sunucularını DNS TXT kaydıyla yetkilendirir. DKIM şifreli imza ekler. DMARC, SPF veya DKIM başarısız olduğunda politikayı tanımlar. Üç yapılandırmayı kontrol etmek için MXToolbox kullanın. Gönderme sağlayıcınızdaki e-posta kimlik doğrulama belgelerine başvurun.

Kaçınılması gereken yaygın hatalar

• Kullanımdan sonra tokeni geçersiz kılmamak. Her zaman "kullanıldı" bayrağını ayarlayın ve her doğrulamada kontrol edin.
• Doğrulamadan önce hoş geldiniz e-postaları göndermek. Onboarding dizilerini yalnızca onaylanmış doğrulamadan sonra etkinleştirin.
• Yeniden gönderme uç noktasını hız sınırlamamak. Adres başına yeniden gönderme isteklerini örneğin saatte üç ile sınırlayın.
• HTTP üzerinden doğrulama bağlantıları göndermek. Her zaman HTTPS kullanın — istisnasız.
• Doğrulama olaylarını günlüğe kaydetmemek. Token ne zaman oluşturuldu, gönderildi ve tıklandı — hata ayıklama için gerekli.
• Birden fazla amaç için aynı tokeni kullanmak. Doğrulama, şifre sıfırlama ve e-posta değişikliği için ayrı tokenler kullanın.