近期处理一个老项目的安全漏洞,要求敏感数据不能明文传输,考虑到效率和兼容性等问题,决定使用 对称加密,前端使用CryptoJS,后端使用Java标准库提供的API;
最开始试了DES算法,可以调通,但是鉴于现在这个算法因为秘钥太短已经不安全,又尝试新的AES,但是怎么也不行,后台解密报错:javax.crypto.BadPaddingException: Given final block not properly padded,
搜索出的原因要么说是秘钥错误,这个检查了肯定不会错;要么说是padding模式不一致,确实CryptoJS默认是Pkcs7,而Java为PKCS5Padding,但是很多文章说这两者是兼容的,
难道是因为CryptoJS太新,jdk版本太旧?实在不行可能就得换成两者唯一完全相同的NoPadding,但这样就需要自己处理数据长度问题.本着排除其他干扰的想法,原来的 秘钥key和偏移量是相同的,
再次将其改为了不同的,同时后台也写了与前台相同的加密方法比对,查看打印结果,前台加密后的变了没错,但是后台加密结果好像没变,进而将 秘钥key和偏移量 也打印出来,发现这俩也没变,
这...该不会是热部署没完全起效吧,手动重启Tomcat,再测,后台正常解密,还真是它.
这告诉我们,热部署虽方便,再碰到报错时也要记得考虑一下它出问题的可能性,再就是排错时关键的参数都要打印查看一下,说不定就能发现问题.
CryptoJS标签：插件,加密,坑爹,秘钥,部署,报错,后台,CryptoJS From： https://www.cnblogs.com/dirgo/p/17904390.html