如果表单未通过验证,密码字段是否应保留其值?

Sco*_*pey 27 html c# passwords validation asp.net-mvc

我有一个带有两个密码字段的典型注册表单.

<form>
    <%= Html.TextBox("Email", null) %>

    <%= Html.Password("password", null) %>
    <%= Html.Password("confirmPassword", null) %>

    <input type='submit' />
</form>
Run Code Online (Sandbox Code Playgroud)

如果表单未通过验证并重新显示,则文本字段将保留其值,但密码字段始终为空.

为什么密码字段不能保留其值? 更重要的是,我有什么理由不应该覆盖这种行为吗?

我觉得这种行为会降低可用性,并且更喜欢密码字段的行为方式与文本框字段相同 - 在验证错误存在时保留输入的值.

我正在使用ASP.NET MVC,但这个问题更多地涉及可用性和安全性.我明白我所看到的是预期的行为,并且看一下这个Password(...)方法就会明白我明确地忽略了它的价值ModelState.

Not*_*tMe 16

您可以在常规输入类型=密码字段上发回该值.

但是,如果您使用的是.net输入控件,那么它会在将html发送回客户端之前清除值的内容.

原因很简单:他们希望限制在服务器和浏览器之间来回发送密码的次数.这有助于限制某些系统的暴露.(链接)

现在,显然,如果你使用ssl,那么这不是一个考虑因素.不幸的是,绝大多数站点仍然没有使用SSL,并且很乐意在数据库中来回发送数据.该字段在客户端和服务器之间传播的次数越多,获取FireSheep的机会就越多.

请记住,这并不是说有人在整个谈话中听不到第一篇文章.但是,请将其视为限制(不消除)攻击面的简单选项.

下一个原因是几乎每次站点在提交后都向用户显示密码字段,这是因为验证没有通过.这可能意味着用户名和/或密码不正确.考虑到密码字段只向用户显示星号或点,没有真正的理由将其返回给用户.

鉴于您永远不想告诉用户哪些凭据失败(即:您不想说"密码无效"或"用户名无效")并且普通用户无法确定他们是否发胖他们的进入,恕我直言,清除BOTH会好得多.


除此之外,你可以在这里选择.标准是将其删除.考虑到这是绝大多数网站的工作方式,你真的想要反对这种做法吗?就个人而言,我发现即使我们不同意它们,我们也更好地坚持使用UI标准.

用户已经有足够的时间可以使用所有不同的选项.

  • 感谢您的深思熟虑的答案.但是,我不同意"限制攻击面"会增加安全性.如果您有一个HTTP站点,您的用户名和密码将以明文形式发送,并且将该流量减少<50%对您没有多大帮助.你的第二点是正确的,但它假设是一个"登录"页面,而不是一个"注册"页面,它应该被区别对待.最后,我不同意有一个"标准"......例子,StackOverflow如果你的CAPTCHA失败,你的密码就完整了! (2认同)
  • @Scott:我同意,这没什么用.然而,我认为这背后的想法是你要求的......;)回到注册页面,我再次相信它们应该被清除.如果由于密码不匹配而错误输出,用户怎么可能知道错误哪一个?他们不会,所以要善待你的用户,你要清除它们并要求他们再试一次.从可用性的角度来看,这比面对2个装满点的盒子更好,而且不知道要清除哪个盒子.面对用户将要清除这两个并再试一次. (2认同)

Sco*_*pey 11

@NickHeidke和@Chris Lively提交的答案都很棒,让我得出了一些我想分享的结论.

首先,关于可用性:当表单未通过验证时,验证问题与验证问题无关,在密码字段保留其值时可能适合的唯一位置是"注册"表单.密码或确认密码.它绝对不适合"登录"表单,"更改密码"表单,或者可能是任何其他地方.因此,Html.Password忽略了这一事实是ModelState完美无缺的.

其次,关于安全性:除非仔细实施,否则"注册"表单将保存在浏览器的导航历史记录中.按"返回"将重新发送您的密码,这可能无法通过验证,并返回填写了密码的表单.密码填写的事实不是安全漏洞,因为它与浏览器已保存和发送的密码相同.您可以"查看源代码"以查看密码,但您也可以查看页面请求以查看密码(例如,使用FireBug).

当然,当你看到填写的密码时,"查看源代码"会更容易也更明显,但我会说更好的解决方案是以一种未保存到浏览器历史记录的方式实现"注册"表单; 例如,带有验证PRG模式解决方法,但这是一个完全不同的主题!

我的结论是这样的:密码字段在显示时几乎总是清晰的.如果您想提高可用性并且不想让用户重新键入其密码,请首先尝试使用客户端验证!最后,如果您真的知道自己在做什么,并且真的想提高可用性,那么可以在注册表单上保留这些值.但这可能不是最好的主意.