身份验证

近日，粤港澳大湾区规范翻新联盟正式公布了《基于互联网的可信数字身份服务技术要求》大湾区个人规范，该规范由腾讯科技（深圳）有限公司提出，粤港澳大湾区规范翻新联盟归口，腾讯科技（深圳）有限公司、腾讯科技（北京）有限公司、北京数字认证股份有限公司、中国科学院信息工程研究所、广东省商用明码协会、上海市数字证书认证核心有限公司、广州大学、华南农业大学、华南师范大学、暨南大学、安讯奔（香港）科技有限公司、上海银基信息安全技术股份有限公司、深圳市电子商务平安证书治理有限公司、北京安讯奔科技有限责任公司、澳门智慧城市联盟协会、香港大学、北京京东世纪贸易有限公司独特起草。 2021年3月，国家公布了《中华人民共和国国民经济和社会倒退第十四个五年布局和2035年近景指标大纲》，激励互联网+公共服务，定义了10个典型的数字化利用场景，如智能政务、智能交通、智慧出行、智慧文旅、智慧能源等。粤港澳大湾区也相继公布或踊跃对接“十四五”布局，抢抓数字技术产业改革时机。 可信数字身份服务作为数字化转型期间的基础设施，也亟需适配新机遇和新场景所提出的要求。腾讯平安联结腾讯规范、政务协同、企业IT、智慧出行、云开发等多方团队，及上述的优良的产学研组织个人，基于各自丰盛的实践经验，独特编制《基于互联网的可信数字身份服务技术要求》大湾区个人规范。 标准规定了可信数字身份服务的基础架构和分级分类、性能要求、性能要求、平安要求、利用集成要求和互操作性要求等内容。规范从服务整体能力的角度登程，制订实用于湾区的通用技术要求，同时思考粤港澳地区的互操作性制订身份标识和信赖体系互联互通的技术要求。规范能够保障互联网环境下可信数字身份服务的规范性和安全性，更好的服务湾区政治、经济、文化和社会生存的倒退。 作为粤港澳大湾区首个可信数字身份方面的大湾区个人规范，该规范的公布能够无效撑持数字政府、智慧城市、数字生态等国家关注的重点利用场景，广泛应用在大湾区金融、证券、交通、出行、文旅、批发、工业、医疗、教育等各行各业中，作为数字化转型时代的平安基座施展重要作用，市场利用场景微小。 近年来，腾讯平安对在互联网场景下的可信数字身份方向进行了宽泛的摸索和实际，在政务、医疗、文旅、交通、出行等行业都落地积淀了胜利案例。在数字政务、医疗畛域，腾讯可信数字身份解决方案已服务20+个省市级、400+市县的民生利用，30+城市衰弱码利用，10+个城市的智慧医疗我的项目；在出行畛域，腾讯摸索落地了数字车钥匙产品，为行业与用户提供更加安全可靠的产品与服务。截至发稿日，腾讯已为各类互联网利用实现超过1000亿次可信身份认证。

1、token是什么？token是一种用户标识，表示用户身份，类似于我们的身份证件。Token 是在服务端产生的。如果前端使用用户名/密码向服务端请求认证，服务端认证成功，那么在服务端会返回 Token 给前端。前端可以在每次请求的时候带上 Token 证明自己的合法地位。如果这个 Token 在服务端持久化（比如存入数据库），那它就是一个永久的身份令牌。 2、为什么要使用token？先来了解一下token认证与session认证的区别：a) Session认证Session认证的方案为：第一次用户认证请求通过时，服务器端存储用户的登录信息，然后在响应时传递给浏览器，浏览器保存为cookie，下次请求时把cookie发送给服务器，服务器根据cookie信息来识别是哪个用户。Session认证适用于单个服务器的场合，如果用户增多，需要部署多个服务器时，Session认证就会暴露问题。因为每个用户在认证后，服务器都会记录Session，一般保存在内存中，随着认证用户增多，服务器开销也会增大；而且认证用户的后续请求都需要到这台保存了自己Session的服务器上验证Cookie。在多集群分布式的场合，这就造成了性能瓶颈，对负载均衡、应用的扩展都会造成影响。（不能多服务共享）进程外Session通过将Session保存在数据库或硬盘中可以解决服务器内存开销的问题，但仍然不便于扩展。 b) Token认证Token认证也是无状态的，不需要在服务端保存认证用户的信息，它的认证流程为：用户使用用户名密码请求服务器；服务器验证用户，如果验证通过就发给用户一个token；客户端保存token，并在之后的每次请求都附上token；服务端验证token、返回数据。Token认证机制不需要保存认证用户的信息、也不需要考录用户在那台服务器登录，可以很好地适应应用的扩展（可以多服务共享）。token的体积很小，请求服务端时，可以被附在URL、Header或是Post参数中。而且token中包含了用户相关的必要、非私密的相信，免去了服务端再次查询数据库的开销另外，token认证能解决以下问题： Token 完全由应用管理，所以它可以避开同源策略Token 可以避免 CSRF 攻击Token 可以是无状态的，可以在多个服务间共享现在详细说明以下roken为什么能够避免CSRF攻击呢？CSRF攻击又是什么意思？ 2.1、CSRF攻击CSRF（Cross-site request forgery）也被称为 one-click attack或者 session riding，中文全称是叫跨站请求伪造。一般来说，攻击者通过伪造用户的浏览器的请求，向访问一个用户自己曾经认证访问过的网站发送出去，使目标网站接收并误以为是用户的真实操作而去执行命令。常用于盗取账号、转账、发送虚假消息等。攻击者利用网站对请求的验证漏洞而实现这样的攻击行为，网站能够确认请求来源于用户的浏览器，却不能验证请求是否源于用户的真实意愿下的操作行为。 2.2、token如何避免CSRF攻击CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的 cookie 来通过安全验证。要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。 3、使用JWT生成和验证token以下代码仅仅用于示意，并不是完整版。 3.1、采用HS256算法生成和验证后台生成token： const jwt = require('jsonwebtoken')const fs = require('fs')// Token 数据const payload = { name: 'wanghao', admin: true}/** * HS256 * 用 HS256 算法生成与验证 JWT */// 密钥const secret = 'ILOVENINGHAO'// 签发 Tokenconst token = jwt.sign(payload, secret, { expiresIn: '1day' })// 输出签发的 Tokenconsole.log('HS256 算法：', token)拦截器验证： ...

来源 | 愿码(ChainDesk.CN)内容编辑愿码Slogan | 连接每个程序员的故事网站 | http://chaindesk.cn愿码愿景 | 打造全学科IT系统免费课程，助力小白用户、初级工程师0成本免费系统学习、低成本进阶，帮助BAT一线资深工程师成长并利用自身优势创造睡后收入。官方公众号 | 愿码 | 愿码服务号 | 区块链部落免费加入愿码全思维工程师社群 | 任一公众号回复“愿码”两个字获取入群二维码本文阅读时长：11minPostgreSQL中的身份验证身份验证回答了问题：谁是用户？PostgreSQL支持一些 身份验证方法，包括以下内容：· Trust认证：任何可以连接到服务器的人都有权使用访问pg_hba.conf配置文件中指定的数据库/数据库。通常用于允许在单个用户计算机上使用Unix域套接字进行连接以访问数据库。此方法也可以与TCP / IP一起使用，但很少允许从本地主机以外的任何IP地址进行连接。 · Ident认证：这通过从ident服务器获取客户端的操作系统用户名然后使用它来访问数据库服务器来工作。这个方法建议用于客户端计算机受系统管理员严格控制的封闭网络。· Peer认证：这类似于身份，但客户端操作系统用户名是从内核获得的。· GSSAPI认证：GSSAPI是RFC2743中定义的行业标准。它提供自动身份验证（单点登录）。· LDAP认证： LDAP服务器仅用于验证用户名/密码对。· 密码认证：有以下三种方法o SCRAM-SHA-256：PostgreSQL 10中引入的最强的身份验证方法。此方法可防止对不受信任的连接进行密码嗅探。默认密码验证方法是MD5使用此功能，配置参数 password_encryption应更改为 scram-sha-256o MD5：MD5具有已知的限制，例如：预先计算的查找表以破解密码哈希。此外，MD5只有40亿个独特的哈希值。最后，MD5计算速度非常快，因此暴力密码猜测不需要大量的CPU资源。对于新应用程序，建议仅使用scram-sha-256。此外，PostgreSQL提供了从scram-sha-256迁移的方法。o Password：建议不要使用此密码，因为密码以明文格式发送到服务器。 要了解身份验证，您需要具有以下信息：· 身份验证通过pg_hba.conf文件控制，其中hba代表基于主机的身份验证。· 最好了解PostgreSQL发行版附带的默认初始身份验证设置· pg_hba.conf文件通常位于数据目录中，但也可以在postgresql.conf配置文件中指定。更改身份验证时，您需要发送一个SIGHUP信号，这是通过基于PostgreSQL平台的几种方法完成的。注意，发送信号的用户应该是超级用户、Postgres或Linux发行版上的根系统用户；同样，这取决于平台。以下是重新加载PostgreSQL配置的几种方法的示例：psql -U postgres -c “SELECT pg_reload_conf();“sudo service postgresql reloadsudo /etc/init.d/postgresql reloadsudo Kill -HUP sudo systemctl reload postgresql-11.service· 该订单的 pg_hba.conf记录或条目是非常重要的。将会话连接pg_hba.conf逐个与记录进行比较， 直到它被拒绝或到达配置文件的末尾。· 最后，检查PostgreSQL日志文件以确定配置重新加载后是否存在错误是非常重要的。PostgreSQL pg_hba.conf与postgresql.conf一样，pg_hba.conf文件由一组记录组成，可以使用哈希符号注释行，并且忽略空格。pg_hba.conf文件记录的结构如下：host_type database user [IP-address| address] [IP-mask] auth-method [auth-options]host_type查询的部分可以是以下内容：· Local：在 Linux系统中使用，允许用户使用Unix域套接字连接访问PostgreSQL。· Host：这是为了允许来自其他主机的连接，基于地址或IP地址，使用带有和不带SSL加密的TCP / IP。· Hostssl：这与主机类似，但应使用SSL加密连接。· Hostnossl：这也与主机类似，但不应加密连接。查询的数据库部分是用户想要连接的数据库的名称。为了提高灵活性，您还可以使用以逗号分隔的列表来指定多个数据库，或者可以all用来指示用户可以访问数据库集群中的所有数据库。此外，可以使用相同的用户和相同的角色值来指示数据库名称与用户名相同，或者用户是与数据库同名的角色的成员。查询的用户部分指定数据库用户的名称； 同样，all值与所有用户匹配。IP地址，地址和IP子网掩码用于标识用户所在的主机尝试连接。可以使用无类别域间路由（CIDR）或点十进制表示法指定IP地址。最后，密码验证方法可以信任，MD5，拒绝等。以下是配置PostgreSQL身份验证的一些典型示例：· 示例1：PostgreSQL集群上的任何用户都可以使用Unix域套接字访问任何数据库，如以下数据库表所示：#TYPE DATABASE USER ADDRESS METHODLocal all all trust· 示例2：PostgreSQL集群上的任何用户都可以使用本地环回IP地址访问任何数据库，如以下数据库表所示：#TYPE DATABASE USER ADDRESS METHODHost all all 127.0.0.1/32 trusthost all all ::1/128 trust· 示例3：192.168.0.53拒绝来自IP地址的所有连接 ，来自192.168.0.1/24范围的连接被接受，如下数据库表所示：#TYPE DATABASE USER ADDRESS METHODHost all all 192.168.0.53/32 rejectHost all all 192.168.0.1/24 trustPostgreSQL提供了一种非常方便的方法来查看pg_hba.conf文件中定义的规则，方法是提供一个名为pg_hba_file_rules的视图，如下所示：postgres=# SELECT row_to_json(pg_hba_file_rules, true) FROM pg_hba_file_rules limit 1; row_to_json ————————- {“line_number”:84, + “type”:“local”, + “database”:[“all”], + “user_name”:[“all”], + “address”:null, + “netmask”:null, + “auth_method”:“trust”,+ “options”:null, + “error”:null}(1 row)侦听地址该listen_addresses 选项定义于postgresql.conf。PostgreSQL listen_addresses连接设置用于标识服务器应从客户端应用程序侦听的IP地址列表。这些listen_addresses是以逗号分隔的主机名或IP地址列表。更改这个值需要重启服务器。此外，还应注意以下几点：· 默认值为localhost，它限制从网络到PostgreSQL集群的直接连接。· 给出一个空列表意味着服务器应该只接受Unix套接字连接· 该值*表示全部对于新加入PostgreSQL的开发人员来说，忘记更改侦听地址是一个常见的错误。如果开发人员忘记更改，并尝试使用网络中的TCP/IP连接到PostgreSQL，则会出现以下错误：Connection refused Is the server running on host and accepting TCP/IP connections on port 5432?认证最佳实践身份验证最佳实践取决于整个基础架构设置，应用程序的性质，用户的特征，数据敏感性等。例如，以下设置对于初创公司很常见：数据库应用程序（包括数据库服务器）托管在同一台计算机上，并且仅由公司内部用户从一个物理位置使用。通常，数据库服务器使用防火墙与世界隔离；在这种情况下，您可以使用SCRAM-SHA-256身份验证方法并限制IP地址，以便数据库服务器接受特定范围或集合内的连接。请注意，重要的是不要使用超级用户或数据库所有者帐户连接到数据库，因为如果此帐户被黑客入侵，则整个数据库集群将被暴露。如果是应用服务器 - 业务逻辑 - 和数据库服务器不在同一台机器上，您可以使用强大的身份验证方法，例如LDAP和Kerberos。但是，对于数据库服务器和应用程序位于同一台计算机上的小型应用程序，SCRAM-SHA-256身份验证方法以及将侦听地址限制为localhost可能就足够了。要对应用程序进行身份验证，建议仅使用一个用户，并尝试使用连接池软件减少允许的最大连接数，以便更好地调整PostgreSQL资源。在应用业务逻辑时可能需要另一级别的安全性来区分不同的登录用户。对于真实用户，更需要LDAP或Kerberos身份验证。此外，如果从外部世界访问数据库服务器，则使用SSL证书加密会话以避免数据包嗅探很有用。您还应该记住保护信任所有localhost连接的数据库服务器，因为访问localhost的任何人都可以访问数据库服务器。角色系统和代理身份验证通常，在设计应用程序时，登录角色用于配置数据库连接和连接工具。需要实现另一级安全性以确保使用该应用程序的用户被授权执行某项任务。该逻辑通常在应用程序业务逻辑中实现。在使用事务块中的SET SESSION AUTHORIZATION 语句或SET ROLE命令建立或重用连接后，通过将身份验证委派给另一个角色，数据库的角色系统也可用于部分实现此逻辑，如下所示：postgres=# SELECT session_user, current_user; session_user | current_user ————–+————– postgres | postgres(1 row)postgres=# SET SESSION AUTHORIZATION test_user;SETpostgres=> SELECT session_user, current_user; session_user | current_user ————–+————– test_user | test_user(1 row)设置角色需要角色成员资格，而设置会话授权需要超级用户权限。允许应用程序作为超级用户进行连接是危险的，因为可以分别使用reset role和reset session命令重置set session authorization和set role命令，从而允许应用程序获得超级用户权限。为了了解如何使用PostgreSQL角色系统来实现身份验证和授权，我们将使用角色系统和汽车门户应用程序。在汽车门户应用程序中，可以将多组用户分类为web-app-user、public-user、registered-user、seller-user和admin-user。web应用程序用户用于配置业务逻辑连接工具；公共用户、注册用户和卖家用户用于区分用户。公共用户组只能访问公共信息，如广告，但不能作为注册用户添加评级，也不能创建广告，因为卖家用户。管理员用户是管理应用程序所有内容的超级角色，例如过滤垃圾邮件和删除不遵守网站策略的用户。当汽车门户网站应用程序连接到数据库时，将使用Web用户。之后，car_portal将根据用户类调用set role命令。这种身份验证方法称为代理身份验证。以下示例演示了如何使用角色系统来实现代理身份验证。第一步是创建角色并分配角色成员身份和权限，如下所示：CREATE ROLE web_app_user LOGIN NOINHERIT;CREATE ROLE public_user NOLOGIN;GRANT SELECT ON car_portal_app.advertisement_picture, car_portal_app.advertisement_rating , car_portal_app.advertisement TO public_user;GRANT public_user TO web_app_user;GRANT USAGE ON SCHEMA car_portal_app TO web_app_user, public_user;该NOINHERIT选项web_app_user 不允许用户继承角色成员资格的权限；但是，web_app_user可以将角色更改为公共用户，如以下示例所示：$ psql car_portal -U web_app_usercar_portal=> SELECT * FROM car_portal_app.advertisement;ERROR: permission denied for relation advertisementcar_portal=> SET ROLE public_user;SETcar_portal=> SELECT * FROM car_portal_app.advertisement; advertisement_id | advertisement_date | car_id | seller_account_id ——————+——————–+——–+——————-(0 rows)car_portal=> SELECT session_user, current_user; session_user | current_user ————–+————– web_app_user | public_user(1 row) ...

作者：Daniel Feldman介绍联邦信任域是SPIFFE和SPIRE最高需求和活跃开发的功能之一。在这篇博文中，我将概述我们当前的计划以及实施它的挑战。什么是联邦？SPIFFE信任域中的证书共享一个信任根。 这是一个根信任捆绑包，由使用非标准化格式和协议在控制平面之间和内部共享的多个证书组成。然而，这还不够好。许多组织都有多个信任根源：可能是因为他们与不同的管理员有不同的组织划分，或者因为他们有偶尔需要沟通的独立的临时和生产环境。类似的用例是组织之间的SPIFFE互操作性，例如云供应商与其客户之间的互操作性。这两种用例都需要一个定义明确、可互操作的方法，以便一个信任域中的工作负载对不同信任域中的工作负载进行身份验证。这是联邦。联邦设计要实现联邦，我们必须在不同的SPIFFE服务器之间共享公钥。这不是一次性操作；由于密钥轮换，每个信任域的公钥会定期更改。每个联邦域必须定期下载其他域的公钥，其频率至少与密钥轮换一样快。定期下载证书的数据格式尚未最终确定。我们目前的想法是让SPIFFE的实现去使用JWKS格式，在一个众所周知的URL上公开发布证书。然后，要启动联邦关系，实现可以下载JWKS数据，并从中导入证书。我们喜欢JWKS，因为它是一种通用的、可扩展的格式，用于共享可以容纳JWT和X.509证书的密钥信息。（出于安全原因，SPIFFE需要不同的JWT和X.509标识的密钥材料 - 它们不能只是以不同格式编码的相同公钥。）JWKS的灵活性允许单个联邦API支持JWT和X.509 。工作负载APISPIFFE工作负载API提供用于读取联邦公钥的端点。此API与用于读取当前信任域的证书的API不同，所以应用程序可以区分本地和联邦域的客户端。SPIRE的实验支持虽然它尚未正式标准化为SPIFFE的一部分，但是SPIRE已经可以提供JWKS的实验性实施。挑战外部SPIFFE服务器的初始身份验证联邦API存在引导问题：如果双方都没有共享信任根，则无法建立初始安全连接。其一种解决方案，是使用两个SPIFFE服务器信任的证书颁发机构的Web PKI。另一种解决方案，是使用手动身份验证机制来消除对公共证书颁发机构（CA）的需求。SPIRE使用与节点和工作负载注册类似的方式实现联邦。随着我们扩展注册API，可以通过该API操作联邦，就像节点和工作负载注册一样。网络中断容错每次SPIFFE实现，从同等的SPIFFE实现，导入新证书时，它都会使用上一个已知捆绑包对连接进行身份验证。如果网络中断很长，并且两个SPIFFE实现无法通信，超过完整的密钥轮换周期，那么它们将无法继续进行通信，从而破坏了联邦关系。其一种解决方案，是将密钥轮换间隔，设置为长于可能的最长网络中断长度（或者如果发生长中断，则重新初始化联邦）。这是设计权衡：如果密钥轮换间隔较长，则受损密钥也将在较长时间内保持有效。或者，如果Web PKI可用于SPIFFE服务器，则可用于保护联邦连接。我们相信联邦SPIFFE服务器之间的Web PKI，将是一种常见的设计模式，因为它避免了长网络中断导致密钥轮换的问题。传递与双向联邦Kerberos和Active Directory具有与联邦相同的，称为“跨领域信任”。在大多数情况下，跨领域信任是双向的（双方互相信任）和传递（如果A信任B，B信任C，然后A信托C）。SPIFFE中的双向联邦通常（但并非总是如此）是可取的。对于公共API，API提供程序可能希望使用Web PKI来保护连接的服务器端，并使用SPIFFE来保护客户端。因此，我们不会自动配置双向联邦。对于具有许多信任域的大型组织，传递联邦可以简化实现复杂性。但是，传递联邦可能难以推断SPIFFE实现的安全属性。出于这个原因，我们现在没有在SPIFFE中实现传递联邦。目前，用户必须通过添加更多联邦关系，来手动配置传递和双向联邦。联邦信任域SVID的范围在Web PKI中，每个人都信任相同的根证书颁发机构。在SPIFFE中，彼此不完全信任的组织可能仍希望联邦其信任域。应用程序必须验证每个SVID是否由拥有该信任域的SPIFFE服务器颁发。想象一个奇怪的世界，可口可乐和百事可乐必须交换数据。为此，他们联邦各自的信任域。可口可乐的SPIFFE证书根，添加到百事可乐的信托商店，反之亦然。在证书验证的简单实现中，可口可乐服务器可以欺骗性地冒充百事可乐网络上的百事可乐服务器，因为百事可乐信任可口可乐的根证书！这是问题所在：根证书没有“范围”。任何CA都可以为任何名称签署证书。如果所有CA都受信任，例如在单个公司内，则可以。在具有多个CA的环境中，每个CA都应该只允许签署具有特定名称的证书，不然这会导致安全漏洞。防止这种情况的一种方法是使用X.509名称约束扩展。名称约束扩展允许将CA证书限制为为特定域名颁发证书。但是，在TLS库中对名称约束扩展的支持是有限的，并且它不能解决未来SPIFFE身份格式（如JWT）的问题。由于这些原因，SPIFFE不包括名称约束扩展。这意味着所有使用SVID的应用程序都必须检查SVID中的SPIFFE ID，是否与签署证书的实际CA的信任域匹配。这意味着检查百事可乐SVID不是被可口可乐的CA签名。当前广泛使用的应用程序（例如Web服务器和代理）不执行此检查。结论联邦对于SPIFFE的成功实施至关重要。但是，以安全和可用的方式实施它仍然存在挑战。我们正在努力与社区一起努力应对这些挑战，如果您有远见，我们很乐意听取您的意见！要了解有关SPIFFE联邦的更多信息：查看新的Java SPIFFE Federation Demo，它演示了在Tomcat服务器环境中使用SPIRE在两个域之间进行联邦。加入SPIFFE Slack与专家讨论SPIFFE。加入SPIFFE SIG-SPEC双月会议，设计SPIFFE联邦会的未来。 （不久将有一个单独的联邦工作组。）