ORA-02153: Invalid VALUES Password String – Why It Happens and How to Fix It (CREATE USER)

If you’ve ever migrated users between Oracle databases or tried to recreate a user exactly as it existed in another environment, you’ve probably used the IDENTIFIED BY VALUES clause. It looks simple, but one small formatting issue can instantly break the process and throw this error:

ORA-02153: invalid VALUES password string

In this blog, we’ll break down why this error happens, what Oracle actually expects, and how you fixed it correctly—in a way that’s practical, human-friendly, and SEO-optimized for DBAs working in real production environments.

---

What Is ORA-02153?

ORA-02153 occurs when Oracle cannot parse or validate the password hash provided in the IDENTIFIED BY VALUES clause during a CREATE USER or ALTER USER operation.

This clause is not for plain-text passwords. It is meant for internal Oracle password hashes, usually copied from:

• DBA_USERS.PASSWORD
• DBA_USERS.SPARE4
• Export / migration scripts
• Legacy user recreation scripts

When Oracle sees something it doesn’t like in that hash string, it immediately stops with ORA-02153.

---

The Problematic Command (What Went Wrong)

Here’s the original command that failed:

CREATE USER "TEST" IDENTIFIED BY VALUES 'S:C295FF98A656B6AB0C9B348D01BC69B
B25BA9CF22A59F550363E87F2DD43;T:889819978B7B73643DEA8DC0CA165B14C6CB53B96E829ABC
C2A910966E69DDB5E2EAB85A4C264A06431B1D24E05995258BBE77C2725438493B9B6721677693C4
3CF360E4E88B5924D2CCAB3C5AC26C0D'
DEFAULT TABLESPACE "USERS"
TEMPORARY TABLESPACE "TEMP";

And Oracle responded with:

ORA-02153: invalid VALUES password string

At first glance, the password string looks valid. It contains both:

• S: → SHA-1 / legacy password hash
• T: → 12c+ password version hash

So what’s the issue?

---

The Root Cause: Line Breaks in the Password Hash

The real problem is subtle but critical:

👉 The password hash was broken across multiple lines.

Oracle expects the entire IDENTIFIED BY VALUES string to be:

• A single continuous string
• With no spaces
• With no line breaks
• With no hidden characters

Even though SQL*Plus visually allows multi-line input, Oracle internally treats line breaks as invalid characters inside the password hash.

Oracle Is Extremely Strict Here

Unlike SQL or PL/SQL syntax, password hashes are binary-safe strings. Oracle does not attempt to “fix” or normalize them. If the hash does not match the exact expected format, you get ORA-02153.

---

The Corrected Command (Why It Worked)

Here is the corrected version that executed successfully:

CREATE USER "TEST"
IDENTIFIED BY VALUES 'S:C295FF98A656B6AB0C9B348D01BC69BB25BA9CF22A59F550363E87F2DD43;T:889819978B7B73643DEA8DC0CA165B14C6CB53B96E829ABCC2A910966E69DDB5E2EAB85A4C264A06431B1D24E05995258BBE77C2725438493B9B6721677693C43CF360E4E88B5924D2CCAB3C5AC26C0D'
DEFAULT TABLESPACE "USERS"
TEMPORARY TABLESPACE "TEMP";

Result:

User created.

Why This Works

• The entire password hash is on a single line
• No whitespace inside the quoted string
• S: and T: sections are preserved exactly
• Oracle can validate the hash successfully

---

Understanding the S: and T: Prefixes

When you see something like this:

S:<hash>;T:<hash>

It means:

• S: → Older password version (pre-12c compatibility)
• T: → 12c+ password version (mandatory in newer releases)

Modern Oracle databases (12c, 19c, 21c, 23ai) require the T: hash. If it’s missing or malformed, user authentication may fail—or user creation may fail outright.

---

Common Scenarios Where ORA-02153 Appears

This error is very common in real DBA work, especially during:

1. User Migration Between Databases

Copying password hashes manually from DBA_USERS output.

2. Copy-Paste from Emails or Documents

Line wrapping silently inserts newlines or spaces.

3. SQL*Plus Formatting Issues

Terminal width causes hashes to wrap visually.

4. Scripted User Creation

Password string accidentally broken across lines in shell or SQL scripts.

---

Best Practices to Avoid ORA-02153

✅ Always Keep the Hash on One Line

Even if it’s very long—one line only.

✅ Copy Carefully from DBA_USERS

Use SQL like:

SET LONG 100000
SET PAGESIZE 0
SET LINESIZE 200

✅ Prefer ALTER USER IDENTIFIED BY PASSWORD

When possible, let users reset passwords instead of migrating hashes.

✅ Validate Quotes

Make sure there is:

• One opening '
• One closing '
• No extra characters in between

---

Should You Still Use IDENTIFIED BY VALUES?

Honestly? Only when absolutely necessary.

Oracle does not recommend this method unless:

• You are doing a controlled migration
• Passwords must remain unchanged
• Users cannot reset passwords

For most environments, it’s safer and cleaner to:

CREATE USER TEST IDENTIFIED BY StrongPassword123;

And force a password reset later if needed.

---

Oracle Version Note (Important)

In newer versions of Oracle Corporation databases (19c, 21c, 23ai):

• Password versions are stricter
• Legacy hashes may be rejected
• Missing or malformed T: hashes cause failures

Always ensure the source and target databases are compatible in terms of password versions.

---

Final Thoughts

ORA-02153 is one of those errors that looks confusing but is actually very simple once you know the rule:

Oracle password hashes must be copied exactly, on a single line, with zero formatting changes.

In your case, nothing was wrong with the hash itself—the issue was purely line breaks inside the IDENTIFIED BY VALUES string.

Fix that, and Oracle is happy again.

---

Related Articles

• ORA-01652: Unable to Extend Temp Segment in Temporary Tablespace – Fix Guide
• ORA-04030: Out of Process Memory in PGA – Oracle Memory Fix Guide
• ORA-01578: ORACLE Data Block Corruption Detected – Fix and Recovery Guide
• How to Monitor and Tune Oracle Undo Tablespace (Avoid ORA-01555 & ORA-30036)