在 ASP.NET 应用程序中存储 SMTP 凭据的最佳实践是什么?
我过去创建了几个发送电子邮件的 ASP.NET 应用程序,但我一直不确定在哪里存储 SMTP 凭据。我通常只是创建一个单独的 XML 文件来存储这些信息,但我不确定这是否是最好的方法。
为 ASP.NET 应用程序存储 SMTP 凭据时的最佳实践是什么?
SMTP 凭据是否应该存储在 web.config 中?
I have created several asp.net application that send email in the past but I have always been unsure of where to store the SMTP credentials. I usually just create a separate XML file to store this information but I am not sure if this is the best way.
What are best practices when storing SMTP credentials for an asp.net application?
Should SMTP credentials be stored in the web.config?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
您应该问自己:您将连接字符串存储在哪里?
如果 web.config 对于您的数据库凭据来说足够安全,我不认为 SMTP 的凭据应该有所不同。
所以我的选择是 - 无论您在何处存储连接字符串。
You should ask your self: Where do you store your Connection String?
If web.config is secure enough for your DB credentials, i don't see any reason why SMTP ones should differ..
So my pick would be - wherever you store your Connection String.
我说的是显而易见的事情吗?
Am I stating the obvious?
主观标签?
如果我有我的鼓手,我会存储在 web.config 中。我曾经去过将它们存储在数据库中的地方,只要需要发送电子邮件就可以调用数据库来获取这些凭据(恶心)。
Subjective tag?
I would store in web.config if I had my druthers. I've been at places that stored them in a DB with a call to the DB for those credentials any time an email needed to be sent (yuck).
我建议将 SMTP 服务器设置为仅 NTLM 身份验证,并以服务器的授权用户身份运行 Web 应用程序。除 SMTP 服务器的 IP 之外,不会存储任何凭据。
显然,如果您使用的是 Gmail,则这不是一个选项,在这种情况下,请将其存储在您自己的单独部分中,并使用加密的用户名和密码。然而,您可能会争辩说,如果他们有权访问您的网络配置,他们很可能有权访问您的源文件或可反编译的二进制文件。
I would give the advice to set the SMTP server to NTLM authentication only, and run the web application as an authorized user for the server. No credentials are then stored except the IP of the SMTP server.
Obviously if you're using Gmail this isn't an option, in which case store it in your own separate Section with an encrypted username and password. You could argue however, that if they have access to your web config they're more than likely to have access to your source files or de-compilable binaries.