1. Describe your new request in detail
In Thin mode, connecting as a database user whose password only carries the legacy 10G verifier (AUTH_VFR_DATA verifier type 0x939) fails with:
DPY-3015: password verifier type 0x939 is not supported by python-oracledb in thin mode
Thick mode (via Instant Client / OCI) connects to the very same account without any problem. It would be great for Thin mode to implement the same O5LOGON handshake so these accounts also work without Instant Client.
This matters for legacy application schemas that still carry only a 10G verifier — for example because SEC_CASE_SENSITIVE_LOGON=FALSE was used historically, or the password was never re-hashed after a database upgrade. Today the only workarounds are to switch to Thick mode or to run ALTER USER ... IDENTIFIED BY ... to regenerate the 11G/12C verifiers, which is not always possible when the account cannot be modified.
I have implemented this and would like to submit a pull request. The handshake is the same O5LOGON/AES flow already used for 11G/12C — only the source of the key material differs: the AES-128 key is the 8-byte binary 10G (DES) verifier padded to 16 bytes with zeros, and the combo key reuses the existing 12C PBKDF2 path. It has been verified end-to-end against Oracle Database 19c on two databases; the 11G and 12C code paths are unchanged.
I'm aware the 10G verifier is a legacy, weak (case-insensitive, DES-based) hash. The change does not create or encourage 10G verifiers — it only lets Thin mode authenticate against accounts that already have one, matching Thick-mode behavior. If you would prefer it gated behind an opt-in (a connection parameter or environment flag), I'm happy to adjust. Would you accept such a PR, and in what form?
2. Give supporting information about tools and operating systems. Give relevant product version numbers.
- python-oracledb: current
main (Thin mode)
- Oracle Database: 19c (19.28)
- Account: password with only the 10G verifier (verifier type
0x939)
- Error today:
DPY-3015 in Thin mode; the same account connects in Thick mode
- A working implementation (3-file change + a gated test) is ready on a branch:
zilent1:thin-10g-o5logon
1. Describe your new request in detail
In Thin mode, connecting as a database user whose password only carries the legacy 10G verifier (
AUTH_VFR_DATAverifier type0x939) fails with:Thick mode (via Instant Client / OCI) connects to the very same account without any problem. It would be great for Thin mode to implement the same O5LOGON handshake so these accounts also work without Instant Client.
This matters for legacy application schemas that still carry only a 10G verifier — for example because
SEC_CASE_SENSITIVE_LOGON=FALSEwas used historically, or the password was never re-hashed after a database upgrade. Today the only workarounds are to switch to Thick mode or to runALTER USER ... IDENTIFIED BY ...to regenerate the 11G/12C verifiers, which is not always possible when the account cannot be modified.I have implemented this and would like to submit a pull request. The handshake is the same O5LOGON/AES flow already used for 11G/12C — only the source of the key material differs: the AES-128 key is the 8-byte binary 10G (DES) verifier padded to 16 bytes with zeros, and the combo key reuses the existing 12C PBKDF2 path. It has been verified end-to-end against Oracle Database 19c on two databases; the 11G and 12C code paths are unchanged.
I'm aware the 10G verifier is a legacy, weak (case-insensitive, DES-based) hash. The change does not create or encourage 10G verifiers — it only lets Thin mode authenticate against accounts that already have one, matching Thick-mode behavior. If you would prefer it gated behind an opt-in (a connection parameter or environment flag), I'm happy to adjust. Would you accept such a PR, and in what form?
2. Give supporting information about tools and operating systems. Give relevant product version numbers.
main(Thin mode)0x939)DPY-3015in Thin mode; the same account connects in Thick modezilent1:thin-10g-o5logon