• 何谓身份认证

    身份认证(Authentication)的目的是鉴别系统的访问者是否是合法用户,即访问者确实是其所声明的名义人本人而非冒名顶替者。

    基本方法

    对用户的身份认证基本方法可以分为这四种

    根据你所知道的信息来证明你的身份
    最基本的密码验证即属于这一类根据你所拥有的东西来证明你的身份
    手机短信验证即属于这一类直接根据独一无二的身体特征来证明你的身份
    指纹认证,静脉认证,人脸识别认证属于这一类委托第三方认证
    网站里常见的社交(SNS)账号登陆即属于这一类 实现技术

    身份认证的系统实现技术有很多,大致如下:

    BasicKerberosOAuthOpenIDSAMLJWT
  • 简介

    Basic身份认证,是HTTP 1.0中引入的认证方案之一,也被称为基本身份认证。 在Basic身份认证中,用户名和密码由冒号“:”连接,用Base64编码并发送。因此,它具有易于窃听和篡改的缺点,但由于它几乎与所有Web服务器和浏览器兼容,因此被广泛使用。为了防止窃听和篡改,后来出现的Digest身份认证技术对Basic身份认证的安全缺陷做了一定的改进。

    认证流程

    Basic身份认证的典型流程如下图所示:

    1. 用户访问受限资源 HTTP请求例:

    GET /employee/index.html HTTP/1.1 Host: psteam.co.jp

    2. 服务端返回401要求身份认证

    HTTP回复例:

    HTTP/1.1 401 Authorization Required Date: Wed, 11 May 2014 07:50:26 GMT Server: Apache/1.3.33 (Linux) WWW-Authenticate: Basic realm="SECRET AREA" Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1

    3. 用户发送认证请求 客户端提示用户输入用户名密码,发送认证请求给服务器端 HTTP请求例:

    /employee/index.html HTTP/1.1 Host: psteam.co.jp Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

    4. 服务端验证请求 HTTP回复例:

    HTTP/1.1 200 OK Date: Wed, 11 May 2014 07:50:26 GMT

    补充说明:

    如果第3步用户选择取消输入用户名密码,认证流程则当即中止如果第4步用户名密码错误,服务器将再次返回401错误,认证流程重回第3步 认证实现 Apache

    Apache里实现Basic认证包含以下两大步骤:

    创建用户管理文件
    要执行基本身份验证,需要创建一个由用户名和密码组成的管理文件。可以使用一个名为htpasswd的程序来创建文件和用户注册。配置htaccess文件
    在需要Basic认证的目录下,创建.htaccsss文件,内容大致如下: AuthUserFile /home/webadmin/.htpasswd AuthGroupFile /dev/null AuthName "Please Enter Your Password" AuthType Basic Require valid-user

    包含以下设置项目:

    AuthUserFile 
    指定步骤1里创建的用户管理文件名。AuthGroupFile 
    指定群组文件AuthName 
    指定客户端用户名密码输入对话框里显示的提示信息AuthType 
    指定认证方式为BasicRequire 
    指定允许访问的用户或群组,「valid-user」表示、允许用户管理文件包含的所有用户。 个别指定的时候,多个用户或群组名可用空格区分。 NodeJS

    如果使用Express,利用express-basic-auth中间件可以很简单的就能实现Basic认证。

  • 何谓单点登录

    什么是单点登录?单点登录(英:Single Sign On,简称SSO),是一种使用单个ID和密码进行身份验证以访问多个Web网站和服务的机制。

    单点登录现在在WEB世界获得了广泛的应用,很多网站支持的Google、Github、Facebook、Twitter、微信、QQ等第三方账号登录就属于单点登录。

    现在说起单点登录,一般指的都是Web SSO,但实际上,单点登录并不限于Web应用,也不是一项新技术,十多年来它已被很多大型企业用户应用在本地系统。

    单点登录的效果

    单点登录里用户的认证处理统一在一个地方集中管理,这有以下几个效果:

    方便管理
    包括用户和管理员
    用户使用应用系统时,能够一次登录,多次使用。用户不再需要每次输入用户名称和用户密码,也不需要牢记多套用户名称和用户密码。
    系统管理员只需要维护一套统一的用户账号,方便、简单。提高安全
    将ID /密码集中在一起统一加强安全管理,泄漏的风险可以降低。
    当然,一旦泄露,影响也是更加灾难性的。简化开发
    开发新的应用系统时,可以直接使用单点登录平台的用户认证服务。主要实现方式

    同一个域名下的各个Web应用可以通过共享Cookie从而很简单的就能实现单点登录。
    但如果要考虑跨域,单点登录的实现方式主要有代理人(英:Agent)、反向代理(英:Reverse proxy)、 联合身份验证(英:Federated Identity)等方式。

    代理人方式

    代理人方式通过将代理软件嵌入Web服务器中来实现身份验证。

    反向代理方式

    反向代理方式通过在Web浏览器和Web应用程序之间安装反向代理服务器并在其中安装身份验证代理来实现身份验证。

    联合身份验证方式联合身份验证(英:Federated Identity)通过把用户身份的验证过程与被该用户访问的服务提供商(英:Service Provider,简称SP)进行逻辑分离,在保证用户身份信息被隔离在用户所属系统的内部的同时,为受信任的服务提供商提供所需要的用户信息。

    当服务提供商需要对用户的身份进行验证时,会将相关的验证过程转交给身份验证提供方(英:Identity Provider,简称IdP),当用户经由身份验证提供方成功登录后,身份验证提供方会将用户的身份验证凭据和用户相关的信息返还给服务提供商,从而实现服务提供商对于用户身份的验证,以及对于用户信息获取。
    联合身份验证方式可以在不使用cookie的情况下在不同域之间打包传输认证信息,也能实现云服务SSO。

    常见的联合身份验证的实现有SAML、OpenID、JWT及OAuth等,

    (SAML)

    SAML(全称:Security Assertion Markup Language,安全断言标记语言,发音sam-el)是一个基于XML格式传输用户认证信息的开放标准。

    (OpenID Connect)

    OpenID Connect 是一套基于 OAuth 2.0 协议的轻量认证级规范,提供通过 API 进行身份交互的框架。


    (JWT)

    JWT(全称:Json Web Token)是一个基于JSON格式传输用户认证信息的开放标准。

    JWT将用户信息加密到token里,服务器不保存任何用户信息。服务器通过使用保存的密钥验证token的正确性,只要正确即通过验证。

    优点是在分布式系统中,很好地解决了单点登录问题,很容易解决了session共享的问题。缺点是无法作废已颁布的令牌/不易应对数据过期。

    (OAuth2)

    OAuth本质上只是一个授权框架而不是身份认证协议,但在第三方账号登录里被直接当作身份认证机制而获得广泛应用。

  • 信息安全 68 0 1 发布

    介绍定义

    公钥基础设施PKI(Public Key Infrastructure),是一种遵循既定标准的密钥管理平台,它能够为所有网络应用提供加密和数字签名等密码服务及所必需的密钥和证书管理体系,简单来说,PKI就是利用公钥理论和技术建立的提供安全服务的基础设施。PKI技术是信息安全技术的核心,也是电子商务的关键和基础技术。

    目的

    PKI技术能够为网络通信和网络交易,特别是电子政务和电子商务业务,透明地提供一整套安全服务,主要包括身份认证、保密、数据完整性和不可否认性。
    作为一种基础设施,PKI的应用范围非常广泛,并且在不断发展之中,下面给出几个常见的应用场景。

    虚拟专用网络VPN(Virtual Private Network)
    VPN是一种构建在公用通信基础设施上的专用数据通信网络,利用网络层安全协议(如IPSec)和建立在PKI上的加密与数字签名技术来获得机密性保护。安全电子邮件
    电子邮件的安全也要求机密、完整、认证和不可否认,而这些都可以利用PKI技术来实现。目前发展很快的安全/多用途Internet邮件扩充协议S/MIME(Secure/Multipurpose Internet Mail Extensions),是一个允许发送加密和有签名邮件的协议,该协议的实现需要依赖于PKI技术。Web安全
    为了透明地解决Web的安全问题,在两个实体进行通信之前,先要建立SSL(Secure Sockets Layer,安全套接层)连接,以此实现对应用层透明的安全通信。利用PKI技术,SSL协议允许在浏览器和服务器之间进行加密通信。此外,服务器端和浏览器端通信时双方可以通过数字证书确认对方的身份。受益

    用户受益

    通过PKI证书认证技术,用户可以验证接入设备的合法性,从而可以保证用户接入安全、合法的网络中。
    通过PKI加密技术,可以保证网络中传输的数据的安全性,数据不会被篡改和窥探。
    通过PKI签名技术,可以保证数据的私密性,未授权的设备和用户无法查看该数据。

    企业受益

    企业可以防止非法用户接入企业网络中。
    企业分支之间可以建立安全通道,保证企业数据的安全性。

    PKI基本概念公钥加密算法

    公钥加密算法,又叫非对称加密算法或双钥加密算法,是指加密密钥和解密密钥为两个不同密钥的密码算法。

    公钥加密算法使用了一对密钥:一个用于加密信息,另一个则用于解密信息,其中加密密钥公之于众,称为公钥;解密密钥由解密人私密保存,称为私钥。用其中任一个密钥加密的信息只能用另一个密钥进行解密。

    RSA密钥对

    数字证书机制依赖于公共密钥体制,PKI系统中应用最广泛的公共密钥体制为RSA加密系统。

    RSA加密系统使用一个非对称的RSA密钥对,包括一个RSA公钥和一个RSA私钥。当实体申请数字证书时,证书请求中必须包含RSA公钥信息。

    RSA密钥对的模数,即RSA密钥的长度(单位bit)。模数越大,密钥越安全,同时设备生成密钥、加密、解密花费的时间也越长。

    数字指纹

    数字指纹是指通过某种算法对数据信息进行综合计算得到的一个固定长度的数字序列,这个序列有时也称信息摘要,常采用单向哈希算法对原始数据进行散列计算得出数字指纹。

    数字签名

    数字签名是指信息发送方用自己的私钥对原始数据的数字指纹进行加密后所得的数据。

    信息接收者使用信息发送者的公钥对附在原始信息后的数字签名进行解密后,获得数字指纹,然后与自己用同样算法对原始数据计算生成的数据指纹进行匹配,根据匹配结果,便可确定原始信息是否被篡改。

    数字证书

    数字证书是一个经认证机构CA(Certificate Authority)签名的,包含实体公开密钥及相关身份信息的文件,它建立了实体身份信息与其公钥的关联,是使用PKI系统的用户建立安全通信的信任基础。CA对数字证书的签名保证了证书的合法性和权威性。

    数字证书中包含多个字段,包括证书签发者的名称、主体的公钥信息、CA对证书的数字签名、证书的有效期等。

    本地(local)证书和CA(Certificate Authority)证书

    本地证书是CA签发给实体的数字证书;CA证书是CA自身的证书。若PKI系统中存在多个CA,则会形成一个CA层次结构,最上层的CA是根CA,它拥有一个CA“自签名”的证书。

    证书废除列表CRL

    由于实体名称的改变、私钥泄漏或业务中止等原因,需要存在一种方法将现行的证书撤消,即撤消公开密钥及相关的实体身份信息的绑定关系。在PKI中,所使用的这种方法为证书废除列表CRL(Certificate Revocation List)。

    任何一个证书被废除以后,CA就要发布CRL来声明该证书是无效的,并列出所有被废除的证书的序列号。CRL提供了一种检验证书有效性的方式。

    当一个CRL的撤消信息过多时会导致CRL的发布规模变得非常庞大,且随着CRL大小的增加,网络资源的使用性能也会随之下降。为了避免这种情况,允许一个CA的撤消信息通过多个CRL发布出来,并且使用CRL发布点CDP(CRL Distribution Point)来指出这些CRL的位置。

    CRL发布点

    CRL发布点CDP,是数字证书中的信息,它描述了如何获取证书的CRL列表。
    最常用的CDP是HTTP URL和LDAP URL,也可以是其他类型的URL或LDAP目录说明。
    一个CDP包含一个URL或目录说明。

    PKI体系架构PKI架构

    如图1所示,一个PKI体系由终端实体、认证机构、注册机构和证书/CRL存储库四部分共同组成。

    终端实体
    终端实体是PKI产品或服务的最终使用者,可以是个人、组织、设备(如路由器、交换机)或计算机中运行的进程。认证机构CA(Certificate Authority)
    CA是PKI的信任基础,是一个用于签发并管理数字证书的可信实体。其作用包括:发放证书、规定证书的有效期和通过发布CRL确保必要时可以废除证书。注册机构RA(Registration Authority)
    RA是CA的延伸,可作为CA的一部分,也可以独立。RA功能包括个人身份审核、CRL管理、密钥对产生和密钥对备份等。PKI国际标准推荐由一个独立的RA来完成注册管理的任务,这样可以增强应用系统的安全性。证书/CRL存储库
    证书/CRL存储库负责证书和CRL的存储、管理、查询等。认证机构

    认证机构层次

    认证机构是PKI体系的核心,通常采用多层次的分级结构,根据证书颁发机构的层次,可以划分为根CA和从属CA。上级认证机构负责签发和管理下级认证机构的证书,最下一级的认证机构直接面向用户。每一份数字证书都与上一级的数字签名证书相关联,最终通过证书链追溯到一个根认证机构,根CA通常持有一个自签名证书。

    根CA是公钥体系中第一个证书颁发机构,它是信任的起源。根CA可以为其它CA颁发证书,也可以为其它计算机、用户、服务颁发证书。对大多数基于证书的应用程序来说,使用证书的认证都可以通过证书链追溯到根。从属CA必须从根CA或者从一个已由根CA授权可颁发从属CA证书的从属CA处获取证书。

    在建立CA时,从属CA要通过上级CA获得自己的CA证书,而根CA则是创建自签名的证书。

    认证机构类型

    认证机构CA的类型包括以下三种:

    自签名CA:在自签名CA中,证书中的公钥和用于验证证书签名的公钥是相同的。从属CA:在从属CA中,证书中的公钥和用于验证证书签名的公钥是不同的。根CA:根CA是一种特殊的CA,它受到客户无条件地信任,位于证书层次结构的最高层。所有证书链均终止于根CA。根CA必须对它自己的证书签名,因为在证书层次结构中再也没有更高的认证机构。

    认证机构功能

    CA的核心功能就是发放和管理数字证书,包括:证书的颁发、证书的更新、证书的撤销、证书的查询、证书的归档、CRL的发布等。具体描述如下:

    证书申请处理:接收、验证用户数字证书的申请。证书审批处理:确定是否接受用户数字证书的申请。证书颁发处理:向申请者颁发或拒绝颁发数字证书。证书更新处理:接收、处理用户的数字证书更新请求。证书查询和撤销处理:接收用户数字证书的查询、撤销。发布CRL:产生和发布证书废除列表(CRL)。证书的归档:数字证书的归档。密钥的备份和恢复。历史数据归档。注册机构

    RA是数字证书注册审批机构,RA是CA面对用户的窗口,是CA的证书发放、管理功能的延伸,它负责接受用户的证书注册和撤销申请,对用户的身份信息进行审查,并决定是否向CA提交签发或撤销数字证书的申请。
    RA作为CA功能的一部分,实际应用中,通常RA并不一定独立存在,而是和CA合并在一起。RA也可以独立出来,分担CA的一部分功能,减轻CA的压力,增强CA系统的安全性。

    PKI工作机制工作过程

    针对一个使用PKI的网络,配置PKI的目的就是为指定的实体向CA申请一个本地证书,并由设备对证书的有效性进行验证。PKI的工作过程如下:

    实体向注册机构RA提出证书申请。RA审核实体身份,将实体身份信息和公开密钥以数字签名的方式发送给CA。CA验证数字签名,同意实体的申请,颁发证书。RA接收CA返回的证书,通知实体证书发行成功。实体获取证书,利用该证书可以与其它实体使用加密、数字签名进行安全通信。实体希望撤消自己的证书时,向CA提交申请。CA批准实体撤消证书,并更新CRL。工作原理

    PKI的目标就是要充分利用公钥密码学的理论基础,建立起一种普遍适用的基础设施,为各种网络应用提供全面的安全服务。

    对于公钥加密算法,由于公钥是公开的,需要在网上传送,故公钥的管理问题就是公钥加密体制所需要解决的关键问题。目前,PKI系统中引出的数字证书机制就是一个很好的解决方案。PKI的核心技术就围绕着数字证书的申请、颁发、使用与撤销等整个生命周期进行展开。

    证书注册

    证书注册即证书申请,就是一个实体向CA自我介绍并获取数字证书的过程。实体向CA提供身份信息,以及相应的公钥,这些信息将成为颁发给该实体证书的主要组成部分。

    实体向CA提出证书申请,有离线和在线两种方式。离线申请方式下,CA允许申请者通过带外方式(如电话、磁盘、电子邮件等)向CA提供申请信息。在线证书申请有手工发起和自动发起两种方式。以下是常用的证书注册方式:

    PKCS#10方式(离线注册方式)
    当无法通过SCEP协议向CA在线申请证书时,可以使用PKCS#10格式打印出本地的证书申请信息。用户以PKCS#10格式保存证书申请信息到文件中,并通过带外方式发送给CA进行证书申请。SCEP方式(在线注册/下载方式)
    通过简单证书注册协议SCEP(Simple Certification Enrollment Protocol),利用HTTP协议与CA或RA通信,发送证书注册请求或证书下载请求消息,下载CA/RA证书、本地证书,或者申请本地证书。SCEP方式是最常用的证书自动注册方式。自签名证书
    PKI设备为自己颁发一个自签名证书,即证书签发者和证书主题相同。证书更新

    设备在证书即将过期前,先申请一个证书作为“影子证书”,在当前证书过期后,影子证书成为当前证书,完成证书更新功能。

    申请“影子证书”的过程,实质上是一个新的证书注册的过程。

    证书更新功能需要CA服务器的支持,即CA服务器必须支持证书更新功能。

    证书下载

    证书下载是指终端实体通过SCEP协议,向CA服务器查询并下载已颁发的证书,或者通过CDP指定机制和地址,下载已颁发的证书。该证书可以是自己的证书,也可以是CA证书,或其他终端实体的证书。

    证书撤销

    由于用户身份、用户信息或者用户公钥的改变、用户业务中止等原因,用户需要将自己的数字证书撤消,即撤消公钥与用户身份信息的绑定关系。在PKI中,CA撤销证书使用的方法为证书废除列表CRL,终端实体撤销自己的证书是通过带外方式申请的。

    为了撤销自己的证书,终端实体必须采用带外方式通知CA服务器管理员。

    管理员要求终端实体提供自己的Challenge Password(Challenge Password在证书注册时已作为PKCS10证书请求的属性发给了CA)。

    如果终端实体提供的Challenge Password与CA服务器保存的一致,CA发布CRL来撤销证书。

    CRL下载

    CA/RA不会主动把CRL发布给终端实体,而是由终端实体主动发起CRL查询。有两种下载CRL的方法:CDP方式、SCEP方式。

    CA如果支持CDP,在为终端实体颁发证书时,把CRL发布点的URL地址编码成CDP属性封装在证书中,终端实体根据CDP来下载CRL。

    如果证书中未携带CDP信息,并且设备本地也没有配置CDP的URL地址,则设备通过SCEP协议向CA服务器请求CRL。终端实体通过SCEP协议获取证书时,以证书签发者名字和证书序列号作为查询关键字。

    证书状态检查方式

    当终端实体验证对端证书时,经常需要检查对端证书是否有效,例如对端证书是否过期、是否被加入证书黑名单中,即检查证书的状态。通常终端实体检查证书状态的方式有三种:CRL方式、OCSP方式、None方式。

    CRL方式
    如果CA支持CDP,那么当CA签发证书时,在证书中会包含CDP信息,描述了获取该证书CRL的途径和方式。终端实体利用CDP中指定的机制和地址来定位和下载CRL。

    如果PKI域下配置了CDP的URL地址,该地址将覆盖证书中携带的CDP信息,终端实体使用配置的URL来获取CRL。

    在线证书状态协议OCSP(Online Certificate Status Protocol)方式
    如果CA不支持CDP,即证书中没有指定CDP,并且PKI域下也没有配置CRL的URL地址,终端实体可以使用OCSP协议检查证书状态。

    None方式
    如果终端实体没有可用的CRL和OCSP服务器,或者不需要检查对端证书状态,可以采用None方式,即不检查证书是否被撤销。

    证书合法性验证

    终端实体获取对端证书后,当需要对对端进行证书认证时,例如需要与对端建立安全隧道或安全连接,通常需要验证对端证书和证书签发者的合法性。如果证书签发者的证书无效或过期,则由该CA签发的所有证书都不再有效。但在CA证书过期前,设备会自动更新CA/RA证书,异常情况下才会出现CA证书过期现象。

    为完成证书验证,除了需要对端证书外,本地设备需要下面的信息:信任的CA证书、CRL、本端数字证书及其私钥、证书认证相关配置信息。

    证书验证的主要过程如下:

    使用CA证书的公钥验证认证机构的签名是否正确。根据证书的有效期,验证证书是否过期。检查证书的状态,即通过CRL、OCSP、None等方式检查证书是否被撤销。证书链验证

    为验证一个数字证书的合法性,首先需要获得签发这个证书的CA的公钥(即获得CA证书),以便检查该证书上CA的签名。一个CA可以让另一个更高层次的CA来证明其数字证书的合法性,这样顺着证书链,验证数字证书就变成了一个叠代过程,最终这个链必须在某个“信任点”(一般是持有自签名证书的根CA或者是实体信任的中间CA)处结束。

    所谓的证书链,是指从终端实体证书到根证书的一系列可信任证书构成的证书序列。任何终端实体,如果它们共享相同的根CA或子CA,并且已获取CA证书,都可以验证对端证书。一般情况下,当验证对端证书链时,验证过程在碰到第一个可信任的证书或CA机构时结束。

    证书链的验证过程是一个从目标证书(待验证的实体证书)到信任点证书逐层验证的过程。

    版权声明:转载自:http://blog.sina.com.cn/s/blog_afd4c4ef0102w20n.html

  • 信息安全 65 0 1 发布

    1、RSA身份验证的隐患

        身份验证和密钥协商是TLS的基础功能,要求的前提是合法的服务器掌握着对应的私钥。但RSA算法无法确保服务器身份的合法性,因为公钥并不包含服务器的信息,存在安全隐患:

        客户端C和服务器S进行通信,中间节点M截获了二者的通信;

        节点M自己计算产生一对公钥pub_M和私钥pri_M;

        C向S请求公钥时,M把自己的公钥pub_M发给了C;

        C使用公钥 pub_M加密的数据能够被M解密,因为M掌握对应的私钥pri_M,而 C无法根据公钥信息判断服务器的身份,从而 C和 M之间建立了"可信"加密连接;

        中间节点 M和服务器S之间再建立合法的连接,因此 C和 S之间通信被M完全掌握,M可以进行信息的窃听、篡改等操作。

        另外,服务器也可以对自己的发出的信息进行否认,不承认相关信息是自己发出。

        因此该方案下至少存在两类问题:中间人攻击和信息抵赖。

    2、身份验证CA和证书

        解决上述身份验证问题的关键是确保获取的公钥途径是合法的,能够验证服务器的身份信息,为此需要引入权威的第三方机构CA(如沃通CA)。CA 负责核实公钥的拥有者的信息,并颁发认证"证书",同时能够为使用者提供证书验证服务,即PKI体系(PKI基础知识)。

        基本的原理为,CA负责审核信息,然后对关键信息利用私钥进行"签名",公开对应的公钥,客户端可以利用公钥验证签名。CA也可以吊销已经签发的证书,基本的方式包括两类 CRL 文件和 OCSP。CA使用具体的流程如下:

        a.服务方S向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;

        b.CA通过线上、线下等多种手段验证申请者提供信息的真实性,如组织是否存在、企业是否合法,是否拥有域名的所有权等;

        c.如信息审核通过,CA会向申请者签发认证文件-证书。

    证书包含以下信息:申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文,同时包含一个签名;

    签名的产生算法:首先,使用散列函数计算公开的明文信息的信息摘要,然后,采用 CA的私钥对信息摘要进行加密,密文即签名;

        d.客户端 C 向服务器 S 发出请求时,S 返回证书文件;

        e.客户端 C读取证书中的相关的明文信息,采用相同的散列函数计算得到信息摘要,然后,利用对应 CA的公钥解密签名数据,对比证书的信息摘要,如果一致,则可以确认证书的合法性,即公钥合法;

        f.客户端然后验证证书相关的域名信息、有效时间等信息;

        g.客户端会内置信任CA的证书信息(包含公钥),如果CA不被信任,则找不到对应 CA的证书,证书也会被判定非法。

    在这个过程注意几点:

        a.申请证书不需要提供私钥,确保私钥永远只能服务器掌握;

        b.证书的合法性仍然依赖于非对称加密算法,证书主要是增加了服务器信息以及签名;

        c.内置 CA 对应的证书称为根证书,颁发者和使用者相同,自己为自己签名,即自签名证书(为什么说"部署自签SSL证书非常不安全")

        d.证书=公钥+申请者与颁发者信息+签名;

     ★即便有人截取服务器A证书,再发给客户端,想冒充服务器A,也无法实现。因为证书和url的域名是绑定的。

    3、证书链

        如 CA根证书和服务器证书中间增加一级证书机构,即中间证书,证书的产生和验证原理不变,只是增加一层验证,只要最后能够被任何信任的CA根证书验证合法即可。

        a.服务器证书 server.pem 的签发者为中间证书机构 inter,inter 根据证书 inter.pem 验证 server.pem 确实为自己签发的有效证书;

        b.中间证书 inter.pem 的签发 CA 为 root,root 根据证书 root.pem 验证 inter.pem 为自己签发的合法证书;

        c.客户端内置信任 CA 的 root.pem 证书,因此服务器证书 server.pem 的被信任。

    服务器证书、中间证书与根证书在一起组合成一条合法的证书链,证书链的验证是自下而上的信任传递的过程。

    二级证书结构存在的优势:

        a.减少根证书结构的管理工作量,可以更高效的进行证书的审核与签发;

        b.根证书一般内置在客户端中,私钥一般离线存储,一旦私钥泄露,则吊销过程非常困难,无法及时补救;

        c.中间证书结构的私钥泄露,则可以快速在线吊销,并重新为用户签发新的证书;

        d.证书链四级以内一般不会对 HTTPS 的性能造成明显影响。

    证书链有以下特点:

        a.同一本服务器证书可能存在多条合法的证书链。

        因为证书的生成和验证基础是公钥和私钥对,如果采用相同的公钥和私钥生成不同的中间证书,针对被签发者而言,该签发机构都是合法的 CA,不同的是中间证书的签发机构不同;

        b.不同证书链的层级不一定相同,可能二级、三级或四级证书链。

        中间证书的签发机构可能是根证书机构也可能是另一个中间证书机构,所以证书链层级不一定相同。

    4、证书吊销

        CA 机构能够签发证书,同样也存在机制宣布以往签发的证书无效。证书使用者不合法,CA 需要废弃该证书;或者私钥丢失,使用者申请让证书无效。主要存在两类机制:CRL 与 OCSP。

        a.CRL

        Certificate Revocation List, 证书吊销列表(什么是证书吊销列表(CRL)?吊销列表起什么作用),一个单独的文件。该文件包含了 CA 已经吊销的证书序列号(唯一)与吊销日期,同时该文件包含生效日期并通知下次更新该文件的时间,当然该文件必然包含 CA 私钥的签名以验证文件的合法性。

    证书中一般会包含一个 URL 地址 CRL Distribution Point,通知使用者去哪里下载对应的 CRL 以校验证书是否吊销。该吊销方式的优点是不需要频繁更新,但是不能及时吊销证书,因为 CRL 更新时间一般是几天,这期间可能已经造成了极大损失。

        b.OCSP

    Online Certificate Status Protocol, 证书状态在线查询协议,一个实时查询证书是否吊销的方式。请求者发送证书的信息并请求查询,服务器返回正常、吊销或未知中的任何一个状态。证书中一般也会包含一个 OCSP 的 URL 地址,要求查询服务器具有良好的性能。部分 CA 或大部分的自签 CA (根证书)都是未提供 CRL 或 OCSP 地址的,对于吊销证书会是一件非常麻烦的事情。

    版权声明:本文转载自https://blog.csdn.net/hherima/article/details/52469488

  • 信息安全 96 0 1 发布

    概述

    HTTPS (Secure Hypertext Transfer Protocol)安全超文本传输协议,是一个安全通信通道,它基于HTTP开发用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换,简单来说它是HTTP的安全版,是使用TLS/SSL加密的HTTP协议。
    HTTP协议采用明文传输信息,存在信息窃听、信息篡改和信息劫持的风险,而协议TLS/SSL具有身份验证、信息加密和完整性校验的功能,可以避免此类问题发生。

    TLS/SSL全称安全传输层协议Transport Layer Security, 是介于TCP和HTTP之间的一层安全协议,不影响原有的TCP协议和HTTP协议,所以使用HTTPS基本上不需要对HTTP页面进行太多的改造。


    HTTPS和HTTP的区别是什么?


    什么是HTTPS

    HTTPS是在HTTP上建立SSL加密层,并对传输数据进行加密,是HTTP协议的安全版。HTTPS主要作用是:

    对数据进行加密,并建立一个信息安全通道,来保证传输过程中的数据安全;对网站服务器进行真实身份认证。什么是HTTP

     HTTP是互联网上应用最为广泛的一种网络协议,是一个客户端和服务器端请求和应答的标准(TCP),用于从WWW服务器传输超文本到本地浏览器的传输协议。HTTP是采用明文形式进行数据传输,极易被不法份子窃取和篡改。

    HTTPS和HTTP的区别   HTTPS是加密传输协议,HTTP是名文传输协议;   HTTPS需要用到SSL证书,而HTTP不用;   HTTPS比HTTP更加安全,对搜索引擎更友好,利于SEO【参考:(1)为保护用户隐私安全,谷歌优先索引HTTPS网页、(2)百度开放收录https站点,https全网化势不可挡】;   HTTPS标准端口443,HTTP标准端口80;   HTTPS基于传输层,HTTP基于应用层;   HTTPS在浏览器显示绿色安全锁,HTTP没有显示;

     总的来说HTTPS比HTTP更加安全,能够有效的保护网站用户的隐私信息安全,这也是为什么现在的HTTPS网站越来越多。如果不想你的网站因为数据泄露上头条的话,就赶快去申请一张SSL证书为自己的网站实现HTTPS加密吧!

    原文链接:https://blog.csdn.net/hherima/article/details/52469267

热门总结

  • 何谓身份认证

    身份认证(Authentication)的目的是鉴别系统的访问者是否是合法用户,即访问者确实是其所声明的名义人本人而非冒名顶替者。

    基本方法

    对用户的身份认证基本方法可以分为这四种

    根据你所知道的信息来证明你的身份
    最基本的密码验证即属于这一类根据你所拥有的东西来证明你的身份
    手机短信验证即属于这一类直接根据独一无二的身体特征来证明你的身份
    指纹认证,静脉认证,人脸识别认证属于这一类委托第三方认证
    网站里常见的社交(SNS)账号登陆即属于这一类 实现技术

    身份认证的系统实现技术有很多,大致如下:

    BasicKerberosOAuthOpenIDSAMLJWT
  • OpenAM 186 0 1 发布

    本文说明的是如何将OpenAM作为OAuth2认证服务器,包括如何配置OAuth2服务和如何创建OAuth2客户端。

    配置OAuth2服务

    以管理员身份登录OpenAM

    (创建服务器设置)

    点击【Config OAuth2/OpenID Connect】按钮

    适当延长Token的有效期限,点击【Create】按钮

    设置创建成功


    (动作确认)

    OpenAM的OAuth服务器の各Endpoint可通过访问以下的URL获得。

    {OpenAM的URL}/.well-known/openid-configuration

    { response_types_supported: [ token id_token ,code token ,code token id_token ,token ,code id_token ,code ,id_token ] ,registration_endpoint: http://passport.utilhub.dt.hudaokeji.com/openam/oauth2/connect/register (string) ,token_endpoint: http://passport.utilhub.dt.hudaokeji.com/openam/oauth2/access_token (string) ,end_session_endpoint: http://passport.utilhub.dt.hudaokeji.com/openam/oauth2/connect/endSession (string) ,version: 3.0 (string) ,userinfo_endpoint: http://passport.utilhub.dt.hudaokeji.com/openam/oauth2/userinfo (string) ,subject_types_supported: [ public ] ,issuer: http://passport.utilhub.dt.hudaokeji.com/openam (string) ,jwks_uri: http://passport.utilhub.dt.hudaokeji.com/openam/oauth2/connect/jwk_uri (string) ,id_token_signing_alg_values_supported: [ HS256 ,HS512 ,RS256 ,HS384 ] ,check_session_iframe: http://passport.utilhub.dt.hudaokeji.com/openam/oauth2/connect/checkSession (string) ,claims_supported: [ phone ,email ,address ,openid ,profile ] ,authorization_endpoint: http://passport.utilhub.dt.hudaokeji.com/openam/oauth2/authorize (string)  } 创建OAuth2客户端

    以管理员身份登陆openAM

    (新建OAuth2客户端)

    进入【Access Control】→ 【(Top Level Realm)】 → 【Agent】 → 【OAuth 2.0/OpenID Connect Client】,点击【Agent–>New】

    输入Name和Password(这里的Name和Password分别等同于Client ID 和 Client Secret),点击【Create】

    创建成功

    点击创建好的OAuth2/OpenID Connect客户端,进入OAuth2客户端详细设置画面。

    (配置OAuth2客户端)

    输入回调URL


    指定Scope

    指定显示名和描述,这些信息将作为提示信息在用户登录的时候被显示

    指定Default Scope

    (其他)

    第三方用户需要为自己的应用服务登录OAUth2客户端时,可使用以下URL。

    {OpenAM的URL}/oauth2/registerClient.jsp

  • OpenAM 185 0 1 发布

    本文说明的是如何以PolicyAgent方式搭建基于OpenAM的单点登录系统。

    基本机制

    Policy Agent方法通过在运行应用程序的服务器上安装Policy Agent,监视HTTP通信来实现。

    (体系结构)


    (处理流程)

    The web client requests access to a protected resource.The web server runs the request through the policy agent that protects the resource according to OpenAM policy. The policy agent acts to enforce policy, whereas the policy configuration and decisions are handled by OpenAM.The policy agent communicates with OpenAM to get the policy decision to enforce.For a resource to which OpenAM approves access, the policy agent allows access.The web server returns the requested access to the web client创建和设置Agent

    以管理员身份登录OpenAM

    (选择Realm)

    点击Access Control

    选择已有或创建新的Realm,这里选择缺省存在的Top Level Realm

    (创建Agent)

    选择Agent页

    在Web页里点击New按钮,创建新的WebAgent

    属于Agent信息,包括名字,密码,OpenAM服务器的URL,应用程序的URL

    点击Save按钮,保存Agent

    (设置SSO Only Mode)

    (配置Cookie)

    (配置跨域认证)



    安装Web服务器端代理

    (安装Apache)

    选择XAMPP安装版 XAMPP for Windows 5.6.11 (Apache版本:2.4)

    127.0.0.1 apache-pa-test.local.com


    (安装OpenAM-Agent)

    下载OpenAM-Agent

    (Agent设定)






    动作确认







  • ADFS(全称:Active Directory Federation Services,活动目录联合服务)是由微软自Windows Server 2003 R2起,在各个Server版本操作系统中提供的一个软件组件,其最新版本是集成在Windows Server 2012 R2的AD FS 3.0。

    简介

    ADFS使用基于Claims的访问控制验证模型来实现联合认证。它提供 Web 单一登录技术,这样只要在会话的有效期内,就可对一次性的对用户所访问的多个Web应用程序进行验证。

    我们可以将 ADFS 理解为组织域内与公网之外用户桥梁。我们编写的应用程序作为Internet服务在公网部署,当程序需要对域内的用户进行验证时,就可以委托 ADFS 服务器进行验证。 ADFS 服务提供了一个 AD FS 联合服务器代理,这类似于一个只提供了登录界面的应用程序,我们将相关域用户的验证过程委托给该程序进行处理,该程序将提示用户输入验证凭据(这可以是在浏览器中弹出登录提示框或跳转到一个登录页面的形式),随后其将所获取的凭据传递给AD FS联合身份验证服务。 AD FS 作为AD的一部分有权限(其拥有AD域管理员的权限)使用AD DS的标准方式认证一个域内的用户,如果认证成功,AD FS 将会依据应用程序预先设定的信息需求,以Claims的形式将安全令牌信息返还给我们的应用程序。


    关于Claims

    在基于Claims的联合身份验证的过程中,当身份验证提供方完成对于用户身份的验证,返还用户的相关信息时,其数据信息实体被称之为令牌(Token),其中的相关信息字段被称为声明(Claims)。令牌保证了用户身份的真实性,并包含了实用信息,其结构如下图所示。

    基于传统的开发方式,创建一个应用程序(即服务提供商)并保证多种身份验证机制可以协调工作并不是一件简单的工作。首先,我们需要决定对于特定的应用程序,哪一种身份验证技术最为合适。如果应用程序允许用户通过不同的方式进行访问,例如,允许同属一个组织下的域用户群体,或者跨越不同组织的多个域下的域用户群体,再或者同时允许这些域用户及传统的注册用户通过公网对应用程序进行访问,那么使用传统的单一的身份验证机制是完全不能满足这些需求的。在这些需求下,应用程序应该以直接经由用户所属的组织或系统处获取对应用户验证的结果。同时,也需要从一个AD目录服务或其它某处查询到用户相关的信息,并且保证这些信息可以在公网上,能够以统一的方式进行传递。
    基于Claims的身份验证(Claims-based identity)为我们提供了这种统一的身份验证方式,让不同的服务提供商可以通过公网,获得所需要的保存在用户所属组织内部的关于用户的验证信息。其基本流程如下图所示。

    首先,用户通过客户端(如浏览器),访问服务提供商(如图中①过程,相对于身份验证提供方也可以称其为信赖方RP)。信赖方向身份验证提供方提出验证请求(如图中②所示),身份验证提供方会要求用户输入登陆凭据(如用户名及验证码)。在通过其验证确认后,身份验证提供方会将验证成功的消息及该用户相关的数据信息以令牌的方式交还给信赖方(如图中③所示)。

    以我的站点与某第三方联合身份验证系统的验证流程为例,其过程也可以用如下的时序图阐明。

    如前所述,我们涉及到两个新的概念,依赖方与安全令牌服务。
    信赖方(RP,Relying Party)就相当于服务提供商,也就是由我们构建的依赖声明的应用程序(如我的网站)。信赖方有时也被称为“声明感知应用程序”或“基于声明的应用程序”。信赖方作为应用程序需要使用由安全令牌服务(STS)所颁发的令牌,并从令牌中提取声明,从而进行用户身份的验证和用户信息的获取。
    安全令牌服务(STS,Security Token Service),信赖方所使用的令牌的创建者就是安全令牌服务。它作为一个Web服务存在。STS可以由我们自行构建,也可以应用已有的实现,AD联合身份验证服务(AD FS)就是一个STS的实现。
    为了充分利用基于Claims的身份验证机制,我们将会使用由微软提供的用于支撑应用程序实现联合认证功能的可供依赖的基础架构。这些技术包括:AD联合身份验证服务(AD FS,Active Directory Federation Services),与Windows身份验证基础类库(WIF,Windows Identity Foundation)。

    关于WIF

    Windows身份验证基础类库(WIF,Windows Identity Foundation)是一组.NET Framework类,它为我们提供了实现基于声明标识的应用程序的基础框架。在具体的实现过程中,主要利用了其中的WSFederation Authentication Module(WS-FAM)HTTP模块。

    概念总结

    以上给出的相关概念层层递进,相似的概念在不同领域层次有着不同的称谓,为了方便理解,下面对这些概念的关系进行简单的总结。

    AD FS中的称谓SAML中的称谓概念简述Security Token 安全令牌Assertion 声明作为安全信息的封装,用于描述一个用户的信息,它在联合身份验证的访问请求期间被创建。Claims Provider 声明提供方Identity Provider (IdP) 身份验证提供方为用户创建安全令牌的联合身份认证程序。Relying Party 信赖方Service Provider (SP) 服务提供商收到联合身份验证服务信赖的请求并使用安全令牌的应用程序。Claims 声明Assertion attributes 属性声明在安全令牌中的关于用户的数据信息。

    下图对相关的领域结构进行了划分。

    (本文转载于Hendry's Blog)

  • OpenAM 126 0 1 发布

    本主题所说明的是如何在NodeJS服务器程序中通过连接到OpenAM服务器实现OAuth2/OpenID Connect认证。

    环境Node.js 0.10.22~Express 4.0~passport 0.2.1~express-generator创建OAuth2客户端

    在OpenAM服务器上为NodeJS服务器应用创建一个客户。

    clientID(name) : localhostclientSecret(password):testcallbackURL:http://localhost:3000/oauth2callback

    创建方法请参照OpenAM单点登录系统搭建(OAuth2认证篇)

    实现准备

    创建一个express应用程序框架

    express openam-connect cd openam-connect

    在package.json加入以下库

    "passport": "*", "passport-openidconnect": "*", "express-session": "*"

    安装所需要的库

    npm install修改app.jsvar express = require('express'); var path = require('path'); var favicon = require('serve-favicon'); var logger = require('morgan'); var cookieParser = require('cookie-parser'); var bodyParser = require('body-parser'); var routes = require('./routes/index'); var users = require('./routes/users'); var app = express(); var passport = require('passport'); var session = require('express-session'); var OpenidConnectStrategy = require('passport-openidconnect').Strategy; app.use(passport.initialize()); app.use(passport.session()); passport.use(new OpenidConnectStrategy({ authorizationURL: "http://passport.utilhub.dt.hudaokeji.com/openam/oauth2/authorize", tokenURL: "http://passport.utilhub.dt.hudaokeji.com/openam/oauth2/access_token", userInfoURL: "http://passport.utilhub.dt.hudaokeji.com/openam/oauth2/userinfo", clientID: "localhost", clientSecret: "test", callbackURL: "http://localhost:3000/oauth2callback", scope: ["openid"] }, function(accessToken, refreshToken, profile, done) { console.log('accessToken: ', accessToken); console.log('refreshToken: ', refreshToken); console.log('profile: ', profile); return done(null, profile); })); app.get('/auth/passport-utilhub-dt', passport.authenticate('openidconnect')); app.get('/oauth2callback', passport.authenticate('openidconnect', { failureRedirect: '/login' }), function(req, res) { // Successful authentication, redirect home. res.redirect('/'); }); passport.serializeUser(function(user, done){ done(null, user); }); passport.deserializeUser(function(obj, done){ done(null, obj); }); // view engine setup app.set('views', path.join(__dirname, 'views')); app.set('view engine', 'jade'); // uncomment after placing your favicon in /public //app.use(favicon(__dirname + '/public/favicon.ico')); app.use(logger('dev')); app.use(bodyParser.json()); app.use(bodyParser.urlencoded({ extended: false })); app.use(cookieParser()); app.use(express.static(path.join(__dirname, 'public'))); app.use('/', routes); app.use('/users', users); // catch 404 and forward to error handler app.use(function(req, res, next) { var err = new Error('Not Found'); err.status = 404; next(err); }); // error handlers // development error handler // will print stacktrace if (app.get('env') === 'development') { app.use(function(err, req, res, next) { res.status(err.status || 500); res.render('error', { message: err.message, error: err }); }); } // production error handler // no stacktraces leaked to user app.use(function(err, req, res, next) { res.status(err.status || 500); res.render('error', { message: err.message, error: {} }); }); module.exports = app; 修改./views/index.jadeextends layout block content h1= title p Welcome to #{title} a(href="/auth/passport-utilhub-dt") Sign In with OpenAM动作确认启动NodeJS应用Windows下
    node ./bin/wwwLinux下
    ./bin/www浏览器访问

    http://localhost:3000

  • OpenAM 112 0 1 发布
    安装OS

    OpenAM是一个纯JAVA的WEB应用程序产品,可以运行在Windows,Linux,MacOS等各种操作系统上面。

    示范安装我们选择Windows。

    安装JDK

    OpenAM需要运行在JDK6之上。

    示范安装我们选择jdk7。

    安装Tomcat

    OpenAM可以运行在任意JavaEE服务器上

    示范安装我们选择Tomcat8。 OpenAM运行需要1GB的Heap领域和256MB的permanent领域。如下修改bin/catalina.bat文件。

    set CATALINA_OPTS=“-server -Xmx1024m -Xms512m -Xss512k -XX:MaxPermSize=256m”

    OpenAM应用的安装

    OpenAM是以WEB应用(WAR文件)的形式发布的,下载该WAR文件发布到服务器上即可。

    示范安装我们选择OpenAM-12.0.0.war. 2015年6月15日时间点,最新版本的13.0里存在程序BUG,导致Openid Connect不能正常动作。

    设置浏览器页面语言

    OpenAM根据浏览器设定的网页语言优先顺序自动切换语言。所以我们必须更改浏览器的设定才能得到我们所希望的语言显示。 下面是Chrome浏览器的网页显示语言设置。

    初期设定

    选择配置选项

    从客户端浏览器访问http://xxxxx/openam,将出现以下画面,选择【创建新设定】


    步骤1:一般 (设定管理员用户密码)



    步骤2:服务器设定 (设置服务器URL,Cookie域名等。)



    步骤3:设定数据存储 (选择OpenAM。)


    步骤4:设定用户数据存储 (选择OpenAM。)


    步骤5:设定站点  (选择No)


    步骤6:设定缺省的Policy用户 输入缺省的Policy用户用户密码

    完成  点击设定创建按钮。

    系统开始创建设定,并显示进度画面

    这个过程将持续较长时间,完成以后将显示以下画面。


    点击登陆按钮,即进入登录画面



    与Apache集成

    因为Cookie域名的关系,OpenAM与mod_proxy_http不能很好的协同工作 可以使用mod_proxy_ajp,openam 12.0 的ajp端口缺省是8009。

    下面是Apache里映射设定的一个范例

    <VirtualHost *:80> ServerAdmin postmaster@dummy-host2.localhost ServerName xxxx.com ServerAlias xxxx.com ProxyRequests Off <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass / ajp://localhost:8009/ <Location /> Order allow,deny Allow from all </Location> ErrorLog "logs/xxxx-error.log" CustomLog "logs/xxxx-access.log" combined  </VirtualHost>
  • 信息安全 96 0 1 发布

    概述

    HTTPS (Secure Hypertext Transfer Protocol)安全超文本传输协议,是一个安全通信通道,它基于HTTP开发用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换,简单来说它是HTTP的安全版,是使用TLS/SSL加密的HTTP协议。
    HTTP协议采用明文传输信息,存在信息窃听、信息篡改和信息劫持的风险,而协议TLS/SSL具有身份验证、信息加密和完整性校验的功能,可以避免此类问题发生。

    TLS/SSL全称安全传输层协议Transport Layer Security, 是介于TCP和HTTP之间的一层安全协议,不影响原有的TCP协议和HTTP协议,所以使用HTTPS基本上不需要对HTTP页面进行太多的改造。


    HTTPS和HTTP的区别是什么?


    什么是HTTPS

    HTTPS是在HTTP上建立SSL加密层,并对传输数据进行加密,是HTTP协议的安全版。HTTPS主要作用是:

    对数据进行加密,并建立一个信息安全通道,来保证传输过程中的数据安全;对网站服务器进行真实身份认证。什么是HTTP

     HTTP是互联网上应用最为广泛的一种网络协议,是一个客户端和服务器端请求和应答的标准(TCP),用于从WWW服务器传输超文本到本地浏览器的传输协议。HTTP是采用明文形式进行数据传输,极易被不法份子窃取和篡改。

    HTTPS和HTTP的区别   HTTPS是加密传输协议,HTTP是名文传输协议;   HTTPS需要用到SSL证书,而HTTP不用;   HTTPS比HTTP更加安全,对搜索引擎更友好,利于SEO【参考:(1)为保护用户隐私安全,谷歌优先索引HTTPS网页、(2)百度开放收录https站点,https全网化势不可挡】;   HTTPS标准端口443,HTTP标准端口80;   HTTPS基于传输层,HTTP基于应用层;   HTTPS在浏览器显示绿色安全锁,HTTP没有显示;

     总的来说HTTPS比HTTP更加安全,能够有效的保护网站用户的隐私信息安全,这也是为什么现在的HTTPS网站越来越多。如果不想你的网站因为数据泄露上头条的话,就赶快去申请一张SSL证书为自己的网站实现HTTPS加密吧!

    原文链接:https://blog.csdn.net/hherima/article/details/52469267

  • 简介

    Basic身份认证,是HTTP 1.0中引入的认证方案之一,也被称为基本身份认证。 在Basic身份认证中,用户名和密码由冒号“:”连接,用Base64编码并发送。因此,它具有易于窃听和篡改的缺点,但由于它几乎与所有Web服务器和浏览器兼容,因此被广泛使用。为了防止窃听和篡改,后来出现的Digest身份认证技术对Basic身份认证的安全缺陷做了一定的改进。

    认证流程

    Basic身份认证的典型流程如下图所示:

    1. 用户访问受限资源 HTTP请求例:

    GET /employee/index.html HTTP/1.1 Host: psteam.co.jp

    2. 服务端返回401要求身份认证

    HTTP回复例:

    HTTP/1.1 401 Authorization Required Date: Wed, 11 May 2014 07:50:26 GMT Server: Apache/1.3.33 (Linux) WWW-Authenticate: Basic realm="SECRET AREA" Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1

    3. 用户发送认证请求 客户端提示用户输入用户名密码,发送认证请求给服务器端 HTTP请求例:

    /employee/index.html HTTP/1.1 Host: psteam.co.jp Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

    4. 服务端验证请求 HTTP回复例:

    HTTP/1.1 200 OK Date: Wed, 11 May 2014 07:50:26 GMT

    补充说明:

    如果第3步用户选择取消输入用户名密码,认证流程则当即中止如果第4步用户名密码错误,服务器将再次返回401错误,认证流程重回第3步 认证实现 Apache

    Apache里实现Basic认证包含以下两大步骤:

    创建用户管理文件
    要执行基本身份验证,需要创建一个由用户名和密码组成的管理文件。可以使用一个名为htpasswd的程序来创建文件和用户注册。配置htaccess文件
    在需要Basic认证的目录下,创建.htaccsss文件,内容大致如下: AuthUserFile /home/webadmin/.htpasswd AuthGroupFile /dev/null AuthName "Please Enter Your Password" AuthType Basic Require valid-user

    包含以下设置项目:

    AuthUserFile 
    指定步骤1里创建的用户管理文件名。AuthGroupFile 
    指定群组文件AuthName 
    指定客户端用户名密码输入对话框里显示的提示信息AuthType 
    指定认证方式为BasicRequire 
    指定允许访问的用户或群组,「valid-user」表示、允许用户管理文件包含的所有用户。 个别指定的时候,多个用户或群组名可用空格区分。 NodeJS

    如果使用Express,利用express-basic-auth中间件可以很简单的就能实现Basic认证。