大家是怎么对数据库主键进行加密的？
如果要查询某个数据需要用到主键的，直接用数据库自增的id肯定不行，是不是需要添加另外一个字段然后对该字段进行加密并查询？
可以直接用唯一约束来做主键。。。
--- 共有 4 条评论 ---
: 给分吧。 thx
: 个人建议还是保留， 每一张表都应该有个数字型的自增字段。 为了扩展。
那么原来的自增id是否还需要？
uuid不就没事了
很好奇，为什么要加密？
--- 共有 1 条评论 ---
用自增主键可能会被别人推测出用户数量
很好奇，为什么喜欢加自增id，直接用唯一的主键不是最好的吗-userid?
现在的存储成本已经很低了，所以用uuid就好了；即使设计用的是uuid类型，数据库内部还是有一个整数类型的，所以也不存在所谓的性能问题。
--- 共有 2 条评论 ---
针对主键应该还好，外键字段加上索引就好了，可以用唯一索引就更好了
表连接就有点蛋疼了在 Oracle 数据库 11g 中使用透明数据库加密
Oracle 学习资料库
在 Oracle 数据库 11g 中使用透明数据库加密目的本教程将描述如何使用 Oracle 数据库 11g 的企业管理器数据库控制中的透明数据加密来对磁盘上存储的数据进行加密。所需时间30 分钟
查看屏幕截图
将鼠标置于此图标上以加载和查看本教程的所有屏幕截图。（警告：此操作将同时加载所有屏幕截图，因此网速较慢时，响应时间可能会比较长。）
注：此外，您还可以在下面的步骤中将鼠标放在每个单独的图标上，从而仅加载和查看与该步骤相关的屏幕截图。
将鼠标移到该图标上可以隐藏所有屏幕截图
更多融合中间件下载
客户与活动
电子邮件订阅
服务与商店
电话: 800-810-8-6698由拖库攻击谈口令字段的加密策略(数据库加密)
字体：[ ] 类型：转载 时间：
我不得不惨痛地写在前面的是，这是一个安全崩盘的时代。过去一年，已经证实的遭遇入侵、并导致关键数据被窃或者被泄露的公司，包括索尼、世嘉这样的大型游戏设备厂商;包括花旗银行这样的金融机构，也包括了RSA这样的安全厂商
这些事件中最令业界瞠目的是RSA被入侵，这直接导致多家工业巨头遭遇连锁的攻击，很多安全企业本身也使用RSA的令牌。比RSA弱小很多的荷兰电子认证公司DigiNotar已经在被入侵后，宣告破产。 　　就在2011年上半年，我们还是站在旁观者的立场讨论这些事情。但随即我们就遭遇了CSDN、多玩和天涯等等的数据泄露，其中最为敏感的，一方面是用户信息，另一个当然就是用户口令。由于身份实名、口令通用等情况影响，一时间人人自危。各个站点也陷在口水当中。 　　但实际上根据推断，这些入侵都是一些过去时，也就是说这些库早就在地下流传。同时流出，也许就是一个集体性的心理效应。 　　这种针对数据库记录的窃取，被一些攻击者称为“拖库“，于是有了一个自然而谐音的戏称“脱裤”。只是攻击者日趋不厚道，从前只是偷了人家的裤子，现在还要晾在大街上，并贴上布告说，“看，丫裤子上还有补丁呢”。 　　如果拖库是很难避免的，那么采用合理的加密策略，让攻击者拿到库后的影响降低到更小就是必要的。 　　明文存放口令的时代肯定是要结束了，但加密就安全么? 　　那些错误的加密策略 　　明文的密码固然是不能接受的，但错误的加密策略同样很糟糕。让我们看看下列情况。 　　简单使用标准HASH 　　我想起了一个90年代黑客笑话，有人进入一台UNIX主机，抓到了一个shadow文档，但破解不了。于是，他用自己的机器做了一个假的现场，故意留下这个shadow，最后看看别人用什么口令来试，最后再用这些口令与渗透原来的主机。遗憾的是，那时我们都把这个当成一个Joke，充其量回复一句“I服了you!“，而没有反思使用标准算法的问题。 　　目前来看，在口令保存上，使用最为广泛的算法是标准MD5 HASH。但实际上，很长时间，我们都忽略了HASH设计的初衷并不是用来加密，而是用来验证。系统设计者是因为HASH算法具有不可逆的特点所以“借”用其保存密码的。但其不可逆的前提假设，是明文集合是无限大的。但放到口令并不一样，口令的长度是受限的，同时其可使用的字符也是受限的。我们可以把口令的总数看正一个事实上的有限集(很难想象有人用100个字符作为口令)。 　　比如一个人的密码是“123456”，那么任何采用标准MD5加密的网站数据库中，其存放的都是这样一个MD5值：E10ADC3949BA59ABBE56E057F20F883E 　　由于密文均相同，加之HASH算法是单向的，因此攻击者较早使用的方法就是“密文比对+高频统计“后生成密文字典来攻击，由于绝大多数网站和系统的加密实现，都是相同明文口令生成相同的密文，因此，那些有高频密文的用户就可能是使用高频明文口令的用户。攻击者一方面可以针对标准算法来制定高频明文的对应密文档来查询，另一方面，对于那些非标准算法，高频统计攻击的方法也非常常见。 　　但查表攻击迅速压倒高频统计的原因，正是从2000年开始陆续有网站规模性明文口令泄漏事件开始的。在过去每一次明文的密码泄漏事件，攻击者都会把使用MD5、SHA1等常见HASH算法加工成的口令与那些采用HASH值来保存的库进行应对。 　　随着超算资源的廉价、GPU的普及、存储能力的增长，一个不容忽视的威胁开始跃上桌面，那就是，这些巨大的HASH表已经不仅仅是基于泄漏的密码和常见字符串字典来制作，很多攻击者通过长期的分工协作，通过穷举的方式来制作一定位数以下的数字字母组合的口令串与多种算法加密结果的映射结果集，这些结果集从百GB到几十TB，这就是传说中的彩虹表。 　　HASH的单向性优势在此已经只有理论意义，因为HASH的单向性是靠算法设计保证的，使用一个有限集来表示一个无限集，其必然是不可逆的。但攻击者是从查表来完成从HASH到口令明文的还原的。因此其算法的单向性也就失去了意义。 　　联合使用HASH 　　一些人误以为，HASH不够安全是因为HASH算法的强度问题，因此把MD5或者SHA1联合使用，其实这是毫无价值的(只是徒耗了存储资源)。如上面所说，HASH的不安全性在于大量口令与其HASH值的对应关系早已经被制作成彩虹表。只要你联合使用HASH的算法其中之一在彩虹表中，自然就可以查到了。 　　同理，那种采用“MD5的头+SHA的尾“之类的，或者采用其他的混合两个值的方法，也一样是没有意义的。因为攻击者可以很容易的观察到这种组合方法的规律，经过拆解后继续按照查表法破解。 　　自己设计算法 　　我一向认为，既然我们不是一个密码学家，而是工程师、程序员，那么放着现成的好东西不用，自己开发加密算法是相当愚蠢的事情。我相信很多程序员都遇到过挖空心思想到了一个“新算法”，然后发现早在某篇20世纪80年代的数学论文里，早就提出了相关算法的情况。 　　况且在开源时代，很多算法不仅被实现和发布了，而且还经历了长期的使用推敲。这些都是自己设计、自己实现无法比拟的。 　　关于自主设计的算法的不安全性，有一个事情深达我脑海。记得我在证券系统工作时，由于刚刚接手收购来的营业部，需要把一个clipper编译的柜台系统进行迁移，但原来的开发商已经联系不到了，当时我们制定了两条路，一位高手李老师负责，进行数据破解，看看是否能还原明文，而我则负责破解算法，如果李老师那边走不通，则我需要解出算法，把9999之间的数字全部加密，然后用密文做碰撞(那时证券都是柜台操作，没有网上炒股，密码都是柜台用数字键盘输入的)。 　　由于原来的开发者加了一点花活，我这边还没有眉目，那边旁观李老师的工程师，已经发出了惊叹之声，我跑过去，只见李老师根据构造的几个密码的加密结果，在纸上汇出了长得非常像杨辉三角的东西。不到半个小时，李老师已经连解密程序一起做好了。 　　上面故事的目的是说明，自己设计算法无论怎么自我感觉良好，看看美国官方遴选算法的PK过程大家就明白了，我们无法和全球数学家的智慧组合对抗。 　　因此自己设计实现算法，并不是一个好主意。这其中也包括，在实现上会不会有类似输入超长字符串会溢出一类的Bug。 　　单独使用对称算法 　　在标准HASH安全破灭后，又看到有人呼吁用AES，其实这不是一个好建议。AES这些对称算法，都不具备单向性。网站被攻击的情况是复杂的，有的是只有数据库被拖，有的则整个环境沦陷。而后者AES密钥一旦被拿到，密码就会被还原出来，这比被查表还要坏。 　　当然我们还看到一种把AES当HASH用的思想，就是只保留一部分的AES加密结果，只验证不还原。但其实这样的AES并不见得比HASH有优势。比如即使攻击者没有拿到密钥，也只拖了库，但攻击者自己在拖库之前注册了足够多的帐号，并使用大量不同的短口令。那么就拿到了一组短明文和对应密文。而此时密钥是完全有可能被分析出来的。 　　而使用DES、AES一类的算法，还是使用标注HASH，还是自己设计算法，如果不解决不同用户相同口令密文相同的统计性缺陷，那么攻击者即使拿不到密钥，也都可以先把一些高频口令用于帐号注册，拖库后进行密文比对。就可以锁定大量的采用常见口令的用户。 　　加“一粒盐” 　　其实很多同仁都指出了哈希加盐法(HASH+SALT)，是问题的解决之道，所谓加盐(SALT)其实很简单，就是在生成HASH时给予一个扰动，使HASH值与标准的HASH结果不同，这样就可以抗彩虹查表了。 　　比如说，用户的密码是123456，加一个盐，也就是随机字符串“1cd73466fdc24040b5”，两者合到一起，计算MD5，得到的结果是6cb1bd9b48475aaab59358e。通过这种操作，即便用户用的弱密码，也通过加盐，使实际计算哈希值的是一个长字符串，一定程度上防御了穷举攻击和彩虹表攻击。 　　但从我们审计过的实现来看，很多人只加了“一粒盐”。也就是说，对同一个站点，不同用户使用同一个密码，其密文还是相同的。这就又回到了会遭遇高频统计攻击，预先注册攻击等问题。 　　口令的安全策略 　　在传统密码学家眼中只有一种加密是理想的，那就是“一次一密”，当然事实上这是不可能的。但如果我们套用这种词法，我们也可以说，口令安全策略的理想境界，我们可以称为单向、一人一密、一站一密。 　　单向：标准HASH算法的价值尽管在这个场景下，已经被推倒，但其单向性的思想依然是正确的，口令只要是能还原的，就意味着攻击者也能做到这一点，从而失去了意义，因此使用单向算法是必须的。 　　一人一密：同一个站点设置同样口令的不同用户，加密生成的密文内容并不相同。这样就能有效的应对结果碰撞和统计攻击。采用字典的攻击的方法基本是不收敛的。 　　一站一密：仅仅保证一人一密是不够的，还要保证使用同样信息、同样口令去注册不同网站的用户，在不同站点的口令加密结果是不同的。鉴于有大量用户用同样的信息、同样的口令去注册不同网站，如果能做到这一点，流失出的库信息会进一步打折扣。而攻击者基本会放弃生成密文字典的尝试。 　　实现这些说起来很简单，依然是HASH+SALT，关键在于每个站点要有不同的SALT，每个用户要有不同的盐。 　　但如果攻击者不是只获得了库，而且也获得了相关的加密参数和密钥，我们就要看到攻击者依然可以自己通过相关参数和密钥调用算法，使用常见密码对每个用户生成一遍密文，然后是否有匹配。当然我们可以看到由于“每人一粒盐”的策略，攻击者所需要的计算代价已经变化了，如果过去只需要生成一次的话，那么假如使用100个常见的口令来做，那么只要口令没有碰撞到，对每个用户都要做100次加密操作。但这也是不容小觑的威胁。因为有太多用户喜欢使用那些常见口令。 　　因此，设定一个密码禁用表，让用户避免使用常见口令，可以进一步让破解者付出更大的代价，从而最终导致计算资源不收敛而放弃，也可以是一个可以考虑的策略。但也需要提醒WEB开发者的是，这样会增大你的用户忘记口令的风险。 　　另外，用户是否有把密码设置为123456的自由呢，我想只要不是国防、航天、涉密系统和有安全要求的企业环境，如果只是潜潜水、骂骂街，网站或许提醒用户就好，但也许并不需要做成强制策略。 　　具体的实现 　　了这么多，怎么来具体实现一站一密、一人一密的策略呢，号，我们想到与其空洞的说教算法原理和策略，不如提供一些非常直接的示例程序和文档。 　　因此同事们写了一份名为Antiy Password Mixer(安天密码混合器)的开源代码，当然这没有什么技术含量，也不是“自有知识产权的国产算法”，有的只是对实现较好的流行开源算法包的示范性使用而已，目前的Python版本，也只有三百行代码，在其中封装了RSA和HASH+SALT使用，并给出了具体的在初始化、注册和认证时如何使用的范例文档。 　　大家可以在这里找到这个东西：/p/password-mixer/ 　　当然，就像我们惋惜很多应用开发者缺乏对安全的重视一样，其实我们并不懂应用开发，所以这些代码和文档对于应用开发者看来可能非常丑陋。尽管可能被鄙视，我们还是要打开门，证明安全团队并不保守。 　　而同时，我们必须与应用走得更近，因为我们也在使用着这些自认为违反了某种安全原则的应用，却因为不是其开发者而无法改造它们。 　　过去的10余年，中国的Web应用甩开安全而飞速狂奔，开发者们凭借自身的勤奋和冲击力奠定了现有的格局，但也因快速地奔跑遗落了一些东西，比如安全。也许现在是拾起这些弃物的时间了。 　　中国的安全界则因保守、敏感和很多自身的原因，与应用的距离越拉越远，在我们还在幻想某些完美的安全图景时，发现我们已经望不到应用的脊背了。也许，在应用会回头等等我们的时候，就是我们加速前行、拾起应用所遗落的安全性，追送上去的时间了。
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具如何大幅提高加密数据库的安全性 -
| 关注黑客与极客
如何大幅提高加密数据库的安全性
共83702人围观
，发现 5 个不明物体
数据库加密越来越常见，但与此同时还是有一些因缺乏加密而造成的情况。姑且认为你已经部署了所有的安全措施，并且开发进程中的每一步都经过深思熟虑；开发出的web应用程序也有足够的能力对抗跨站脚本攻击、SQL注入和其他常见的web漏洞；并且熟知所有的安全计划（OWASP）条款，也知道对所有的传输数据、敏感数据库、数据库中的敏感字段加密。但接下来你会将加密密钥放在哪里呢？有没有使用硬件安全模块（HSM）？大多数企业都没有使用HSM，其实为了安全他们应该都要使用的。存储明文密码就相当于将钥匙放在门垫上，完全没有安全意识。
Web应用程序框架
让我们先来恶补一下常见的Web应用程序框架。在一个典型的数据库加密Web应用程序中，应用程序会直接将密钥存储在服务器的某个角落。这样就被置于了逆向工程攻击之列，并且还会造成一些操作性的安全问题。这就是不使用HSM的后果，所以各位程序猿们赶紧使用HSM吧。
Freebuf科普：什么是HSM？
一个HSM本质上就是一个协同处理器。就计算机架构而言，HSM可能含有冯诺依曼机的所有组件——包括储存、内存以及处理能力。计算机采用二进制算法和内存贮器后，指令和数据便可以一起存放在存贮器中，并可作同样处理，这样，不仅可以使计算机的结构大大简化，而且为实现运算控制自动化和提高运算速度提供了良好的条件。
HSM为主机本身提供专用离线加密服务。
HSM致力于处理加密和保护加密进程，服务器内存不能访问重要数据，用户也无法看到明文密钥，因此可以保证应用程序和加密数据中间存在一个可信任的路径。这个时候你可能会想到还有可能被物理入侵呢，其实不用担心，HSM拥有一个防干扰的密封圈，可阻止攻击者的电子窃听和无线电监测。
HSM可以用来防范什么？
HSM可以防止攻击者从一个敏感数据库中盗取信息。如果攻击者获得了应用服务器（储存了明文密钥）的访问特权，密码可以重新找回。无论密码有多复杂，哪怕是被编译、被打包或者被更改，它也能给逆向工程了。从安全工程的角度来看，这不是一种最佳的方式。
从操作安全的角度看，让别人看到敏感、加密数据都是不明智的。其中包括终端用户，还有开发团队、系统管理员以及数据库管理员。从系统角度看，你同样不希望看到敏感数据从产品服务器传播到工作服务器或开发服务器上。??如果你的数据库含有敏感数据，最好不要让任何人访问它。??
HSM是如何实施的？
因为HSM是由一个应用程序开发团队部署，它是属于程序安全领域，而不是基础设施安全。硬件安全模块能够被应用程序用于建立一个安全、可靠的通路。应用程序必须使用HSM供应商提供的应用程序编程接口（API）建立专门执行加密的操作。这些API包括常见的加密功能，如对称算法、非对称算法和解密操作，散列消息身份验证代码，密码信息身份验证代码，RSA，数字签名算法，Diffie-Hellman密钥交换，随机数生成，素数生成以及格式保存生成。HSM程序编程接口可以由特定的供应商提供，比如IBM发布的，或遵循公共标准，如PKCS 11。显然，有人会需要做一些谨慎的购物来确保适当的功能可用。
遵从FIPS-140-2标准
然而HSM不受PCI合规的托管，它们为大多数支付方案使用。当前HSM的管理标准为来自美国国家标准和技术委员会，称为美国联邦信息处理标准（缩写：）。事实上，若你需要储存信用卡数据，你非常应该使用HSM。2009年PCI安全需求查看请点，2012年更新内容可以在查看。
当遵守FIPS-140-2标准的HSM被广泛运用于支付行业中，所有行业数据库的安全系数都得到了大幅提高。而需要牢记的是你的对网络犯罪而言比你的信用卡更具有价值，所以请保持警惕。
怎么开始使用加密？
幸运的是，拥有一个“票据交换所”，同时还有很多关于硬件安全模型的讨论，包括专为基于网络模块储存系统及其他定制的设计。然而，本文的目的是为HSM做一个高级的介绍，同时鼓励用户去和（一系列问答网站，每一个网站包含不同领域的问题）做一些深入的阅读。
* 参考来源：，转载请注明来自FreeBuf黑客与极客（）&
必须您当前尚未登录。
必须（保密）
be kind to one another
关注我们 分享每日精选文章