接上文《IT从业人员需要知道的安全知识(1)》

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. 一次性口令令牌


B. 手机一次性口令

服务器发送一个随机串到用户的手机，用户以这个字符串作为密码进行认证。

结合令牌、手机和密码的双因子认证，更为安全可靠。

- 认证时服务器面临的威胁和对策

  威胁：口令猜测
  恶意人员通过猜测用户的口令，来尝试登录。
  对策1: 锁定帐号
  如果用户连续若干次认证失败，就锁定其帐号。只有通过其他途径解锁后才能继续使用。因为可能造成合法用户在一定时间内无法使用(拒绝服务DoS攻击)，所以实现这个功能时要谨慎。
  对策2: 告警和警告
  如果系统的安全要求不高，给用户和管理员发出告警日志就可以了。也要对正在尝试登录的用户发出警告。
  威胁：口令字典攻击
  口令字典是一个庞大的口令库，这些口令是通过各种途径收集到的。攻击者使用字典库中的口令尝试登录,尝试的过程往往通过特殊的软件自动进行，因此可以在很短的时间内尝试很多的口令。
  对策1：锁定账户一小段时间
  操作系统的本地登录，常使用这种方法。
  对策2：验证码
  验证码上展示了一些只有人才能分辨出的内容，如果字母，汉字，图表，地图，数学算式等。可以更好的阻止字典攻击。如下图所示：


  对策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查到，需要了解详细内容的朋友可以上去浏览。