密码修改和重置功能是应用程序提供给用户的密码修改或重置的自助服务机制。这种自助服务允许用户快速修改或重置他们的密码，而不需要管理员参与。当密码被修改后，应用程序中也一般同时被修改。当密码被重置时，他们或是由应用程序生成或是发送邮件给用户告知。这可能会说明密码被明文存储或是以可解密的方式存储。
对于密码修改和密码重置功能两者来说，都应该重点检查：
除了上面提供的检查，确认下面的情况也很重要：
重置密码需要哪些信息？
第一步是检查是否需要回答安全问题。不询问安全问题就发送密码（或密码重置链接）到用户邮件地址意味着100%依赖邮件地址的安全性，可能不符合某些高等级的安全需求。
从另一方面来说，如果需要回答安全问题，第二步就是评估他们的强度。这部分特定测试在指南中测试安全问题的脆弱性章节有深入描述。
重置后的密码如何告知用户？
在这里，最不安全的场景是如果密码重置工具直接显示给我们密码，这给了攻击者登录账户的机会，除非应用程序提供关于上次登录的信息，否则受害者不知道他们的账户已经沦陷。
较为不安全的场景是入宫密码重置工具强制用户立刻修改他们的密码。这不像第一个场景那么隐蔽，这允许攻击者获得权限，并踢出真正的用户。
最安全的方法是通过向用户最初注册的或其他的电子邮件发送链接。这强制使攻击者不仅要猜测重置的密码被发送到哪个邮件账户（除非应用程序显示了这个信息），而且需要攻破邮箱账户来获取临时密码或密码重置链接。
重置的密码是否是随机生成的？
在这里，最不安全的常见是如果应用程序明文发送或显示了旧密码，这意味者密码没有通过哈希形式存储，这本身就是一个安全问题。
最安全的方法是密码通过一个安全的算法随机生成，而且不能被推断出来。
重置密码功能是否在修改密码前要求确认？
为了限制拒绝服务攻击，应用程序应该向用户发送邮箱链接时候附带随机令牌，并且只有当用户访问这个链接时，整个重置过程才算完成。这确保了当前的密码在重置请求被确认前依旧有效。
除了上个测试以外，还应该重点确认：
在完成过程中是否要求提供旧密码？
最不安全的场景就是应用程序允许在没有旧密码的情况下修改密码。这时如果攻击者能够控制一个合法的会话，他们也就能轻易修改修改受害者的密码了。
同时参考测试弱密码策略 章节。
密码修改或重置功能是一个敏感的操作功能，需要某种形式的保护，比如要求用户再次认证或在过程中提示用户确认界面。