Java业务开发常见错误100例
朱晔
贝壳金服资深架构师
立即订阅
6699 人已学习
课程目录
已完结 40 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 业务代码真的会有这么多坑?
免费
代码篇 (20讲)
01 | 使用了并发工具类库,线程安全就高枕无忧了吗?
02 | 代码加锁:不要让“锁”事成为烦心事
03 | 线程池:业务代码最常用也最容易犯错的组件
04 | 连接池:别让连接池帮了倒忙
05 | HTTP调用:你考虑到超时、重试、并发了吗?
06 | 20%的业务代码的Spring声明式事务,可能都没处理正确
07 | 数据库索引:索引并不是万能药
08 | 判等问题:程序里如何确定你就是你?
09 | 数值计算:注意精度、舍入和溢出问题
10 | 集合类:坑满地的List列表操作
11 | 空值处理:分不清楚的null和恼人的空指针
12 | 异常处理:别让自己在出问题的时候变为瞎子
13 | 日志:日志记录真没你想象的那么简单
14 | 文件IO:实现高效正确的文件读写并非易事
15 | 序列化:一来一回你还是原来的你吗?
16 | 用好Java 8的日期时间类,少踩一些“老三样”的坑
17 | 别以为“自动挡”就不可能出现OOM
18 | 当反射、注解和泛型遇到OOP时,会有哪些坑?
19 | Spring框架:IoC和AOP是扩展的核心
20 | Spring框架:框架帮我们做了很多工作也带来了复杂度
设计篇 (6讲)
21 | 代码重复:搞定代码重复的三个绝招
22 | 接口设计:系统间对话的语言,一定要统一
23 | 缓存设计:缓存可以锦上添花也可以落井下石
24 | 业务代码写完,就意味着生产就绪了?
25 | 异步处理好用,但非常容易用错
26 | 数据存储:NoSQL与RDBMS如何取长补短、相辅相成?
安全篇 (4讲)
27 | 数据源头:任何客户端的东西都不可信任
28 | 安全兜底:涉及钱时,必须考虑防刷、限量和防重
29 | 数据和代码:数据就是数据,代码就是代码
30 | 如何正确保存和传输敏感数据?
不定期加餐 (6讲)
加餐1 | 带你吃透课程中Java 8的那些重要知识点(一)
加餐2 | 带你吃透课程中Java 8的那些重要知识点(二)
加餐3 | 定位应用问题,排错套路很重要
加餐4 | 分析定位Java问题,一定要用好这些工具(一)
加餐5 | 分析定位Java问题,一定要用好这些工具(二)
加餐6 | 这15年来,我是如何在工作中学习技术和英语的?
结束语 (3讲)
结束语 | 写代码时,如何才能尽量避免踩坑?
结课测试 | 关于Java业务开发的100个常见错误,你都明白其中缘由了吗?
结课问卷获奖用户名单
Java业务开发常见错误100例
15
15
1.0x
00:00/00:00
登录|注册

30 | 如何正确保存和传输敏感数据?

朱晔 2020-05-26
你好,我是朱晔。
今天,我们从安全角度来聊聊用户名、密码、身份证等敏感信息,应该怎么保存和传输。同时,你还可以进一步复习加密算法中的散列、对称加密和非对称加密算法,以及 HTTPS 等相关知识。

应该怎样保存用户密码?

最敏感的数据恐怕就是用户的密码了。黑客一旦窃取了用户密码,或许就可以登录进用户的账号,消耗其资产、发布不良信息等;更可怕的是,有些用户至始至终都是使用一套密码,密码一旦泄露,就可以被黑客用来登录全网。
为了防止密码泄露,最重要的原则是不要保存用户密码。你可能会觉得很好笑,不保存用户密码,之后用户登录的时候怎么验证?其实,我指的是不保存原始密码,这样即使拖库也不会泄露用户密码。
我经常会听到大家说,不要明文保存用户密码,应该把密码通过 MD5 加密后保存。这的确是一个正确的方向,但这个说法并不准确。
首先,MD5 其实不是真正的加密算法。所谓加密算法,是可以使用密钥把明文加密为密文,随后还可以使用密钥解密出明文,是双向的。
而 MD5 是散列、哈希算法或者摘要算法。不管多长的数据,使用 MD5 运算后得到的都是固定长度的摘要信息或指纹信息,无法再解密为原始数据。所以,MD5 是单向的。最重要的是,仅仅使用 MD5 对密码进行摘要,并不安全
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Java业务开发常见错误100例》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(11)

  • 那时刻
    1.关于日志脱敏,可以在日志处理模块里通过正则表达式对于敏感词比如username匹配后,做模糊字符输出到日志里。
    2.https双向认证指的是服务器额外校验客户端证书,方便控制某个接口是否允许客户端访问,用于第三方服务调用。流程上多了客户端提交自己证书和服务器校验证书等步骤。

    小伙伴们讨论的云平台使用的secretid和secrestkey。云平台更推荐使用临时的IAM来替代吧。

    作者回复: 嗯,对于logback可以直接实现一个MessageConverter来做脱敏,脱敏的方式可以是屏蔽敏感信息的几位,或者是对敏感信息进行加密输出。

    2020-05-26
    3
  • 大胖子呀、
    老师说不能直接对密码进行md5加密,那我心想可以加盐,老师又说盐不要写死,我又想可以用用户名作为盐,接着老师就又说不建议用用户名做盐,应该uuid生成,我就想那保存到数据库不也可以被黑客获取到吗?最后老师又说:有的同学可能又要问了……

    可恶啊,这些都在你的计算当中啊!

    作者回复: 哈哈

    2020-05-26
    3
  • 旅途
    老师 密码使用对称加密或非对称加密不行吗 使用自己的算法进行加密 别人也破解不了

    作者回复: 不行 源码也泄露了呢

    2020-05-26
    3
  • 握了个大蚂蚱
    规模巨大的隐私数据尤其公司搞国际化的业务,应该都会有一个全局的点来管理隐私数据,业务流转的时候都不需要流转明文,相当于拿个令牌流转,到需要置换,显示时,再去兑换,根据需要兑换不同等级的明文(匿名值,完整明文)。
    hash的盐我们是初始化一个map里面放10000个盐,然后把字符串的char转为int再对10000取模得到这个字符串对应的盐。这样好处是盐具有复杂性而又保证hash算法的根本:相同铭文hash后得到相同hash,缺点是用在密码上的话可能会被看出相同密码的数据,需要再加一层处理
    2020-06-05
    1
  • Joker
    关于彩虹表的解释在这里:https://www.zhihu.com/question/19790488,简单想象成一个黑盒吧,你传进加密后的密码,就能得到解密后的密码。但是构造这黑盒的过程就比较麻烦了。但是如果密文都是根据一个字符串根据特定的规则得到的字符串,哪怕是根据用户信息来构造一个盐,那么就有很大的概率出现,构造了一个彩虹表就把整个数据库的密码给解密了的情况。构造彩虹表的过程虽然麻烦,却是一劳永逸的,那么就要想一个不那么一劳永逸的方法,所以就出现了每次都用一个随机盐的方式。
    因为如果是固定的盐的话,那么黑客得到一套数据库之后,只要构造一套彩虹表就能得到结果了。如果每次的盐都不同,那么黑客就要每次都根据密文和盐构造一套彩虹表。
    我就是这么理解的,不知道是否正确。密码学真的难。

    作者回复: 差不多

    2020-05-28
    1
  • Jeff.Smile
    记得一次面试,别人问我https的原理,其实我是理解的,但是记不住这个过程,怎么办?😂

    作者回复: 自己画一遍流程图

    2020-05-27
    1
  • 👽
    敏感数据的话,其实还有一个:
    就是第三方的一些验证数据。类似于阿里云的Id和key。
    我未进行加密保存在配置文件中,并且还将其上传在了GitHub上,按理说,如果Github泄露了,任何人都可以调用我的资源了。因为是透支额度设置的很低,而且余额只有10¥,所以未作安全处理。因为最坏的结果,也就是把我余额全用完。

    1,如果需要涉及到加密,我会考虑到分开存储:
    可能ID存数据库,Key存本地文件。(鸡蛋分在多个篮子里存放,脱库或者服务器被黑,也只有一部分数据泄露,依然无法使用我的服务)
    2,然后加密存放,因为调用服务需要读取,所以必须是可逆的加密算法。增加破译的成本。
    3,定期监控,出问题及时发现。

    作者回复: 大家也可以继续探讨一下 SecretID和SecretKey应该怎么保存

    2020-05-26
    1
    1
  • 👽
    我的理解,没有绝对的安全。现有的一切加密安全措施,其实只是增加破解的难度罢了。真正的安全,还是需要验证码之类的动态验证。

    我一直以来,理解的加密就分两种:可逆的,不可逆的。
    可逆的:规定了一种规律,只要应用这种规律就可以逆推其原始值。我认为其实雪花算法就是可逆的加密算法。知道其运算规律,也可以逆推其创建时间。虽然明文中无法体现其创建时间。
    不可逆的:自己的密码是12,加密后是3,已知了算法是所有数位之和,但是并无逆推出原始数值是111,003,03,102......等。

    但是,无论可逆还是不可逆,破解也是寻找其规律罢了。加密其实本质也是,对结果附加运算过程。
    原始密码 x+a-b*c?d = 密文x1,在足够多的数据样本的时候,我觉得还是可以逆推出原始数据。(解方程嘛。。。)

    我觉得,现在的密码加密,维持个三五年之后,也会被轻易破解。

    其实要是简单粗暴一点,就手机验证码登录,就已经基本OK了,大平台似乎也都是这么做的。类似于某里云。在一些不太重要的数据,就处理的可以适当放开一些。

    作者回复: 其实深度学习就是通过大量样本寻找y=f(x)中的函数f,我们想一下,是否有可能通过深度学习来解密/获得密钥呢?

    2020-05-26
    1
    1
  • kacaric
    请问老师接口能否采用https双向认证保证接口安全,还需要在接口中额外增加签名字段吗?

    作者回复: https确保防止伪造篡改中间人窃取
    双向https虽然限制了客户端,但是粒度还是很粗
    如果我们还是防止调用方随意调用接口,那么还是需要在业务层进行业务加密和签名

    2020-06-13
  • 阿冲
    请问老师脱敏后的数据如何做SQL查询,这个条件怎么处理。比如身份证号和姓名字段?

    作者回复: 脱敏(是指遮掩部分数据)后的数据只能呈现了,加密后的数据要做查询的话,2个办法:
    1、加密后查询
    2、数据库存一个哈希值,查询的话哈希后查询,需要展示的时候再解密

    2020-06-10
  • Geek
    老师好,保护用户二要素AAD在实际会用在哪些场景中,是否用户忘记了自己设置的AAD就没办法类似于重置密码的方式找回AAD了,也就没办法再解密信息?

    作者回复: 不是找回密码的场景,所谓找回密码是重置密码,这里演示的是保护需要用户授权才能获取的重要信息

    2020-05-31
收起评论
11
返回
顶部