精华内容
下载资源
问答
  • 常用的身份验证方法有
    2022-03-21 06:40:46
    您的应用程序的客户端和服务器需要相互通信。这种通信高度依赖于 REST API。您经常需要在您的应用程序中添加用户身份验证系统作为功能,而 REST API 也充当了这方面的桥梁。

    身份验证方法

    您可以将多种身份验证方法与 REST API 一起使用。让我们讨论一下这批中最常见的三种方法。

    HTTP 身份验证方案

    有多种 HTTP 安全方案可用于 REST API 进行身份验证。例如:

    • 基本:这样,发件人将用户名和密码放在请求标头中。用户名和密码均使用 Base64 加密。服务器解密数据并返回用户是否通过身份验证的响应。
    • Bearer:服务器生成令牌并将其提供给客户端的 HTTP 身份验证方案。然后,客户端在向受保护的资源发出请求时,必须在 Authorization 标头中发送此令牌。
    • 摘要:这种类型的身份验证不需要传输密码。客户端获取用户名和密码并使用 MD5 散列算法创建一个散列,然后将其发送到 SQL 服务器。
    • OAuth:它是一种授权协议,为应用程序提供保护指定访问的能力。

    API 密钥

    另一种广泛用于 REST API 的身份验证方法是 API 密钥。它为初次使用的用户提供了唯一的生成密钥。当用户尝试访问所请求的资源时,他们使用他们的 API 密钥。API 密钥告诉服务器这是与以前相同的用户。

    API 密钥不得作为查询参数发送到服务器。相反,它们应该使用 REST API 在 Authorization 标头中发送。

    OAuth 2.0

    OAuth 2.0(开放授权)是一种标准,允许用户从第三方应用程序访问资源。它是一种授权协议,仅用于授予对资源的访问权限,它通过使用访问令牌来工作。

    访问令牌是提供代表用户访问资源的授权的信息。通常,JSON Web Token (JWT) 格式用于访问令牌。

    由于安全原因,它们也可能有到期日期。
    更多相关内容
  • 在B/S系统开发中,经常需要使用“身份验证”。因为web应用程序非常特殊,和传统的C/S程序不同,默认情况下(不采用任何身份验证方式和权限控制手段),当你的程序在互联网/局域网上公开后,任何人都能够访问你的web...
  • 本文分别以ASP.NET1.1与ASP.NET2.0在Forms 身份验证上的实现方法,以及ASP.NET2.0较上一版本哪些改进或变化进行说明.相信读者都己经看过许多类似这样的文章,不伦是在网上或是某些专业书籍上,最近又模式&实践小组...
  • 权限的设计中比较常见的就是RBAC基于角色的访问控制,基本思想是,对系统操作的各种权限不是直接授予具体的用户,而是在用户集合与权限集合之间建立一个角色集合。每一种角色对应一组相应的权限。 一旦用户被分配了...
  • 虽然代码示例和资源适用于 Python 开发人员,但每种身份验证方法的实际说明适用于所有 Web 开发人员。 身份验证与授权 身份验证是验证尝试访问受限系统的用户或设备的凭据的过程。同时,授权是验证是否允许用户或...

    目录

    身份验证与授权

    HTTP 基本身份验证

    流程

    优点

    缺点

    代码

    资源

    HTTP 摘要式身份验证

    流程

    优点

    缺点

    代码

    资源

    基于会话的身份验证

    流程

    优点

    缺点

    代码

    资源

    基于令牌的身份验证

    流程

    优点

    缺点

    代码

    资源

    一次性密码

    流程

    优点

    缺点

    代码

    资源

    OAuth 和 OpenID

    流程

    优点

    缺点

    代码

    资源

    结论


    在本文中,我们将从Python Web开发人员的角度看处理Web身份验证的最常用方法。

    虽然代码示例和资源适用于 Python 开发人员,但每种身份验证方法的实际说明适用于所有 Web 开发人员。

    身份验证与授权

    身份验证是验证尝试访问受限系统的用户或设备的凭据的过程。同时,授权是验证是否允许用户或设备在给定系统上执行某些任务的过程。

    简单地说:

    1. 身份验证:您是谁?
    2. 授权:你能做些什么?

    身份验证先于授权。也就是说,用户必须保持有效,然后才能根据其授权级别授予对资源的访问权限。对用户进行身份验证的最常见方法是 via 和 。一旦通过身份验证,就会为它们分配不同的角色(如 、等),从而向它们授予对系统的特殊权限。usernamepasswordadminmoderator

    有了这个,让我们看一下用于对用户进行身份验证的不同方法。

    HTTP 基本身份验证

    内置于 HTTP 协议中的基本身份验证是最基本的身份验证形式。有了它,登录凭据将随每个请求一起发送到请求标头中:

    "Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=" your-website.com
    

    用户名和密码未加密。相反,用户名和密码使用符号连接在一起以形成单个字符串:。然后使用 base64 对此字符串进行编码。:username:password

    >>> import base64
    >>>
    >>> auth = "username:password"
    >>> auth_bytes = auth.encode('ascii') # convert to bytes
    >>> auth_bytes
    b'username:password'
    >>>
    >>> encoded = base64.b64encode(auth_bytes) # base64 encode
    >>> encoded
    b'dXNlcm5hbWU6cGFzc3dvcmQ='
    >>> base64.b64decode(encoded) # base64 decode
    b'username:password'
    

    此方法是无状态的,因此客户端必须为每个请求提供凭据。它适用于 API 调用以及不需要持久会话的简单身份验证工作流。

    流程

    1. 未经身份验证的客户端请求受限资源
    2. 返回 HTTP 401 未授权,其标头值为 。WWW-AuthenticateBasic
    3. 标头会导致浏览器显示用户名和密码提升WWW-Authenticate: Basic
    4. 输入凭据后,它们将与每个请求一起发送到标头中:Authorization: Basic dcdvcmQ=

    优点

    • 由于正在进行的操作不多,因此使用此方法可以更快地进行身份验证。
    • 易于实施。
    • 所有主流浏览器都支持。

    缺点

    • Base64 与加密不同。这只是表示数据的另一种方式。base64 编码的字符串可以很容易地解码,因为它是以纯文本形式发送的。这种较差的安全功能需要多种类型的攻击。因此,HTTPS / SSL是绝对必要的。
    • 必须随每个请求一起发送凭据。
    • 用户只能通过使用无效凭据重写凭据来注销。

    代码

    基本的HTTP身份验证可以使用Flask-HTTP包在Flask中轻松完成。

    from flask import Flask
    from flask_httpauth import HTTPBasicAuth
    from werkzeug.security import generate_password_hash, check_password_hash
    
    app = Flask(__name__)
    auth = HTTPBasicAuth()
    
    users = {
        "username": generate_password_hash("password"),
    }
    
    
    @auth.verify_password
    def verify_password(username, password):
        if username in users and check_password_hash(users.get("username"), password):
            return username
    
    
    @app.route("/")
    @auth.login_required
    def index():
        return f"You have successfully logged in, {auth.current_user()}"
    
    
    if __name__ == "__main__":
        app.run()
    

    资源

    HTTP 摘要式身份验证

    HTTP 摘要式身份验证(或摘要式访问身份验证)是 HTTP 基本身份验证的一种更安全的形式。主要区别在于密码以MD5散列形式发送,而不是以纯文本形式发送,因此它比基本身份验证更安全。

    流程

    1. 未经身份验证的客户端请求受限资源
    2. 服务器生成一个名为 nonce 的随机值,并发回 HTTP 401 未授权状态,其标头的值与 nonce 一起为:WWW-AuthenticateDigestWWW-Authenticate: Digest nonce="44f0437004157342f50f935906ad46fc"
    3. 标头会导致浏览器显示用户名和密码提示WWW-Authenticate: Basic
    4. 输入凭据后,密码将被散列,然后与每个请求的随机数一起发送到标头中:Authorization: Digest username="username", nonce="16e30069e45a7f47b4e2606aeeb7ab62", response="89549b93e13d438cd0946c6d93321c52"
    5. 使用用户名,服务器获取密码,将其与随机数一起散列,然后验证散列是否相同

    优点

    • 比基本身份验证更安全,因为密码不是以纯文本形式发送的。
    • 易于实施。
    • 所有主流浏览器都支持。

    缺点

    • 必须随每个请求一起发送凭据。
    • 用户只能通过使用无效凭据重写凭据来注销。
    • 与基本身份验证相比,由于无法使用bcrypt,因此服务器上的密码安全性较低。
    • 容易受到中间人攻击。

    代码

    Flask-HTTP 包也支持摘要式 HTTP 身份验证。

    from flask import Flask
    from flask_httpauth import HTTPDigestAuth
    
    app = Flask(__name__)
    app.config["SECRET_KEY"] = "change me"
    auth = HTTPDigestAuth()
    
    users = {
        "username": "password"
    }
    
    
    @auth.get_password
    def get_user(username):
        if username in users:
            return users.get(username)
    
    
    @app.route("/")
    @auth.login_required
    def index():
        return f"You have successfully logged in, {auth.current_user()}"
    
    
    if __name__ == "__main__":
        app.run()
    

    资源

    基于会话的身份验证

    使用基于会话的身份验证(或会话 Cookie 身份验证或基于 Cookie 的身份验证),用户的状态存储在服务器上。它不要求用户在每个请求中提供用户名或密码。相反,在登录后,服务器将验证凭据。如果有效,它将生成一个会话,将其存储在会话存储中,然后将会话 ID 发送回浏览器。浏览器将会话ID存储为cookie,每当向服务器发出请求时,就会发送该cookie。

    基于会话的身份验证是有状态的。每次客户端请求服务器时,服务器都必须在内存中找到会话,以便将会话 ID 绑定回关联的用户。

    流程

    优点

    • 更快的后续登录,因为不需要凭据。
    • 改进的用户体验。
    • 相当容易实现。许多框架(如Django)开箱即用地提供了此功能。

    缺点

    • 它是有状态的。服务器跟踪服务器端的每个会话。用于存储用户会话信息的会话存储需要在多个服务之间共享才能启用身份验证。因此,它不适用于RESTful服务,因为REST是一种无状态协议。
    • Cookie 随每个请求一起发送,即使它不需要身份验证
    • 容易受到 CSRF 攻击。在此处阅读有关CSRF以及如何在Flask中预防CSRF的更多信息

    代码

    Flask-Login非常适合基于会话的身份验证。该软件包负责登录,注销,并且可以记住用户一段时间。

    from flask import Flask, request
    from flask_login import (
        LoginManager,
        UserMixin,
        current_user,
        login_required,
        login_user,
    )
    from werkzeug.security import generate_password_hash, check_password_hash
    
    
    app = Flask(__name__)
    app.config.update(
        SECRET_KEY="change_this_key",
    )
    
    login_manager = LoginManager()
    login_manager.init_app(app)
    
    
    users = {
        "username": generate_password_hash("password"),
    }
    
    
    class User(UserMixin):
        ...
    
    
    @login_manager.user_loader
    def user_loader(username: str):
        if username in users:
            user_model = User()
            user_model.id = username
            return user_model
        return None
    
    
    @app.route("/login", methods=["POST"])
    def login_page():
        data = request.get_json()
        username = data.get("username")
        password = data.get("password")
    
        if username in users:
            if check_password_hash(users.get(username), password):
                user_model = User()
                user_model.id = username
                login_user(user_model)
            else:
                return "Wrong credentials"
        return "logged in"
    
    
    @app.route("/")
    @login_required
    def protected():
        return f"Current user: {current_user.id}"
    
    
    if __name__ == "__main__":
        app.run()
    

    资源

    基于令牌的身份验证

    此方法使用令牌(而不是 Cookie)对用户进行身份验证。用户使用有效凭据进行身份验证,服务器返回签名令牌。此令牌可用于后续请求。

    最常用的令牌是 JSON Web 令牌 (JWT)。JWT由三部分组成:

    • 标头(包括令牌类型和使用的哈希算法)
    • 有效负载(包括声明,即有关主题的语句)
    • 签名(用于验证邮件在此过程中是否未更改)

    这三种都是 base64 编码的,并使用 a 和散列进行串联。由于它们是编码的,因此任何人都可以解码和读取消息。但只有真实用户才能生成有效的签名令牌。令牌使用签名进行身份验证,签名是使用私钥签名的。.

    JSON Web 令牌 (JWT) 是一种紧凑的 URL 安全方法,用于表示要在双方之间传输的声明。JWT 中的声明被编码为 JSON 对象,该对象用作 JSON Web 签名 (JWS) 结构的有效负载或 JSON Web 加密 (JWE) 结构的明文,从而使声明能够使用消息身份验证代码 (MAC) 进行数字签名或完整性保护和/或加密。- IETF

    令牌不需要保存在服务器端。只需使用其签名即可对其进行验证。最近,由于RESTful API和单页应用程序(SPA)的兴起,令牌采用率有所增加。

    流程

    优点

    • 它是无状态的。服务器不需要存储令牌,因为它可以使用签名进行验证。这使得请求速度更快,因为不需要数据库查找。
    • 适用于多个服务需要身份验证的微服务体系结构。我们需要在每一端配置的是如何处理令牌和令牌密钥。

    缺点

    • 根据令牌在客户端上的保存方式,它可能导致 XSS(通过 localStorage)或 CSRF(通过 cookie)攻击。
    • 无法删除令牌。它们只能过期。这意味着,如果令牌泄露,攻击者可能会滥用它直到到期。因此,将令牌到期时间设置为非常小的时间(如 15 分钟)非常重要。
    • 需要将刷新令牌设置为在到期时自动颁发令牌。
    • 删除令牌的一种方法是创建一个数据库,用于将令牌列入黑名单。这增加了微服务体系结构的额外开销,并引入了状态。

    代码

    Flask-JWT扩展包为处理JWT提供了许多可能性。

    from flask import Flask, request, jsonify
    from flask_jwt_extended import (
        JWTManager,
        jwt_required,
        create_access_token,
        get_jwt_identity,
    )
    from werkzeug.security import check_password_hash, generate_password_hash
    
    app = Flask(__name__)
    app.config.update(
        JWT_SECRET_KEY="please_change_this",
    )
    
    jwt = JWTManager(app)
    
    users = {
        "username": generate_password_hash("password"),
    }
    
    
    @app.route("/login", methods=["POST"])
    def login_page():
        username = request.json.get("username")
        password = request.json.get("password")
    
        if username in users:
            if check_password_hash(users.get(username), password):
                access_token = create_access_token(identity=username)
                return jsonify(access_token=access_token), 200
    
        return "Wrong credentials", 400
    
    
    @app.route("/")
    @jwt_required
    def protected():
        return jsonify(logged_in_as=get_jwt_identity()), 200
    
    
    if __name__ == "__main__":
        app.run()
    

    资源

    一次性密码

    一次性密码 (OTP) 通常用作身份验证的确认。OTP是随机生成的代码,可用于验证用户是否是他们声称的身份。它通常在用户凭据验证后用于利用双重身份验证的应用。

    要使用 OTP,必须存在受信任的系统。此受信任的系统可以是经过验证的电子邮件或手机号码。

    现代OTP是无国籍的。可以使用多种方法验证它们。虽然有几种不同类型的OTP,但基于时间的OTP(TOTP)可以说是最常见的类型。生成后,它们将在一段时间后过期。

    由于您可以获得额外的安全层,因此建议将OTP用于涉及高度敏感数据的应用程序,例如网上银行和其他金融服务。

    流程

    实施OTP的传统方式:

    • 客户端发送用户名和密码
    • 凭据验证后,服务器生成随机代码,将其存储在服务器端,并将代码发送到受信任的系统
    • 用户在受信任的系统上获取代码,然后将其输入回 Web 应用
    • 服务器根据存储的代码验证代码,并相应地授予访问权限

    TOTP的工作原理:

    • 客户端发送用户名和密码
    • 凭据验证后,服务器使用随机生成的种子生成随机代码,将种子存储在服务器端,并将代码发送到受信任的系统
    • 用户在受信任的系统上获取代码,然后将其输入回 Web 应用
    • 服务器根据存储的种子验证代码,确保它没有过期,并相应地授予访问权限

    GOOGLE AuthenticatorMicrosoft Authenticator 和 FreeOTP 等 OTP 代理的工作原理:

    • 注册双因素身份验证(2FA)后,服务器会生成一个随机种子值,并以唯一QR码的形式将种子发送给用户
    • 用户使用其2FA应用程序扫描QR码以验证受信任的设备
    • 每当需要 OTP 时,用户都会在其设备上检查代码,并在 Web 应用上输入该代码
    • 服务器验证代码并相应地授予访问权限

    优点

    • 添加额外的保护层。
    • 没有被盗密码可用于同时实施OTP的多个站点或服务的危险。

    缺点

    • 您需要存储用于生成 OTP 的种子。
    • 如果您丢失了恢复代码,则很难再次设置像Google身份验证器这样的OTP代理。
    • 当受信任的设备不可用时会出现问题(电池没电,网络错误等)。因此,通常需要备份设备,这会增加额外的攻击媒介。

    代码

    PyOTP 软件包提供基于时间和基于计数器的 OTP。

    from time import sleep
    
    import pyotp
    
    if __name__ == "__main__":
        otp = pyotp.TOTP(pyotp.random_base32())
        code = otp.now()
        print(f"OTP generated: {code}")
        print(f"Verify OTP: {otp.verify(code)}")
        sleep(30)
        print(f"Verify after 30s: {otp.verify(code)}")
    

    例:

    OTP generated: 474771
    Verify OTP: True
    Verify after 30s: False
    

    资源

    OAuth 和 OpenID

    OAuth/OAuth2 和 OpenID 分别是授权和身份验证的流行形式。它们用于实现社交登录,这是一种单点登录(SSO)形式,使用来自社交网络服务(如Facebook,Twitter或Google)的现有信息登录到第三方网站,而不是专门为该网站创建新的登录帐户。

    当您需要进行高度安全的身份验证时,可以使用此类型的身份验证和授权。其中一些提供商拥有足够的资源来投资身份验证本身。利用这种久经考验的身份验证系统最终可以使您的应用程序更加安全。

    此方法通常与基于会话的身份验证结合使用。

    流程

    您访问的网站需要您登录。您导航到登录页面,并看到一个名为“使用Google登录”的按钮。您点击该按钮,它会将您带到Google登录页面。通过身份验证后,系统会将您重定向回自动登录的网站。这是使用 OpenID 进行身份验证的示例。它允许您使用现有帐户(通过OpenID提供程序)进行身份验证,而无需创建新帐户。

    最著名的OpenID提供商是Google,Facebook,Twitter和GitHub。

    登录后,您可以导航到网站内的下载服务,该服务可让您将大文件直接下载到Google云端硬盘。网站如何访问您的 Google 云端硬盘?这就是OAuth发挥作用的地方。您可以授予访问其他网站上的资源的权限。在这种情况下,请以写入权限访问 Google 云端硬盘。

    优点

    • 提高了安全性。
    • 更简单、更快速地登录流程,因为无需创建和记住用户名或密码。
    • 如果发生安全漏洞,不会发生第三方损坏,因为身份验证是无密码的。

    缺点

    • 你的应用程序现在依赖于另一个应用,不受你的控制。如果 OpenID 系统已关闭,用户将无法登录。
    • 人们通常倾向于忽略 OAuth 应用程序请求的权限。
    • 在已配置的 OpenID 提供程序上没有帐户的用户将无法访问您的应用程序。最好的方法是同时实现两者 - 例如,用户名和密码以及OpenID - 并让用户选择。

    想要实施社交登录?

    想要运行自己的 OAuth 或 OpenID 服务?

    代码

    您可以使用 Flask-Dance 实现 GitHub 社交身份验证。

    from flask import Flask, url_for, redirect
    from flask_dance.contrib.github import make_github_blueprint, github
    
    app = Flask(__name__)
    app.secret_key = "change me"
    app.config["GITHUB_OAUTH_CLIENT_ID"] = "1aaf1bf583d5e425dc8b"
    app.config["GITHUB_OAUTH_CLIENT_SECRET"] = "dee0c5bc7e0acfb71791b21ca459c008be992d7c"
    
    github_blueprint = make_github_blueprint()
    app.register_blueprint(github_blueprint, url_prefix="/login")
    
    
    @app.route("/")
    def index():
        if not github.authorized:
            return redirect(url_for("github.login"))
        resp = github.get("/user")
        assert resp.ok
        return f"You have successfully logged in, {resp.json()['login']}"
    
    
    if __name__ == "__main__":
        app.run()
    

    资源

    结论

    在本文中,我们研究了许多不同的Web身份验证方法,所有这些方法都有自己的优点和缺点。

    什么时候应该使用它们?这要视情况而定。基本经验法则:

    1. 对于利用服务器端模板的 Web 应用程序,通过用户名和密码进行基于会话的身份验证通常是最合适的。您也可以添加OAuth和OpenID。
    2. 对于 RESTful API,基于令牌的身份验证是推荐的方法,因为它是无状态的。
    3. 如果必须处理高度敏感的数据,则可能需要将 OTP 添加到身份验证流中。

    最后,请记住,显示的示例只是触及表面。生产使用需要进一步的配置。

     

    展开全文
  • Mongodb提供了一系列的 安全功能 ,这里介绍一种很常用身份验证方式。 2. 开启验证 默认情况下,只要在启动数据库的时候没有加上 –auth 选项,就是没有身份验证功能的,所有客户端都可以进行所有权限的操作。 ...
  • 本发明涉及一种身份验证方法,具体涉及一种计算机系统用户身份验证方法。背景技术:现代社会生活中,无论是科学研究、商业发展、日常办公还是医疗或教育,无一例外地都与计算机技术息息相关。计算机技术的发展使...

    本发明涉及一种身份验证方法,具体涉及一种计算机系统用户身份验证方法。

    背景技术:

    现代社会生活中,无论是科学研究、商业发展、日常办公还是医疗或教育,无一例外地都与计算机技术息息相关。计算机技术的发展使计算机这一高新科技切实地走入了千家万户,渗透到了社会的每一个角落。人们的日常生活对于计算机的依赖度越来越高,尤其是网络应用软件的不断推陈出新,打破了日常时间与空间上的阻碍后,人们对于计算机的应用更加广泛。随着各种新型的软件的开发,人们在电脑上储存了大量的个人信息,每一台电脑中都存有持有者的许多个人隐私,有的甚至是机密要件等等。由于计算机中存有的信息量巨大而且重要,计算机信息泄露的问题就越来越受到人们的关注。

    目前,防范计算机信息泄露的方法主要集中在硬件和软件的保密加固,此外还有登录系统时的身份验证。现在常用的身份验证方法可能对于普通用户来说已经绰绰有余,但是对于那些保密需求较高的用户来说就显得保护力度不足。

    技术实现要素:

    为解决现有技术的不足,本发明的目的在于提供一种用户身份验证方法,该方法能够有效的确保用户身份的合法性,防止系统中机密资料的泄露。

    为了实现上述目标,本发明采用如下的技术方案:一种计算机系统用户身份验证方法,用于判断登陆计算机系统的用户是否为合法使用者,其特征在于,包括以下步骤:

    步骤一,用户建立登录账号时,向服务器上传自己的手机号码,并且向服务器提供其他手机号码作为关联方;

    步骤二,服务器向所述关联方手机号码发送信息询问是否同意关联;

    步骤三,所述关联方手机号码向服务器回复同意关联的信息,则关联成功,所述关联方手机号码设置登录密码并发送至服务器;

    步骤四,用户向服务器发送登陆请求后,服务器向用户发送关联方手机号码选择列表;

    步骤五,用户在所述选择列表中选取一个手机号码,并将结果返回服务器;

    步骤六,服务器对用户选择的手机号码进行验证,如果所选号码和所述关联方手机号码不一致,则拒绝用户的登录请求,如果所选号码和所述关联方手机号码一致,则向所述关联方手机号码发送信息索取登录密码;

    步骤七,所述关联方通过手机发送登录密码至服务器,服务器判断密码是否正确,如果密码正确,则用户登录成功,如果密码不正确,则拒绝用户的登录请求。

    优选地,所述关联方为同一计算机系统的用户。

    优选地,所述步骤一中,向服务器提供多个其他手机号码作为关联方。

    本发明的有益之处在于:

    本发明提出了一种计算机系统用户身份验证方法,该方法采用两级验证方式验证登录用户的身份,首先验证登录用户是否知道关联方的手机号码,然后通过关联方发送密码的方式通过用户的登录请求,能够确保登录计算机系统的用户的合法性,防止机密资料的泄露。

    附图说明

    图1是本发明一种计算机系统用户身份验证方法流程图。

    具体实施方式

    以下结合附图和具体实施例对本发明作具体的介绍。

    参照图1所示,本发明一种计算机系统用户身份验证方法,用于判断登陆计算机系统的用户是否为合法使用者,其特征在于,包括以下步骤:

    S1,用户建立登录账号时,向服务器上传自己的手机号码,并且向服务器提供其他手机号码作为关联方。其中,关联方可以是系统用户之外的人,最好是同一系统中的其他用户,这样保密性更好。其次,在建立账户时,可以只提供一个其他手机号码只设立一个关联方,也可以向系统服务器提供多个手机号码设立多个关联方,关联方的数量依据保密需求设定。

    S2,服务器向所述关联方手机号码发送信息询问是否同意关联。

    S3,所述关联方手机号码向服务器回复同意关联的信息,则关联成功,所述关联方通过手机设置登录密码并发送至服务器。登录密码的形式可以根据需要设定,比如纯数字、数字和字母的组合、数字和特殊符号的组合等。

    S4,用户向服务器发送登陆请求后,服务器向用户发送关联方手机号码选择列表。此外,服务器还可以直接要求用户输入关联方的手机号码,而不用选择的方式。

    S5,用户在所述选择列表中选取一个手机号码,并将结果返回服务器。当设置了多个关联方时,根据需求,服务器可以要求用户选出关联方手机号码中的一部分或者全部。

    S6,服务器对用户选择的手机号码进行验证,如果所选号码和所述关联方手机号码不一致,则拒绝用户的登录请求,如果所选号码和所述关联方手机号码一致,则向所述关联方手机号码发送信息索取登录密码;

    S7,所述关联方手机号码发送登录密码至服务器,服务器判断密码是否正确,如果密码正确,则用户登录成功,如果密码不正确,则拒绝用户的登录请求。

    以上显示和描述了本发明的基本原理、主要特征和优点。本行业的技术人员应该了解,上述实施例不以任何形式限制本发明,凡采用等同替换或等效变换的方式所获得的技术方案,均落在本发明的保护范围内。

    展开全文
  • 常见身份验证协议

    千次阅读 2019-10-21 20:04:48
    PAP 是 PPP 协议集中的一种链路控制协议,通过2次握手建立认证,对等结点持续重复发送 ID/ 密码(明文)给验证者,直至认证得到响应或连接终止,常见于PPPOE拨号环境中。 PAP认证过程 首先被认证方向认证方发送...

       

    PAP(PasswordAuthenticationProtocol 密码认证协议)
            PAP 是 PPP 协议集中的一种链路控制协议,通过2次握手建立认证,对等结点持续重复发送 ID/ 密码(明文)给验证者,直至认证得到响应或连接终止,常见于PPPOE拨号环境中。

    PAP认证过程

            首先被认证方向认证方发送认证请求(包含用户名和密码),以明文形式进行传输,认证方接到认证请求,再根据被认证方发送来的用户名去到自己的数据库认证用户名密码是否正确,如果密码正确,PAP认证通过,如果用户名密码错误,PAP认证未通过
            PAP 并不是一种强有效的认证方法,其密码以文本格式在电路上进行发送,对于窃听、重放或重复尝试和错误攻击没有任何保护。


    CHAP (ChallengeHandshakeAuthenticationProtocol 挑战应答认证协议)
            CHAP通过三次握手验证被认证方的身份(密文),在初始链路建立时完成,为了提高安全性,在链路建立之后周期性进行验证,目前在企业网的远程接入环境中用的比较常见。

    CHAP认证过程

            链路建立阶段结束之后,认证方主动向对端点发送“challenge”消息(此认证序列号id+认证方主机名+随机数)
    对端点去到自己的数据库查到认证方主机名对应的密码,用查到的密码结合认证方发来的认证序列号id和随机数,经过单向哈希函数MD5计算出来的值做应答。
    根据被认证方发来的认证用户名,主认证方在本地数据库中查找被认证方对应的密码,结合id找到先前保存的随机数据和id根据MD5算法算出一个Hash值,与被认证方得到的Hash值做比较,如果一致,则认证通过,如果不一致,则认证不通过。
    经过一定的随机间隔,认证方发送一个新的 challenge 给端点,重复步骤 1 到 3 。

    EAP协议以及类型

            可扩展身份认证协议(Extensible Authentication Portocol,EAP)最早定义在RFC2284中,是一种支持多种认证方法的认证框架,而不是一个认证机制。EAP最初被设计用于PPP,后来被RFC 3748更新,用于基于端口的802.1X访问控制,最后又被RFC 5247所更新。

    EAP是一种非常灵活的二层协议,包括多种类型。有些EAP类型是产商私有的,有些EAP类型是标准的,如LEAP是Cisco私有的,PEAP是公有的标准。有些EAP仅能提供单向认证,而有些EAP可提供双向认证(mutual authenticaiton)。在双向认证中,不仅认证服务器需要对请求方的身份进行认证,请求方也必须对认证服务器的身份进行认证,以防止自己提供的用户名和密码被非法或假冒的认证服务器窃取。大部分要求双向认证的EAP采用服务器证书对认证服务器的身份进行验证。下表列出了各种EAP的特点和具体特性:

    表-1 EAP类型

     

    1. “弱”EAP协议

            传统的EAP类型极容易受到各种攻击,包括社会工程学和离线字典的攻击。这些传统的EAP类型是企业WLAN绝对不可能接受的解决方案,包括EAP-MD5和EAP-LEAP。

    1.1 EAP-MD5

          EAP-MD5是一种相当简单的EAP类型,很长一段时间在有线网络中用于端口认证,因此也成为第一个用于WLAN中的EAP类型。然而,由于EAP-MD5的存在几大缺点,因此在企业WALN环境中不建议EAP-MD5,这几大缺点是:

    •      单向认证: 只有请求方被认证,服务器不需要被认证。相互认证需要创建动态加密密钥,如果选择EAP-MD5为身份验证方法,则加密方法只能是静态WEP,或根本没有加密;

    •      用户名明文: 请求方的用户名总是明文可见,如果黑客知道用户的身份,黑客可以尝试使用社会工程学技术获取到密码。因此,EAP-MD5很容易受到社会工程学攻击;

    •      弱MD5哈希:请求方的密码使用MD5哈希功能,但其很容易受到各种黑客工具所破解。因此,EAP-MD5极容易受到离线字典攻击;

    下图描述了EAP-MD5的认证过程:

     

    图-1 EAP-MD5的认证过程

    1.2 EAP-LEAP

          EAP-LEAP也被简称为LEAP(Lightweight Extensible Authentication

    Protocol, 轻量级可扩展身份认证协议),是多年来被企业WLAN使用的一个非常成功的EAP类型。LEAP很容易部署,所有终端用户可使用相同的身份凭证:用户名和密码。

    与EAP-MD5不同,LEAP使用动态生成的WEP密钥对数据传输进行加密,并执行一种类型的伪双向认证,尽管许多文档声称LEAP支持双向认证。MS-CHAP和MS-CHAPv2在双向认证的过程中使用相同的密码进行哈希以认证对方,但这不是真正的双向认证。LEAP有以下几大缺点:

    •      用户名明文:请求方的用户名总是明文可见,如果黑客知道用户的身份,黑客可以尝试使用社会工程学技术获取到密码。因此,EAP-MD5很容易受到社会工程学攻击;

    •      弱MS-CHAPv2哈希:请求方的密码使用MS-CHAPv2哈希功能,但其很容易受到各种黑客工具所破解。因此,EAP-MD5极容易受到离线字典攻击;

    •      伪双向认证:LEAP使用MS-CHAPv2协议支持一种“类型”的双向认证;

          尽管LEAP可以使用强大和复杂的密码抵御攻击,但强制终端用户使用强大的密码策略是一个挑战。为了企业WLAN的安全,不建议在企业WLAN中部署使用LEAP。

    下图描述了EAP-LEAP的认证过程:

    图-2 EAP-LEAP的认证过程

     

    2. “强”EAP协议

        “强”EAP类型使用基于TLS的身份认证或TLS隧道化身份认证,与EAP-MD5/EAP-LEAP只使用一个请求方身份不同,基于隧道身份验证的EAP类型使用两个请求方身份:外层身份(outer identity)和内层身份(inner identity)。外层身份只是一个有效的虚假用户名(通常为anonymous),而内层身份是请求方的真实身份。外层身份以明文出现在加密TLS隧道外,而内层身份被TLS隧道所保护。

    注意:所有的请求方都有能力配置外层身份的虚假用户名,除了Microsoft WZC请求方。WZC请求认证时内层和外层身份都使用相同的用户名。因此,真正的用户名可见,这是为什么建议不是用Microsoft内置的WZC请求方。

     

    2.1 EAP-PEAP

            EAP-PEAP简称为PEAP(Protected Extensible Authentication Protocol,受保护的可扩展身份验证协议),其创建一个加密的TLS隧道,并在该TLS隧道内验证请求方内层身份。由于PEAP的高安全性,因此,PEAP是企业WLAN中最常用也是使用最广泛的的EAP类型。

             PEAP最开始由Csico、Microsoft、RSA、Security三家公司所联合提议,但是据报道Microsoft和Cisco没有完全同意提议的每一个细节。Microsoft实施PEAPv0使用MS-CHAPv2作为内部认证方法,MS-CHAPv2是Microsoft自由的CHAP版本,随着微软在客户端和服务器操作系统占有的统治地位,并内置支持MS-CHAPv2,因此这也导致了EA-PEAPv0(EAP-MSCHAPv2)的成功。而Cisco从原始的标准中分离出PEAPv1,其使用EAP-GTC作为内部认证方法。PEAP包括三个主要版本:

    •    EAP-PEAPv0(EAP-MSCHAPv2)

            微软的EAP-PEAPv0 (EAP-MSCHAPv2)是最常用的一种PEAP类型,使用EAP-MSCHAPv2协议作为隧道内部的认证方法,其使用用户名和密码作为用户凭证。

    •    EAP-PEAPv0(EAP-TLS)

            EAP-PEAPv0(EAP-TLS)是微软的另一种类型的PEAP,使用EAP-TLS协议作为隧道内部的认证方法,其使用客户端证书作为用户凭证。EAP-TLS也可以作为一个单独的EAP认证协议使用。

    •    EAP-PEAPv1(EAP-GTC)

           EAP-PEAPv1(EAP-GTC)是Cisco版本的一种PEAP类型,使用EAP-GTC(EAP-GenericToken Card,通用令牌卡)协议作为隧道内部的认证方法。EAP-GTC定义在RFC3748中,然后被发展成与现有的安全令牌系统提供互操作性,如RSA的SecurID解决方案的OTP。EAP-GTC方法建议使用安全令牌设备,但是其身份凭证也可以为明文的用户名和密码。因此,当EAP-GTC被用于PEAPv1的隧道中,通常其身份凭证是一个简单的明文用户名和密码。

            由于在TLS隧道中使用的PEAP内部认证协议是另一种类型的EAP,所以PEAP通常也被称为”EAP inside EAP“认证,唯一的区别就是使用在TLS隧道中的内部EAP协议不同。

            PEAP操作的关键点是建立TLS隧道,这需要一个服务器端证书(server-side certificate)。EAP-PEAP认证过程包括两个阶段,下面以EAP-PEAPv0 (EAP-MSCHAPv2) 来说明,下图描述了EAP-PEAP的认证过程:

    图-3 EAP-PEAP的认证过程

     

    注意:加密TLS隧道只会存在几毫秒,用于保护用户身份凭证,而不是用于加密802.11数据帧。

    2.2 EAP-TTLS

            EAP-TTLS(EAP-Tunneled Transport Layer Security,隧道传输层安全)由Certicom和FunkSoftware设计,定义在RFC 5281中。与PEAP一样,EAP-TTLS也使用TLS隧道保护相对不安全的内层认证方法。如下图所示,EAP-TTLS与PEAP相似,认证过程也包含两个阶段。

    图-4 EAP-TTLS的认证过程

     

    EAP-TTLS与EAP-PEAP的区别相当小,最大的不同就是EAP-TTLS支持更多的内层认证协议。EAP-TTLS支持传统的认证方法PAP、 CHAP、MS-CHAP和MS-CHAPv2,也支持使用EAP协议作为内层认证方法,支持使用客户端证书作为身份凭证,而EAP-PEAP只支持EAP协议作为内层认证方法。

             EAP-TTLS曾被广泛部署过,在许多企业WLAN中也能遇到。然而,EAP-TTLS与EAP-PEAP几乎相同,且不被Microsoft WZC所支持。因此,相对其他的EAP协议类型来说市场较小。如果不使用Microsoft WZC作为请求方,EAP-TTLS是可考虑的一种选择。

     

    2.3 EAP-TLS

            EAP-TLS(EAP-Transport Layer Security,传输层安全)定义在RFC 5216中,是使用最广泛,也是WLAN中最安全的一种EAP类型。EAP-TLS除了与EAP-PEAP和EAP-TTLS一样需要服务器端证书外,还需要客户端证书。

            部署服务器端证书并不需要太大的负担,然而为每一个客户端部署唯一的数字证书需要企业PKI基础设施,这对企业来说是一个负担。因此,除非企业已经存在PKI基础设施,否议在企业WLAN中部署EAP-TLS不是第一建议。下图描述了EAP-TLS的认证过程:

    图-5 EAP-TLS的认证过程

     

    使用客户端数字证书作为身份凭证是EAP-TTLS和EAP-PEAP的可选项,然而在TLS隧道中使用客户端证书是不必要的。因此,只建议在部署EAP-TLS时使用客户端数字证书。认证服务器配置EAP-TLS时,通常允许通过比较用户数字证书中包含的一个或多个信息来验证客户端证书,这些信息包括:

    •    证书持有者别名(Certificate Subject Alternative Name ,SAN)

    •    证书持有者通用名称(Certificate Subject Common Name ,CN)

    •    证书二进制(Certificate Binary)

    2.4 EAP-FAST

          EAP-FAST(EAP-Flexible Authentication via Secure Tunneling,基本安全隧道的灵活认证)由Cisco所开发设计,用于取代易破解的LEAP。EAP-FAST目前已经被标准化定义在RFC 4851中,并在2009年,与EAP-AKA一起加入到Wi-Fi联盟的WPA2互操作认证中。

     EAP-FAST与EAP-PEAP和EAP-TTLS一样,提供双向认证和隧道化认证。但是EAP-FAST并不使用基于X.509标准的数字证书去建立TLS隧道,而是使用PAC(Protected Authentication Credential,受保护的接入凭证)。

          PAC是一种类数字证书,实际上是一个共享密钥,主要包含以下三部分:

    •    Shared Secret—The PAC-Key:客户端与认证服务器之间的一个预共享密钥,是一个强32字节的密钥,由认证服务器随机产生,是建立TLS隧道的先期主密钥;

    •    Opaque Element—The PAC-Opaque:在隧道建立时发送给认证服务的一个可变长度的数据元素,这样认证服务器就可以解码所需的信息来验证客户端的身份;

    •    Other Information—PAC-Info:是一个可变长度的数据元素,,能够以最简洁方式的提供认证服务器或PAC发布者的身份(A-ID)。为了避免混绕,各个认证服务器的A-ID是不同的。PAC-Info还可能包括其他的有用但非强制的信息,例如,PAC-Key生存时间,也可能在PAC分发或更新时被服务器传递到申请者。

     

    以上三个部分统一构成了一个完整的PAC证书,在EAP-FAST认证之前由认证服务器一次性产生并通过安全的方式送给申请者,完成PAC的发放。

    EAP-FAST的认证过程包含3个阶段:其中阶段1是一个可选的阶段,如下图所示:

    图-6 EAP-FAST认证过程

     

    •    EAP-FAST 阶段0 —— 此阶段用于自动分发部署PAC,是一个可选的阶段,所有的PAC可以通过手动方式安装在每个客户端上。

    •    EAP-FAST 阶段1 ——  客户端请求方发送外层伪装的身份ID给认证服务器,让认证服务器知道有客户端尝试认证。客户端和认证服务器之间使用对称密钥加密进行协商,建立起一个加密的TLS隧道;

    •    EAP-FAST阶段2 ——  在加密隧道内进行客户端请求方的身份验证。EAP-FAST支持多种内层认证方法,但通常使用的内层认证协议为EAP-GTC,使用用户名和密码进行验证。

          阶段0执行的自动分发部署PAC文件是使用一个匿名的Diffie-Hellman交换,客户端仅是简单的信任提供PAC文件的。因此,EAP-FAST如果是使用自动分发部署PAC文件,很容易遭受到中间人攻击。如果不经过阶段0,则手动安装PAC文件到每个客户端上则是一件很繁重的任务,还不如使用已经被广泛部署过的EAP-TLS和EAP-PEAP。

     

    3. 其他EAP协议

          除了以上介绍的EAP协议外,还有多种其他EAP协议的存在。如EAP-POTP协议,用于移动电话产业的EAP-SIM和EAP-AKA等,这里不做详细介绍。

    展开全文
  • 最容易把人搞糊涂的是,很少人注意到这样一种事实:存在许多不同种类的身份验证协议,它们还试图扮演完全不同的角色。与往常一样,首先请记住,身份验证和授权是不一样的功能。考虑到这一点,本质上存在三种不同的...
  • Authentication—身份验证流程

    千次阅读 2020-01-21 14:05:43
    本篇是对Shiro体系架构的介绍,本栏目大部分内容来自于Shiro官网。...Authentication是身份验证的过程,即证明该用户是否合法,对于证明一个用户是否合法,用户需要提供一些身份识别信息,以及系统能信任的身份证...
  • Windows身份验证提供程序: ...使用 Forms 身份验证的一种简便方法是使用 ASP.NET 成员资格和 ASP.NET 登录控件,它们一起提供了一种只需少量或无需代码就可以收集、验证和管理用户凭据的方法。 Passport 身份验
  • 这种方法将本地身份验证和社会身份验证分开。 但是,在这两个世界中都一些常见的场景需要处理。 例如,由OpenID提供程序传递的电子邮件地址不能保证得到验证。 因此,在将OpenID帐户挂接到本地帐户之前,必须先...
  • 常见身份验证方法是使用密码,但密码是一种存在严重缺陷的身份验证方式。 人们被要求完成一项几乎不可能完成的任务——为他们拥有的众多帐户中的每一个创建独特、长且复杂的密码,经常更改它们并记住它们。 ...
  • 根据业务需求,开发人员需要为其应用程序选择最合适的身份验证方法。 除非人们很好地了解机制之间的差异,否则这可能不是一件容易的事。 在这篇简短的文章中,我想回顾一下实现身份验证的4种流行机制。 还要比较...
  • 客户端使用它支持的身份验证方法进行访问,如果服务器可以接受,则建立会话。用户凭据(用户名和密码)将发送到服务器,这些凭证可能安全,也可能不安全。实际上,服务器可能根本不需要身份验证。这...
  • 关于身份认证的方式,最近在工作中用到了些,想着就干脆针对目前常用身份认证组件的实际使用,就做一个总结,会涉及Json Web Token(JWT),Shiro的常见认证方式。 传统的认证流程 在学习这些组件的时候,还是需要...
  • 发布时间:2015-09-22昨天蚕豆网小编给大家带来了iOS体验试玩版给大家下载试玩,虽然时候游戏进不去,但最后还是能快乐的进入游戏玩耍的.而今天早上,小编再次准备进入的时候发现了一些 ...标签:现代战争5连接失败 ...
  • about(Short Description / Summary):该项目描述了一种使用手机实现两因素身份验证方法。 所提出的方法保证以非常安全的方式对服务(例如在线银行或 ATM 机)进行身份验证。 提议的系统涉及使用手机作为一次性...
  • 目标是使用表单登录方法对用户进行身份验证。2.认证和授权(Authentication and Authorization)身份验证和授权通常结合使用,因为它们在授予系统访问权限时起着重要且同样重要的作用。但是,它们具有不同的含义,并在...
  • 常用方法有:口令变换:用户给出的口令在客户端经过单问函数变换处理后传送给服务器,服务器对存储的用户口令副本进行同样变换后与收到的口令值进行比较。这主要是防止攻击者通过信道窃取合法用户口令原值。提问-回答:...
  • 这很有用,因为单足授权是许多常见服务 API(例如和所需的身份验证方法。 已经提供了一个用于创建和发送签名 URL 请求的,但是它没有提供一种方法来独立生成 OAuth 签名的 URL 请求并使用选择的网络库(例如 ...
  • WebService 之 身份验证

    2021-02-12 18:06:32
    二、 在第一种方法的基础上对WebService里的方法进行加密,这里面方法很多,下面提供一种比较常用方法。在调用方法时多提供两个参数用户加密解密用(当然了提供几个参数看自己的需要而定)。比如个WebService...
  • django-uniauth django-uniauth是一个应用程序,它允许通过大学常用的服务(例如 )进行身份验证,同时还允许自定义身份验证方案。 这种方法允许开发人员利用大学数据库中包含的用户数据,而不必严格地将自己绑定到...
  • 身份验证

    千次阅读 多人点赞 2019-10-17 20:44:21
    传统身份验证方法 HTTP 是一种没有状态的协议,也就是它并不知道是谁是访问应用。这里我们把用户看成是客户端,客户端使用用户名还有密码通过了身份验证,不过下回这个客户端再发送请求时候,还得再验证一下。 ...
  • 社交网络和用户“身份疲劳”正迫使企业接受分布式身份作为其数据和应用程序的身份验证途径。 实际上,根据ISACA,国际专业协会致力于IT治理(请参阅参考资料 ): “ IT的消费化”是近年来影响IT组织的最重要趋势...
  • IIS的几种身份验证方式

    千次阅读 2018-10-21 01:05:02
    集成Windows身份验证:用于发送Kerberos票证,通过网络向用户发送请求验证用户身份信息,可提供较高的安全等级 Windows域服务器的摘要式身份验证:要求用户提供账号和密码,并将此信息以HashaMD5方式或者信息摘要在...
  • 关于ssh用户身份验证不能选择password

    千次阅读 2022-02-23 02:17:57
    最近刚学完SpringBoot,Spring... 问题 Xhell连接服务器,必须输入公匙才能登录 今天刚买服务器没多久,小白一个,没整公匙,没得公匙密码,直接给我整不会了啊这 于是百度 ssh用户身份验证不能选择password 百度后:...
  • Oracle身份验证的方法是Oracle数据库中比较基本的知识,下面为您介绍几种常用的Oracle身份验证方法,希望对您学习Oracle身份验证方面能有所帮助。配置身份验证Oracle为用户账户提供了三种Oracle方法。(1)密码验证当...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 131,614
精华内容 52,645
热门标签
关键字:

常用的身份验证方法有