专业的JAVA编程教程与资源

网站首页 > java教程 正文

那些年我在数据库加密的大坑坑坑坑

temp10 2025-03-06 19:46:07 java教程 71 ℃ 0 评论

之前在对数据库加密的需求中遇到一些坑,拿出来分享一下。

加密的方案是:将数据使用AES加密再经过base64编码。

那些年我在数据库加密的大坑坑坑坑

最近整理了一些Java架构学习视频和大厂项目底层知识点,需要的同学欢迎私信我【Java】发给你~

坑一: AES+base64加密后的长度

AES算法加密后的长度应当是:不小于原始长度的16的最小倍数。例如:

  • 15字节加密后变成16字节
  • 16字节加密后变成32字节 这是第一个坑

后面base64编码后的长度即变成4/3倍。


坑二: 数据库的编码对varchar类型的影响

varchar(n) 这个类型其实是指能容纳 n个字符,即如果数据库的编码是utf8,即每个字符可能占3个字节,那么在极限情况下,有可能 3*n 个字节。

然而经过base64以后,这些字节都将对应于一个字符。因此,在n不是16整数倍的情况下,加密以后varchar的长度应当变为4*n (如果n是16整数倍,则存在->坑一)


坑三: 加密后数据库模糊匹配的问题

即无法使用 like 语法,必须完全匹配。

目前没有一个好的解决方案,针对数量级特别小的加密表,忽略模糊匹配的字段查询,解密后再过滤也可以; 量级稍大一点点 并且不需要频繁修改的,将明文结果缓存也可以。


坑四: MySql的字符串比较大小写问题

MySql的字符串匹配默认是大小写不敏感的,也就是说之前系统里能匹配到的加密后就无法匹配了。

这里还涉及到统一认证系统URS的一个问题,该系统返回给我们的账户名有时大写有时小写。。

这是MySql的一个特性,sqlite则默认大小写敏感


坑五: MyBatis缓存

由于MyBatis的缓存,在dao操作里对select出来的对象直接解密,可能会对下一次同一个dao操作有影响。详见:mybatis 的缓存坑


来源:网易工程师-郁利涛

看到这里的小伙伴,如果你喜欢这篇文章的话,别忘了转发、收藏、留言互动!

最近我新整理了一些Java资料,包含个人精选的Java架构学习视频、大厂实战知识点、大厂内部面试题,如果你需要的话,欢迎私信我

如果对文章有任何问题,欢迎在留言区和我交流~

Tags:

本文暂时没有评论,来添加一个吧(●'◡'●)

欢迎 发表评论:

最近发表
标签列表