【问题标题】:Does the Oracle JDBC client encrypt password when you make a connection?建立连接时,Oracle JDBC 客户端是否加密密码?
【发布时间】:2023-03-31 09:17:01
【问题描述】:

当您使用Oracle JDBC 客户端库进行Oracle 连接时,密码或安全握手是否默认加密? (想知道在使用 Oracle JDBC 客户端库建立连接时,密码是否存在通过网络嗅探的风险)

【问题讨论】:

    标签: oracle jdbc


    【解决方案1】:

    密码在通过网络传输时始终被加密。

    这并不是说它不受攻击。如果攻击者可以获取用户密码的hash并且他们可以监控合法客户端和数据库之间的网络流量,那么就有可能获得明文密码.

    出于好奇,这里总结了跨不同版本的 Oracle 数据库软件的身份验证过程。处理加密密码传输的步骤以粗体显示。 JDBC 驱动程序正在使用哪个版本的身份验证协议并不完全直观,因为它并不总是与其宣传的版本相匹配。这是因为客户端可以协商它希望使用的协议。例如,11g JDBC 驱动程序在连接到 11g 数据库时可能不一定使用 11g 身份验证协议(它可能会回退到 10g 身份验证协议)。我忘记了哪些驱动程序使用哪些协议。

    Oracle Database 8 中的身份验证协议

    1. 客户端为特定用户请求服务器会话密钥。
    2. 服务器生成服务器会话密钥。
    3. 服务器使用请求的用户密码哈希作为密钥对服务器会话密钥进行加密。
    4. 服务器将加密的服务器会话密钥传输给客户端。
    5. 客户端使用用户的密码哈希作为密钥解密加密的服务器会话密钥。
    6. 客户端使用服务器会话密钥作为密钥对用户密码进行加密。 (基于DES的专有算法)
    7. 客户端将加密后的密码发送给服务器。
    8. 服务器使用其服务器会话密钥作为密钥对加密密码进行解密。
    9. 服务器计算解密密码的哈希值。
    10. 如果计算出的密码哈希(来自第 9 步)与存储在服务器上的副本匹配,则用户提供了正确的密码。

    Oracle Database 9i 中的身份验证协议

    1. 客户端为特定用户请求服务器会话密钥。
    2. 服务器生成服务器会话密钥。
    3. 服务器使用请求的用户密码哈希作为密钥对服务器会话密钥进行加密。
    4. 服务器将加密的服务器会话密钥传输给客户端。
    5. 客户端使用用户的密码哈希作为密钥解密加密的服务器会话密钥。
    6. 客户端使用服务器会话密钥作为密钥对用户密码进行加密。 (基于DES的专有算法)
    7. 客户端将加密后的密码发送给服务器。
    8. 服务器使用其服务器会话密钥作为密钥对加密密码进行解密。
    9. 服务器计算解密密码的哈希值。
    10. 如果计算出的密码哈希(来自第 9 步)与存储在服务器上的副本匹配,则用户提供了正确的密码。

    Oracle 数据库 10g 中的身份验证协议

    1. 客户端向服务器请求一个会话密钥,指定它希望以哪个用户身份连接。
    2. 服务器生成服务器会话密钥。
    3. 服务器使用请求的用户密码哈希作为密钥对服务器会话密钥进行加密。
    4. 服务器将加密的服务器会话密钥传输给客户端。
    5. 客户端使用请求的用户密码哈希作为密钥解密加密的服务器会话密钥。
    6. 客户端生成客户端会话密钥。
    7. 客户端将客户端会话密钥与服务器会话密钥相结合。
    8. 客户端对用户密码加盐。
    9. 客户端使用组合会话密钥(来自第 7 步)作为其密钥对用户的加盐密码进行加密。 (AES-128)
    10. 客户端使用用户的密码哈希作为密钥对客户端会话密钥进行加密。
    11. 客户端将加密的客户端会话密钥和加密的加盐用户密码传输到服务器。
    12. 服务器使用请求的用户密码哈希解密加密的客户端会话密钥。
    13. 服务器将客户端会话密钥与其服务器会话密钥相结合。
    14. 服务器使用组合会话密钥(来自第 13 步)作为密钥对加密的加盐密码进行解密。
    15. 服务器取消加盐密码。
    16. 服务器对解密后的密码进行哈希处理。
    17. 服务器将计算的密码哈希(从第 16 步开始)与存储的密码哈希进行比较。如果它们相等,则用户提供了正确的密码。

    Oracle 数据库 11g 中的身份验证协议

    1. 客户端向服务器请求一个会话密钥,指定它希望以哪个用户身份连接。
    2. 服务器生成服务器会话密钥。
    3. 服务器生成验证者数据。
    4. 服务器使用请求的用户密码哈希作为密钥对服务器会话密钥进行加密。
    5. 服务器将加密的服务器会话密钥(“AUTH_SESSKEY”)和验证者数据(“AUTH_VFR_DATA”)传输给客户端。
    6. 客户端使用验证者数据作为盐对用户密码进行哈希处理。
    7. 客户端使用用户的密码哈希作为密钥解密加密的服务器会话密钥。
    8. 客户端生成客户端会话密钥。
    9. 客户端将客户端会话密钥与服务器会话密钥相结合。
    10. 客户端对用户密码加盐。
    11. 客户端使用组合会话密钥(来自第 9 步)作为其密钥对用户的加盐密码进行加密。 (AES-192)
    12. 客户端使用用户的密码哈希作为密钥对客户端会话密钥进行加密。
    13. 客户端将加密的客户端会话密钥和加密的加盐用户密码传输到服务器。
    14. 服务器使用请求的用户密码哈希解密加密的客户端会话密钥。
    15. 服务器将客户端会话密钥与其服务器会话密钥相结合。
    16. 服务器使用组合会话密钥(来自第 15 步)作为密钥对加密的加盐密码进行解密。
    17. 服务器取消加盐密码。
    18. 服务器对解密后的密码进行哈希处理。
    19. 服务器将计算出的密码哈希(来自步骤 18)与存储的密码哈希进行比较。如果它们相等,则用户提供了正确的密码。

    【讨论】:

    • 您的答案非常详细。谢谢!
    • @BestPractices:感谢您提供发布此信息的借口! :) 我不写博客,所以事情往往处于休眠状态,直到我偶然发现一个与之相关的问题。
    • 我想知道您是如何“存储”这么多细节的,以至于您可以如此迅速地取出 :)
    • @VincentMalgrat:我相信漏洞仍然存在(我可能是错的)。如果您知道用户的密码哈希,您可以解密服务器会话密钥(在第 5 步)客户端会话密钥(在第 13 步)。有了这些,您可以解密密码。听起来对吗?
    • @AdamPaynter:哦,我现在明白了,你完全正确 =) POC:soonerorlater.hu/index.khtml?article_id=512。最安全的方法可能是 SSL 加密或third-party authentication
    猜你喜欢
    • 1970-01-01
    • 2017-11-28
    • 1970-01-01
    • 1970-01-01
    • 2011-05-06
    • 2018-12-10
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多