未验证 提交 69991d7e 编写于 作者: O openharmony_ci 提交者: Gitee

!10085 fix docs style

Merge pull request !10085 from NEEN/master
......@@ -27,13 +27,22 @@
**说明**:算法的安全性不在于算法本身的机密性。
**示例**:推荐使用的密码算法:
1)分组密码算法:AES(密钥长度在128位及以上)
2)流密码算法:AES(密钥长度在128位及以上)(OFB或CTR模式)
3)非对称加密算法:RSA(推荐3072位)
4)哈希算法:SHA2(256位及以上)
5)密钥交换算法:DH(推荐3072位)
6)HMAC(基于哈希的消息验证码)算法:HMAC-SHA2
不安全的密码算法举例如下:MD5/DES/3DES(加密传输协议TLS/SSH密码协议中避免使用3DES,非密码协议场景必须保证密钥K1≠K2≠K3)/HMAC-SHA2-256-96/HMAC-SHA1-96/HMAC-MD5/HMAC-MD5-96/SSH服务所有带CBC模式的算法/匿名算法套件/DH512/DH1024/SKIPJACK/RC2/RSA(1024位及以下)/MD2/MD4/blowfish/RC4。
不安全的密码算法举例如下:
MD5/DES/3DES(加密传输协议TLS/SSH密码协议中避免使用3DES,非密码协议场景必须保证密钥K1≠K2≠K3)/HMAC-SHA2-256-96/HMAC-SHA1-96/HMAC-MD5/HMAC-MD5-96/SSH服务所有带CBC模式的算法/匿名算法套件/DH512/DH1024/SKIPJACK/RC2/RSA(1024位及以下)/MD2/MD4/blowfish/RC4。
3-2 除标准协议外,避免使用差错控制编码(如奇偶校验、CRC)实现完整性校验。
3-3 密码算法中使用到的随机数必须是密码学意义上的安全随机数。
......@@ -41,10 +50,16 @@
**说明**:使用了不安全的随机数,容易导致密码算法的强度降低甚至算法的失效。
**示例**:可使用以下的安全随机数生成接口:
1) OpenSSL的RAND_bytes或RAND_priv_bytes;
2) OpenSSL FIPS模块中实现的DRBG;
3) JDK的java.security.SecureRandom;
4)类Unix平台的/dev/random文件
- OpenSSL的RAND_bytes或RAND_priv_bytes
- OpenSSL FIPS模块中实现的DRBG
- JDK的java.security.SecureRandom
- 类Unix平台的/dev/random文件
3-4 默认使用安全的密码算法,关闭或者禁用不安全的密码算法。在选择密码算法库时,应使用通过认证的或业界开源公认的或经评估认可的密码算法库。
......@@ -80,12 +95,19 @@
**示例**:截短消息认证码的配置举例:SSH协议中配置HMAC-MD5-96、HMAC-SHA1-96、HMAC-SHA2-256-96
哈希算法的标准输出长度如下,低于标准长度可视为截短:
1)SHA1/HMAC-SHA1,标准输出长度160比特
2)SHA224/HMAC-SHA224,标准输出长度224比特
3)SHA256/HMAC-SHA256,标准输出长度256比特
4)SHA384/HMAC-SHA384,标准输出长度384比特
5)SHA512/HMAC-SHA512,标准输出长度512比特
6)SHA-512/224/HMAC-SHA-512/224,标准输出长度224比特
7)SHA512/256/HMAC-SHA-512/256,标准输出长度256比特
3-13 使用HMAC保护数据完整性时,不能使用hash(key||message)或hash(message||key)的计算结果作为MAC值。
......@@ -94,7 +116,8 @@
3-14 同一笔业务中,若既需要加密运算也需要计算MAC时,加密操作和计算MAC操作不能使用同一个对称密钥。
**说明**:如果加密和MAC密钥相同,一旦密钥泄露,攻击者可以有针对性的篡改机密信息。
**说明**:如果加密和MAC密钥相同,一旦密钥泄露,攻击者可以有针对性的篡改机密信息。
3-15 加密时避免使用固定的IV(如:硬编码,或固定在配置文件中)。
**说明**:CBC模式的随机IV值可确保相同的明文、相同的密钥加密出的密文完全不同,如果IV无法确保每次加密都不同,对于CBC模式,攻击者可以轻易的进行密文替换攻击;CBC模式之外的其他分组密码运算模式(如:OFB、CRT等),攻击者可以非常容易的解密密文。
......@@ -103,7 +126,8 @@
**说明**:容易造成安全上的薄弱环节从而降低系统的安全性。
**示例**:匿名认证举例:TLS_DH_anon_WITH_3DES_EDE_CBC_SHA、TLS_DH_anon_WITH_AES_256_CBC_SHA
**示例**
匿名认证举例:TLS_DH_anon_WITH_3DES_EDE_CBC_SHA、TLS_DH_anon_WITH_AES_256_CBC_SHA
弱身份认证举例:密钥长度小于2048比特的RSA/DSA密钥
3-17 推荐仅选择使用ECDHE作为密钥交换算法的加密套件。
......@@ -128,9 +152,13 @@
4-2 认证凭据不需要还原的场景,应使用PBKDF2等不可逆的算法加密,对于性能敏感且安全性要求不高的场景可使用HMAC(认证凭据,盐值)(注:认证凭据、盐值位置可以互换)。
**示例**:1、认证凭据使用PBKDF2算法计算口令单向哈希时,迭代次数最低1000次。
2、盐值Salt为密码学意义上的安全随机数,由系统随机生成,盐值salt至少16字节,并按用户区分。
3、避免使用HASH(用户名||口令)、HMAC(用户名,口令)、HASH(口令 XOR salt)。
**示例**
1、认证凭据使用PBKDF2算法计算口令单向哈希时,迭代次数最低1000次。
2、盐值Salt为密码学意义上的安全随机数,由系统随机生成,盐值salt至少16字节,并按用户区分。
3、避免使用HASH(用户名||口令)、HMAC(用户名,口令)、HASH(口令 XOR salt)。
4-3 敏感数据如需通过非信任网络传输,应支持安全传输通道或者将数据加密后再传输的机制。
......@@ -140,11 +168,7 @@
## 5.系统管理和维护安全
5-1 对于系统自身操作维护类的接口的登录认证场景,应综合考虑实际业务场景及风险,采取下述一种或几种保护措施,实现口令防暴力破解机制:
1)锁定帐号;
2)锁定IP;
3)登录延迟;
4)验证码;
5-1 对于系统自身操作维护类的接口的登录认证场景,应综合考虑实际业务场景及风险,采取一种或几种保护措施,实现口令防暴力破解机制:锁定帐号、锁定IP、登录延迟、验证码。
5-2 对于系统自身操作维护类的口令,图形界面缺省不明文显示用户键入的所有口令。
......@@ -152,7 +176,10 @@
5-4 应使用合适的安全协议,不安全协议应默认关闭。
**示例**:安全协议举例:SSHv2/TLS1.2/TLS1.3/IPSec/SFTP/SNMPv3等协议,及其业界最新安全版本。对于流密码算法,建议使用AES的OFB和CTR模式或chacha20流加密算法替换RC4算法。
**示例**
安全协议举例:SSHv2/TLS1.2/TLS1.3/IPSec/SFTP/SNMPv3等协议,及其业界最新安全版本。对于流密码算法,建议使用AES的OFB和CTR模式或chacha20流加密算法替换RC4算法。
不安全协议举例:TFTP、FTP、Telnet、SSL2.0、SSL3.0、TLS1.0、TLS1.1、SNMP v1/v2和SSHv1.x。
5-5 基于权限最小化原则,系统新建账号默认不授予任何权限,或者默认只指派最小权限(如:只读权限)的角色。
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册