shadow1ng/fscan · error

unsupported oracle verifier type %d

Error message

unsupported oracle verifier type %d

What it means

After receiving the server's authentication response, the library derives the session key from the stored password verifier. The verifier type recorded in the auth response has a variant the library does not implement (only the implemented 11g/12c verifier schemes are supported), so it fails with the numeric verifier type.

Source

Thrown at plugins/services/oracle_raw.go:1370

		salt, err := hex.DecodeString(auth.salt)
		if err != nil {
			return nil, err
		}
		h := sha1.New()
		_, _ = h.Write(append([]byte(password), salt...))
		key = append(h.Sum(nil), 0, 0, 0, 0)
	case 18453:
		salt, err := hex.DecodeString(auth.salt)
		if err != nil {
			return nil, err
		}
		message := append(salt, []byte("AUTH_PBKDF2_SPEEDY_KEY")...)
		speedyKey = oracleGenerateSpeedyKey(message, []byte(password), auth.pbkdf2VgenCount)
		h := sha512.New()
		_, _ = h.Write(append(speedyKey, salt...))
		key = h.Sum(nil)[:32]
	default:
		return nil, fmt.Errorf("unsupported oracle verifier type %d", auth.verifierType)
	}
	if err != nil {
		return nil, err
	}
	auth.serverSessKey, err = oracleDecryptSessionKey(padding, key, auth.eServerSessKey)
	if err != nil {
		return nil, err
	}
	auth.clientSessKey = make([]byte, len(auth.serverSessKey))
	for {
		if _, err = rand.Read(auth.clientSessKey); err != nil {
			return nil, err
		}
		if !bytes.Equal(auth.clientSessKey, auth.serverSessKey) {
			break
		}
	}
	auth.eClientSessKey, err = oracleEncryptSessionKey(padding, key, auth.clientSessKey)

View on GitHub (pinned to 95cc12e753)

Solutions

  1. Check the server's password verifier version (DBA_USERS.PASSWORD_VERSIONS) and align it with what the library supports (e.g. 11G/12C variants it implements).
  2. Re-create the user account with a supported verifier: ALTER USER ... identified by ... after adjusting SEC_CASE_SENSITIVE_LOGON / sqlnet.allowed_logon_version_client.
  3. Upgrade the library to a version supporting the newer verifier, or use godror/ODPI-C for 12C+ exclusive verifier setups.

Example fix

-- before: account only has 12C-exclusive verifier the lib can't use
ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON=TRUE;
-- after: allow a verifier generation the library supports
ALTER USER app_user IDENTIFIED BY "NewPassword"; -- regenerated with supported verifier
ALTER SYSTEM SET SQLNET.ALLOWED_LOGON_VERSION_SERVER=11;
Defensive patterns

Strategy: validation

Validate before calling

-- Verify the account's verifier is one the library supports:
-- SELECT username, password_versions FROM dba_users WHERE username = 'APP_USER';
-- Prefer accounts with 10G/11G verifiers or configure SQLNET.ALLOWED_LOGON_VERSION_SERVER accordingly.

Prevention

When it happens

Trigger: The O5LOGON response's verifierType field is a value outside the implemented switch cases (e.g. a 12C verifier variant or a future/patched scheme), hitting the default branch during password-based session key derivation.

Common situations: Connecting to a database using newer password verifier generation (e.g. 12c verifiers with PBKDF2 variants configured via SEC_CASE_SENSITIVE_LOGON / sqlnet.allowed_logon_version settings) that the library doesn't handle; patched server with custom verifier.

Related errors


AI-assisted analysis of shadow1ng/fscan@95cc12e753 (2026-09-06). Data as JSON: /api/errors/5923520c6bc2e686. Report an issue: GitHub.