使用 GenerateChangePhoneNumberTokenAsync() 来确认电子邮件而不是电话号码是否可以接受？答案

【问题标题】：Is it acceptable to use GenerateChangePhoneNumberTokenAsync() to confirm an email instead of phone number?使用 GenerateChangePhoneNumberTokenAsync() 来确认电子邮件而不是电话号码是否可以接受？
【发布时间】：2022-01-02 08:20:32
【问题描述】：

我正在 Xamarin 中构建一个 API 和一个移动应用程序。我不想确认电话号码，因为我必须使用 Twilio 或其他 SMS 提供商，相反，我想确认电子邮件。同时，我不想创建一个电子邮件令牌发送给用户点击链接，因为 API 不是 MVC，不会有任何视图。

相反，我希望将 6 位代码通过电子邮件发送给用户，然后我将在 API 中创建一个端点，用户将通过移动 APP 提交该代码以确认电子邮件。例如：

var code = await _userManager.GenerateChangePhoneNumberTokenAsync(newUser, newUser.Email);

这将创建代码，请注意我传递的是用户电子邮件而不是电话号码。此代码现在通过电子邮件发送给用户，用户在移动应用程序中输入此代码。那么：

var confirmed = await _userManager.VerifyChangePhoneNumberTokenAsync(newUser, code, newUser.Email);

这确认代码是正确的。然后我将使用由此产生的布尔值手动将数据库中的EmailConfirmed 设置为true

它有效。还是可以接受吗？我有什么理由不应该这样做吗？

【问题讨论】：

也许也值得在security.stackexchange.com 上提问

标签： asp.net-core xamarin .net-core asp.net-identity

【解决方案1】：

弹出的一个原因是，尽管它只是一个验证码，但从语义上讲，该功能是针对电话代码的，因此如果您将来将其用于电子邮件，它可能会引入一些“陷阱”。

通过阅读the source，您可以看到当前的实现基于RFC 6238：基于时间的一次性密码算法，它对于电子邮件的使用也足够通用。

因此，您知道通过使用相同的方法，它与在 ASP.NET Identity Core 中实现的 RFC 6238 规范一样安全。

你不能只使用类，因为访问修饰符是internal，但遵循相同的想法，基于相同原理的.NET 有OTP Libraries。

在我看来，使用one of them 将确保实现尽可能干净和通用，但是对于当前版本的 ASP.NET Identity Core 的快速而肮脏的解决方案，我认为该方法没有问题.

【讨论】：