Skip to Main Content

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question, ian.

Asked: March 10, 2008 - 7:08 pm UTC

Answered by: Tom Kyte - Last updated: April 22, 2013 - 8:26 pm UTC

Category: Database - Version: 10.2

Viewed 10K+ times! This question is

You Asked

Have just downloaded and installed 11.1.
imported by 10g2 database and started to run my forms application
My sql reports started failing - invalid username/password

running under Vista


C:\Users\ian>sqlplus CHEST/norma@m

SQL*Plus: Release 11.1.0.6.0 - Production on Mon Mar 10 22:56:47 2008

Copyright (c) 1982, 2007, Oracle. All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Pr
oduction
With the Partitioning, OLAP, Data Mining and Real Application Testing options

C:\Users\ian>sqlplus CHEST/NORMA@m

SQL*Plus: Release 11.1.0.6.0 - Production on Mon Mar 10 22:56:59 2008

Copyright (c) 1982, 2007, Oracle. All rights reserved.

ERROR:
ORA-01017: invalid username/password; logon denied


Enter user-name:


Regards

Ian


and we said...

and you rated our response

  (14 ratings)

Is this answer out of date? If it is, please let us know via a Review

Reviews

11g client, 10g database

March 12, 2008 - 10:51 am UTC

Reviewer: A reader

Tom,
If I have a user running 11g client and connecting to a 10g database, the passwords will not be case sensitive. Is this correct?

Thanks

Tom Kyte

Followup  

March 12, 2008 - 5:38 pm UTC

10g was not case sensitive, correct.

March 12, 2008 - 11:34 am UTC

Reviewer: A reader

no it won't be case sesitive- but it is unusual to connect from higher version client to a db of lower version
Tom Kyte

Followup  

March 12, 2008 - 5:41 pm UTC

no, not today - not with application servers wanting the newest jdbc drivers and whatnot available.

I would say 10 years ago, that might have been true - as updating thousands of clients was hard, and the clients used to lag way behind.

Now that the clients are application servers - they are tending to actually start to run ahead in many cases.

11g only case sensitive

March 12, 2008 - 11:36 am UTC

Reviewer: Ian Gallacher from Scotland

Hi

New parameter introduced in 11G release

sec_case_sensitive_logon

which defaults to TRUE when you install the database!

simply
alter system set sec_case_sensitive_logon=False
to return to normal !

Ian



Not available in previous releases


11g client, 10g database

March 13, 2008 - 1:03 pm UTC

Reviewer: A reader

Tom,
You hit the nail right on the head. The reason we want to connect to a 10g database from 11g client is that we want latest version of .Net drivers on the application servers. The drivers are available with 11g client.

There was a time when we used to follow the "client has to be lesser or equal version to the database" rule. Now Oracle provides so many new features which allow co-hosting of different client versions, allows applications to use different driver versions on the same host and provides backward client compatibility with database versions.

I guess it is part of the evolving technology that we have to change the rules with time.

Thanks...

What case will existing passwords be after upgrade?

May 01, 2009 - 3:34 pm UTC

Reviewer: Mike from Cleveland, OH USA

Is there any way to know whether passwords will be upgraded as uppercase, lowercase, or 'however it was originally typed'?

Suppose I know that I am currently be able to use
MYPASSWORD
mypassword
MyPassWord
and they are all accepted when connecting to a 10g database. It is certainly possible that the password was originally typed as mYpASSwORD, even, but I really don't have any way to find out.

What will the the password be after upgrading the database to 11g?
Tom Kyte

Followup  

May 02, 2009 - 12:01 pm UTC

they were always rolled to uppercase in the past

Passwords after migrating to 11g

May 06, 2009 - 9:35 pm UTC

Reviewer: Mike from Cleveland, OH USA

I found the following in the 11g Upgrade Companion:

In Oracle Database 11g password are case sensitive. In previous versions the passwords are not
case sensitive. This feature is enabled by the initialization parameter sec_case_sensitive_logon
that is TRUE by default. Setting sec_case_sensitive_logon to FALSE disables the case sensitive
feature. After migrating the Oracle database from previous versions the existing user passwords are
case-insensitive until users change it.


So it sounds like this scenario has already been planned for. It also describes a new column DBA_USERS.PASSWORD_VERSIONS to show under which database versions the password has been set (and, therefore, to indicate whether case-sensitivity is appropriate).

sec_case_sensitive not working properly

June 30, 2011 - 1:49 am UTC

Reviewer: KC from Philippines

the sec_case_sensitive parameter seems not to work on one of our databases.

SQL> conn MYUSER/MYPASSWORD@MYDB101
Connected.
SQL> conn myuser/mypassword@mydb101
Connected.
SQL> sho parameter case_sensitive

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
sec_case_sensitive_logon             boolean     TRUE

is there any other parameter that i should set?

Tom Kyte

Followup  

July 01, 2011 - 8:18 am UTC

http://docs.oracle.com/docs/cd/E11882_01/network.112/e16543/authentication.htm#DBSEG3225

<quote>
In previous releases of Oracle Database, passwords were not case sensitive. If you import user accounts from a previous release, for example, Release 10g, into the current database release, the case-insensitive passwords in these accounts remain case insensitive until the user changes his or her password. </quote>


sounds like a legacy account that hasn't changed their password yet.

sec_case_sensitive not working properly

June 30, 2011 - 2:00 am UTC

Reviewer: KC from Philippines

by the way, this is the version of my database


SQL> select * from v$version
  2  /

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE    11.2.0.2.0      Production
TNS for HPUX: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production

Logins failing, but only from Forms running under OC4J

September 21, 2011 - 10:50 am UTC

Reviewer: Chuck from Salem, OR

We just migrated to database version 11.1.0.7 fom 10.1.0.4, and newly added employees were having trouble running their Forms under OC4J. While they are able to connect to the database within Forms Builder, when they try to run the form they received an "invalid username/password" error, and then they receive a popup asking for username/password (pre-filled with their username, and database instance).

By setting the SEC_CASE_SENSITIVE_LOGON parameter to FALSE, everything starts working for them. Since the production database has been running with SEC_CASE_SENSITIVE_LOGON set to TRUE without problem, I'd like to keep it in place. So that means trying to figure out how to get OC4J to work for newly added users (or, for people who change their passwords). Any suggestions?
Tom Kyte

Followup  

September 21, 2011 - 12:31 pm UTC

I'd try quoted identifiers quick to see if that fixes it - that would confirm that the forms app is rolling things to upper case by default..

"myusername"/"mypassword"


(sorry, I don't have any forms installs or anything to play with...)

Forms Patch

September 21, 2011 - 3:38 pm UTC

Reviewer: Stephen from UT USA

There is an oracle patch to fix this problem.

Forms Bundle Patch 9593176 for forms 10.1.2.3.
Tom Kyte

Followup  

September 21, 2011 - 10:46 pm UTC

thanks much, i just don't work with forms at all - not really at all since about 1995 when this "internet" thingy started to catch on myself...

SYS password is still case sensitive

March 07, 2012 - 9:53 am UTC

Reviewer: Gary from Atlanta, GA

I have just installed Oracle 11g R2 and took care of setting sec_case_sensitive_login as FALSE. It seems to have applied to all but my SYS user's password. Is SYS an exception or is it any user that connects as SYSDBA?
Tom Kyte

Followup  

March 07, 2012 - 7:06 pm UTC

you'd have to sync up the external password file.


the password file is used to verify remote sysdba logins, it is maintained when you "alter user identified by". the next time you alter the user to change the password, this will take place.

Case-only PWD Change

April 22, 2013 - 5:50 pm UTC

Reviewer: Russ Cannon from Maxwell AFB, Gunter Annex

We have noticed that changing a password only by swapping the case of the letters is rejected as changing to the same password under 11g with case sensitive passwords enabled.

sqlplus /nolog

SQL*Plus: Release 11.2.0.3.0 Production on Mon Apr 22 17:36:16 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

SQL> conn /as sysdba
Connected.

sho parameter sec_case

NAME                     TYPE    VALUE
------------------------ ------- -----
sec_case_sensitive_logon boolean TRUE

SQL> create user u1 identified by Ab1$;

User created.

SQL> alter user u1 identified by aB1$;
alter user u1 identified by aB1$
*
ERROR at line 1:
ORA-28007: the password cannot be reused


SQL> alter user u1 identified by Ab1#;

User altered.

The password changes successfully when changing $ to # but not when swapping the case of 'A' to 'a' and 'b' to 'B'.  Changing just the case of letters creates a valid new password--'a' is not equal to 'A'--but this is not accepted by Oracle even with case sensitive passwords enabled.

We are guessing that this is because the 10g hash (sys.user$.password) doesn't change even though the 11g (sys.user$.spare4) would.  If this is the case, is there any way of suppressing the generation of the 10g hash so that such a password change would be accepted?  Is anything like this even possible?

Cheers,
Russ

Tom Kyte

Followup  

April 22, 2013 - 8:26 pm UTC

Not that I am aware of...

April 22, 2013 - 9:10 pm UTC

Reviewer: Michael Kutz from Greensboro, NC

I can't reproduce Russ Cannon's error.
I suspect because I don't have a 'password verify function' set in my profile on my dev database.

SQL*Plus: Release 11.2.0.3.0 Production on Mon Apr 22 17:02:50 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

SQL> connect / as sysdba;
Connected.
SQL> select profile, limit
  2  from dba_profiles
  3  where resource_name='PASSWORD_VERIFY_FUNCTION';

PROFILE                        LIMIT
------------------------------ ----------------------------------------
DEFAULT                        NULL

SQL> alter user joeblack identified by abc123;

User altered.

SQL> alter user joeblack identified by abc123;

User altered.

SQL>connect joeblack/abc123;
Connected.
SQL> alter user joeblack identified by abc123;

User altered.

SQL>


April 22, 2013 - 9:18 pm UTC

Reviewer: Michael Kutz from Greensboro, NC

I take that back.
I had 'password_reuse_max' set to unlimited.