JWT电子邮件验证协议 [英] JWT Email Validation Protocol

问题描述

我对Web应用程序帐户创建过程中的电子邮件验证步骤有一个想法.这是我第一次构建类似的东西，所以我只想确保此协议是安全的.

I had an idea about the email validation step inside an account creation process on a web application. This is the first time I build something like that, so I just want to be sure that this protocol is secure.

由于我真的不想为未经验证"的用户在数据库中存储任何内容，因此我想到了使用JWT来验证用户的电子邮件地址的想法.这是我的主意:

As I don't really want to store anything on my database for a 'non verified' user, I had the idea to use a JWT in order to verify the user's email address. This is my idea:

1. 用户访问网站上的/register 端点并输入他的电子邮件(仅他的电子邮件，暂时没有用户名或密码).
2. 我在后端服务器上使用正则表达式验证电子邮件格式，并检查与域名关联的MX DNS记录.
3. 我创建一个JWT，其中包含用户仅作为数据提供的用户电子邮件地址.之后，我会向该地址发送一封电子邮件，其中包含指向新端点的链接:/create?token =< Generated jwt> .(此令牌经过加密签名，可防止生成已经绑定到电子邮件地址的注册链接.)
4. 如果该电子邮件属于该用户，则只需单击该链接，我现在就知道该地址有效.
5. 用户可以在此新的/create 端点上完成注册，然后要求他提供用户名和密码.

1. The user visits the /register endpoint on the website and enters his email (only his email, no username or password for the moment).
2. I verify the email format using regex on the backend server and check the MX DNS records associated with the domain name.
3. I create a JWT containing the user's email address that he provided as only data. After that I send an email to that address containing a link to a new endpoint: /create?token=<generated jwt>. (This token is cryptographically signed preventing generation of registration links already bound to an email address).
4. If this email belongs to the user, he just clicks on the link and I would now know that this address valid.
5. The user can complete his registration on this new /create endpoint where he will be asked to provide a username and a password.

我认为该方法将更加用户友好，因为用户不必两次输入用户名和密码(1:注册，2:单击电子邮件链接后登录)，并且对我的数据库更有效我根本不跟踪未验证的用户.
最重要的是，在JWT上设置的过期时间将非常方便，因为我可以将其设置为24小时(创建后)，并且该链接将立即变得不可用.

I think that this method would be more user-friendly because the user don't have to enter his username and password twice (1: registration, 2: login after clicking on the emailed link) and more efficient for my database as I don't keep track of the unverified users at all.
On top of that the expiration time set on the JWT would be very convenient as I could set it to 24 hours (after its creation) and the link would instantly become unusable.

我只需要在/create 端点上显示电子邮件地址，以确保某人没有将绑定到其电子邮件地址的链接发送给其他人进行注册(这将使该人获得稍后可以重置受害者的密码的功能).通过在用户名和密码提示旁边显示一个包含电子邮件地址的不可编辑字段，可以很容易地避免这种情况.

I would just need to display the email address on the /create endpoint to ensure that someone did not send a link bound to his email address to someone else to register (which would give this person the ability to reset the victim's password later). This is pretty easily prevented by displaying a non-editable field containing the email address next to the username and password prompt.

推荐答案

您可能应该使用(并检查)jwt中的 iss 和 aud 字段来指示哪个您的网站所发行的令牌(可能是其本身).虽然您只在一个网站上使用它，但并没有多大关系，但是随着多个网站的使用变得越来越复杂，将其发送给谁的消息中始终是一个好主意.

You should probably use (and check) the iss and aud fields in the jwt to indicate which of your websites issued the token for which one (probably itself). While you only use this on one website, it doesn't matter much, but with multiple websites it gets more complicated, it's always a good idea to include in messages who sent it to whom.

考虑到URL中可以容纳的最大长度，一个以base64编码的jwt(我想)可以变长(但是我认为上述情况会起作用，因此对于此数据，我认为它不会太长)

Consider the max length that will fit in an url, a jwt base64-encoded (I guess) can get long (but I think the above scenario would work, so with this data I don't think it's too long already).

这还允许对jwt机密进行已知明文攻击，因为您将发出新的jwt并将其发送到任何电子邮件地址.也许您可以对/register 端点进行某种速率限制以减轻这种情况.这也可能会拒绝服务，因为对jwts进行签名和发送电子邮件可能会占用大量资源.

Also this allows a known-plaintext attack on the jwt secret as you will issue a new jwt and send it to any email address. Probably you could have some kind of rate limiting on the /register endpoint to mitigate this. This might also have a denial of service aspect as signing jwts and sending emails can be fairly resource heavy.

最后，您在上一段中提到的威胁(用户将自己的链接发送给其他人，以便他们在攻击者的电子邮件地址中注册)是一个很好的威胁.仅显示电子邮件地址可能不足以缓解风险，这完全取决于您的情况，甚至包括视觉效果，我想用户也将如何显示或确认该电子邮件地址.当然，这是攻击用户的一种方法，一种更有效的缓解方法是，如果用户需要再次输入其电子邮件地址，并且将其与jwt中的电子邮件地址进行比较-但这是换来更糟糕的用户体验，需要您权衡取舍.例如，如果您认为足以满足您的应用程序的需求，也可以明确要求用户仅确认电子邮件地址.

And finally, the threat you mentioned in the last paragraph (a user sending his own link to somebody else so they register with the attacker's email address) is an excellent one. Only displaying the email address might not be enough mitigation, it totally depends on your scenario, even the visuals how it would be displayed or acknowledged by the user I guess. This is certainly one way to attack your users, one stronger mitigation is if they need to enter their email address again and you compare it to the one in the jwt - but that is in exchange for worse ux, the tradeoff is for you to decide. You could for example also explicitly have the user just confirm the email address if you think that's enough for your application, it very well can be.

这篇关于JWT电子邮件验证协议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！