登录密码加密怎么测试(登录密码加密解密)

2023-02-01 22:49:55 密码用途 思思

数据库 ENCRYPT()加密的密码怎么验证登录

String.Format("selectencryptbycert(cert_id('c1'),'')fromtest,TextBox2.Text);这个是把你加密后的密码作为字段名来查询了吧。另外你这逻辑有很大问题呀,就算把上面的SQL改好也不行。你的逻辑是首先判断用户是否存在,然后判断密码是否存在,你都不判断用户名对应的密码是否是你输入,只是判断数据库里是否存在这个密码……

登录密码加密怎么测试(登录密码加密解密) 第1张

jmeter如何测试加密过的登录接口

1.用jemter做接口

1.我们先建立一个线程组

2.我们要设置一个http,发送http默认请求值,放入你需求测试的地址

3.在建立一个http请求

4.添加监控器,主要是监控结果,查看结果树

5.查看请求,发现请求是成功了的,但是响应数据是错误,登录失败了,因为请求失败以后的数据是以下的数据

"State":9999, // 9999

至于为什么,是因为登录需要加密的key,有一个加密的算法,那如果这样,就只能用java来手写这个接口了,就在下次共享出来吧。

如何保证用户登录时提交密码已经加密

如何保证用户登陆时提交密码已经加密?密码是否已加密,需要客户端和服务端建立约定,双方按约定办事就行了。

这里提到的另一个问题是,如何保证传输安全?

最理想的方案当然是走 HTTPS 协议. HTTPS

在理论上是可靠的,但在国内会打一些折扣:你可以随便找一台电脑看看有没有安装商业公司或机构的根证书,这些根证书为线路某节点成为中间人提供了可能性;同时,在木马横行的年代,密码在加密提交前可能就被拿到了,此时

HTTPS

成了摆设,这是为什么国内流行密码控件的一个重要原因。

从成本和需求上考虑,对于众多对安全性要求不高的个人网站,仍然可以考虑采用

HTTP 传输,密码提交前通过 JavaScript 加密。由于

JavaScript

代码暴露在客户端,因此一般通过不可逆的加密方法加密密码,而对于任何摘要式的加密算法,都可以通过类似

md5 字典的方式直接查表获知弱密码,所以要混入

salt

以增加制作字典的成本。可想而知,解密只是时间成本的问题。因此这里的重要前提是“对安全性要求不高”。

如何验证密码呢?一个可行的方法是,客户端提交

md5(password)

密码(如上所述,此方法只是简单保护了密码,是可能被查表获取密码的)。服务端数据库通过

md5(salt+md5(password)) 的规则存储密码,该 salt

仅存储在服务端,且在每次存储密码时都随机生成。这样即使被拖库,制作字典的成本也非常高。

密码被 md5() 提交到服务端之后,可通过 md5(salt +

form['password'])

与数据库密码比对。此方法可以在避免明文存储密码的前提下,实现密码加密提交与验证。

这里还有防止 replay

攻击(请求被重新发出一次即可能通过验证)的问题,由服务端颁发并验证一个带有时间戳的可信

token (或一次性的)即可。

当然,传输过程再有 HTTPS 加持那就更好了。

最后,为什么要密码控件?原因之一是上面说的,要防止密码在提交前被截获。

“登录”功能如何测试?

常用的登录方式有很多,如:邮箱、账号、手机号登录。对于同时支持多种登录方式,测试时除了考虑每种方式是否能够登录成功以外,还需要考虑不同登录方式的优先级、对于用户习惯登录方式的设置和记忆、各种登录方式之间的切换、不同设备的不同登录方式等。

以下是“登录”功能需要测试的点:

输入正确的用户名和密码登录成功

输入错误的用户名密码登录失败

用户名或密码错误或为空时,是否有对应的错误提示

用户未注册就登录,是否提示先注册再登录

已经注销的用户登录失败,提示信息是否友好

密码框是否加密显示

用户名、密码是否支持中文、特殊字符

用户名、密码框是否有长度限制,是否区分大小写

密码为一些简单常用字符串时,是否提示修改?如: 123456

密码存储时是否加密

验证码有效时间

验证码输入错误或过期,提示信息是否友好

验证码是否容易识别,换一张功能是否可用,点击验证码图片是否可以更换验证码

如果使用第三方账号 (微信,QQ,微博账号)登录,那么第三方账号与本系统的账号体系对应关系如何保存

布局是否合理、美观,输入框是否对齐

风格和提示信息用语是否符合语境

登录页面文字和图片能否正常显示,按钮的设置和排列是否正常

页面默认焦点是否定位在用户名的输入框中

首次登录时相应的输入框是否为空,或者如果有默认文案,当点击输入框时默认方案是否消失

页面的前进、后退、刷新按钮是否可用

快捷键 Tab,Esc,Enter 等,能否控制使用

单用户登录系统的响应时间是否符合 "3-5-8"原则

用户数在临界点时并发登录是否还能符合 "3-5-8"原则

大量并发用户登录,系统的响应时间是多少,系统会出现宕机、内存泄露、 cpu饱和、无法登录吗,是否存在资源死锁和不合理的资源等待

长时间大量用户连续登录和登出,服务器端是否存在内存泄漏

用户名和密码是否通过加密的方式,发送给Web服务器

用户名和密码的验证,应该是前端验证+服务器端验证, 而不能单单是在客户端用javascript验证

密码输入框是否不支持复制和粘贴

用户名和密码的输入框,无SQL 注入攻击风险

错误登录的次数限制(防止暴力破解)

验证码不能被轻易破解、欺骗

不登录的情况下,在浏览器中直接输入需要登录后才能访问的URL地址,验证是否会重新定向到用户登录界面

同一用户先后在多台终端的浏览器上登录,验证登录是否具有互斥性

主流的浏览器下能否显示正常

不同的操作系统是否能正常工作

移动设备上是否正常工作

不同的分辨率

是否提供记住用户名密码、自动登录的功能

输入用户名,密码后按回车,是否可以登陆

连续输入 3次或以上错误密码,用记是否被锁一定时间(如:15分钟),时间内不允许登录,超出时间点是否可以继续登录。

输入框能否可以以Tab键切换

用户 session过期后,重新登录是否还能重新返回这前session过期的页面

用户名和密码输入框是事支持键盘快捷键?如:撤销、复制、粘贴等等

是否允许同名用户同时登录进行操作?考虑 web和app同时登录

手机登录时,是否先判断网络可用

手机登录时,是否先判断 app存在新版本

是否支持单点登录

如何做接口测试

1、可以使用postman软件进行接口测试,这里以较复杂的上传图片的接口为例进行测试,首先打开postman软件选择Post方式,输入后台接口调用地址。

2、然后填写Headers,注意这里的Headers部分不要写任何东西,如果之前是有Content-Type头信息, 那么就会上传失败。

3、接着填写Body,选择form-data,填写Key后台规定的接收文件的名称参数,格式选择为File,此时value会自动变成选择文件。

4、最后点击Send,可以发现下方返回了接口的响应,说明上传图片是成功的,这样简单的图片上传的接口测试就完成了。