03 - 认证(Authentication)

- 认证因子(什么东西可以用来做认证凭证)
  A. Something you know
     只有你知道的东西。如：口令。
  B. Something you have
     只有你拥有的东西。如：你的银行卡、令牌、手机等。
  C. Something you are
     你身体上和别人不一样的东西。如：指纹、视网膜、声音、DNA等。
同时使用多种认证因子进行认证是更安全的做法。例如，到银行取钱，需要同时有卡和密码。
网银交易，需要USB Key和密码。

我们接触到的系统中，绝大多数只使用了一种认证因子，也是最简单的一种，即口令认证
(Something you know)。认证凭证也是数据，也会遭遇‘数据’一节中提到的威胁。因为认证凭证的
特殊性，我们通常不使用‘数据’一节中介绍的对策，来保护认证凭证，而是采用专用的方法。

- 基于口令摘要的认证
  在‘密码学’一节中已经介绍了Hash算法，它的特点非常适合用在认证的过程中。
  A. 用户发送口令摘要(D1)到服务器
  B. 服务器从数据库获取用户的口令摘要(D2)
  C. 服务器验证D1=D2,成功则认证成功。

  基于口令摘要的认证有以下几个优点：
  A. 不需要传输明文口令
  B. 不能从摘要中得到明文口令
  C. 服务器端不需要存储明文口令

  到此为止，你可能认为口令的传输已经是安全的了，其实不然。
  威胁：重放攻击(Replay Attack)
  从上面的认证过程可以看出，认证凭证本质上是口令摘要。尽管没办法获取到明文口令，但是仍然可以
  通过Sinffing获取到口令摘要，甚至是整个认证过程的数据包。只要伪造一个合法的认证数据包发送到服
  务器，就能认证成功。

  对策：随机的消息认证码(Message Authentication Code)
  我们可以在每次认证时，用一个随机字符串和口令一起进行摘要。当然这个随机数必须要由服务器来指定,
  否则无效。认证的过程如下：
  A. 用户发送认证请求。
  B. 服务器发送一个随机数(R)给客户端。
  C. 客户端计算随机数(R)+口令摘要(D)的摘要CP1,并发送给服务器.
  D. 服务器从数据库获得口令摘要(D2)，计算R+D2的摘要CP2. 如果CP1=CP2,认证成功。

HMAC(Hash-based Message Authentication Code)是基于摘要算法的一个标准消息认证
算法，很适合用来做认证使用。

  威胁：彩虹表攻击(Rainbow Table Attack)
  彩虹表攻击本质上是字典攻击。攻击者首先对口令字典中的所有口令进行摘要，产生一个口令摘要字
  典(Rainbow Table). 然后把获取到的用户口令摘要和彩虹表比对。如果找到了同样的口令摘要，
  就找到了口令。此方法主要用来攻击存储在服务器端的口令摘要,还原用户口令。

  对策：随机串
  和随机的消息认证码机制类似，在服务器端不存储口令的摘要而是(口令+随机串)的摘要。
  A. 也有人用用户的其他信息(如用户名，ID)和口令一起摘要。但是在长度相同时，随机串强度更大。
     因此如果没有特殊的需求，还是推荐使用随机串。
  B. 有人将口令进行2次或N次摘要后存储。这是一种很不恰当的做法。

随机数和密钥一样，也是越长强度越高。随机数在整个密码学中起到了很重要的作用，因此不能小觑。
通常系统API或开发语言的库中都提供有获得随机数或字符串的函数。

- 一次性口令(One-Time Password|OTP)
本质上讲, 随机的消息认证码是一次性口令。这里还有其他更简单有效的一次性口令方式有：
A. 一次性口令令牌

Fig.1(来自WikiPedia)

B. 手机一次性口令
服务器发送一个随机串到用户的手机，用户以这个字符串作为密码进行认证。
结合令牌、手机和密码的双因子认证，更为安全可靠。

- 认证时服务器面临的威胁和对策
  威胁：口令猜测
  恶意人员通过猜测用户的口令，来尝试登录。

  对策1: 锁定帐号
  如果用户连续若干次认证失败，就锁定其帐号。只有通过其他途径解锁后才能继续使用。因为可能造成合
  法用户在一定时间内无法使用(拒绝服务DoS攻击)，所以实现这个功能时要谨慎。

  对策2: 告警和警告
  如果系统的安全要求不高，给用户和管理员发出告警日志就可以了。也要对正在尝试登录的用户发出警告。

  威胁：口令字典攻击
  口令字典是一个庞大的口令库，这些口令是通过各种途径收集到的。攻击者使用字典库中的口令尝试登录,尝
  试的过程往往通过特殊的软件自动进行，因此可以在很短的时间内尝试很多的口令。

  对策1：锁定账户一小段时间
  操作系统的本地登录，常使用这种方法。

  对策2：验证码
  验证码上展示了一些只有人才能分辨出的内容，如果字母，汉字，图表，地图，数学算式等。可以更
  好的阻止字典攻击。如下图所示：

Fig. 2(图片来自Wikipedia)

  对策3：使用良好的密码管理策略
  A. 要求用户的口令长度,如必须超过10个字符。
  B. 要求用户口令的复杂度，如必须包含数字、小写字母、大写字母和特殊字符。
  C. 定期更换密码，如6个月更换一次。
  D. 更换的密码不能重复使用。如每6个月更换一次密码，被更换的密码在4×6个月内不能再次使用。
  E. 构建口令字典，验证用户的密码不在口令字典中。

04 - 授权
  通常的系统都是采用基于角色的访问控制模型(Role-based access control model)。系统的操
  作一般可以归为三大类的角色：
  A. 系统的管理角色
  B. 应用用户的操作角色
  C. 审计(日志相关)的角色
  注重安全的系统，要奉行:
  A. 三权分离的原则
     一个用户只能拥有其中一种类型的角色权限。
  B. 最小权限原则
     在用户创建时，应给予0权限或最小权限。只有在用户需要某个权限时才授权。
  很多系统都设置有超级帐号，使用这种帐号可以做任何事情，或者授于管理员过多的权限。这样做
  肯能涉及到以下的几个问题：
  A. 误操作，导致数据被修改.
  B. 权限滥用。
  C. 帐号被盗，导致整个系统受到威胁.

05 - 访问控制
  威胁：拒绝服务攻击(DoS)
  由于某种特殊的情况出现，导致系统无法为合法的用户提供访问。

  对策：高安全意识
  导致DoS的原因有很多，有些是系统、网络层面的，也有来自于应用系统本身的原因。没有一个确切的
  办法能解决所有的问题。因此我觉的还是要高的安全意识来发现可能的问题。
  A. 网络层面的DoS攻击种类繁多，这和TCP/IP协议本身的实现有关。如果SOCKET的实现不恰当也会引入此
     类攻击。一个常见的例子是，Socket的等待队列设置的太小。如果有人故意的打开很多的半连接，就会造
     成其他用户无法连接。
  B. 多用户系统中，意味着这些用户要共享系统的资源。如内存，硬盘等。因此需要从这个方面来注意。
     当一个用户使用过大的内存或硬盘空间时，可能就造成了其他用户无法使用这些资源，甚至导致系统崩溃。

  威胁：不公平的服务
  现在常见的一种情况是，一些恶意的用户通过特殊的软件，来和其他用户抢系统提供的资源。如：特价
  商品，火车票等。从而导致系统不能为其他用户提供公平的服务。
  对策：验证码(同上)

  俗话说“病从口入”,软件系统也一样，下面的一些威胁，都是从用户输入开始的。
  威胁：SQL注入(SQL Injection)
  威胁：缓冲区溢出(Buffer Overflow)
  威胁：跨站脚本(XSS)
  此三中攻击手段是目前很常用，杀伤力很大的手段。具体的原理，大家可以在网上找到很多文章。

  对策：提高安全意识，对待用户输入紧小慎微
  不要假设用户输入的是正确的数据，不要认为用户都是无知的。据调查多数的攻击行为都来自于内部。因此
  对用户的输入要进行严格的约束和检查。
  A. 访问控制相关的逻辑信息不要放在客户端。
  B. 不要相信客户端的输入检查程序，必须在服务器端再次做输入合法性检查。

  对策：使用专业的软件来阻止攻击
  对用户的输入进行严格的检查也并不一定能有很好的效果。如果系统的安全需求较高，请向安全专家进行
  咨询。并配以专业的软件来预防此类攻击的发生。

- 数据库系统
  数据库中存储着系统的核心-数据，而很多攻击者的目标也是这些数据。因此要对数据库做严格的安全措施。
  A. 系统层面的安全
  B. 网路层面的安全
  C. 数据库本身的安全加固
  这些安全措施和软件开发本身没有太大的关系，因此不在这里详细描述了。
  D. 值得一提的是，数据库的帐号管理。数据库数据信息被盗的主要威胁来自于SQL注入和特权帐号被滥用。
     都和帐号管理相关。因此必须根据前面提到的口令管理策略，做好数据库的帐号管理。曾经碰到过程序员
     将Oracle的口令写入代码中,而导致无法对数据库进行加固的情况。这是非常错误的做法。
     另外要注意，良好的帐号管理只能减少SQL注入带来的损失，没办法阻止SQL注入的发生，因此还是要
     从输入检查上入手，去杜绝SQL注入的发生。

06 - 后记
  很多系统在开发的时候对安全问题并不重视，只有出了安全问题后才开始修修补补。随着安全事件的越来越多，
  要清醒的认识到，安全不是始于系统上线，而是始于需求分析。
  安全涉及到很多方面的知识，本文没有也不可能详述这些内容，只是希望能够提高大家的安全意识。文中的
  许多英文术语都可以通过Wikipedia查到，需要了解详细内容的朋友可以上去浏览。

建议继续学习：

1. 腾讯执行的感悟（安全方向）    (阅读：4936)
2. 如何让ssh登录更加安全    (阅读：4492)
3. 微博架构与平台安全演讲稿    (阅读：3786)
4. 为flash建立socket安全策略文件服务器    (阅读：3682)
5. php.ini安全配置及使用说明    (阅读：3517)
6. 查看你服务器的安全性    (阅读：3313)
7. IT从业人员需要知道的安全知识(1)    (阅读：3335)
8. 淘宝网：前端安全须知    (阅读：2942)
9. Mysql 安全    (阅读：2751)
10. jQuery之保证你的代码安全    (阅读：2543)