how can I create b) all users should have unique usernames and passwords. Password should be at least 8 characters long (enforced).
I know how to enforce 8 character in pl sql but how can I make sure user name and password is unique.
Oracle provides a function to be compiled under SYS for password verification and it's complexity. You will find it in $ORACLE_HOME/rdbms/admin/utlpwdmg.sql.
With different releases, the function has been modified and new functions have been added. With 12c, there are four more functions, ora12c_verify_function , ora12c_strong_verify_function and two helper functions complexity_check and string_distance.
Have a look at http://www.oradba.ch/2013/07/oracle-12c-new-password-verify-function/
Related
I know 3 lengths are supported for example "SAA" but "SA" or "S" is possible?
My Oracle versions are 11.2.0.4, 11.2.0.1, 12.1 and 12.2. What is the minimum username length on these versions?
There is no restriction on the minimum length of the username in any oracle version.
SQL> create user a identified by oracle;
User created.
SQL>
It is mentioned in the oracle documents that,
Specify the name of the user to be created. This name can contain only
characters from your database character set and must follow the rules
described in the section "Schema Object Naming Rules". Oracle
recommends that the user name contain at least one single-byte
character regardless of whether the database character set also
contains multibyte characters.
Also refer this: Database Object Naming Rules
Hello I want to know what's different between
Create User C##USERNAME
and
Create user USERNAME
in oracle database? Oracle 19c
In versions you tagged (10g and 11g), none (except that it makes your life more complicated than it should be).
In later Oracle database versions, it is related to CDB. From CREATE USER (19c version, as edited question suggests):
(user:) Specify the name of the user to be created. This name can contain only characters from your database character set and must follow the rules described in the section "Database Object Naming Rules". Oracle recommends that the user name contain at least one single-byte character regardless of whether the database character set also contains multibyte characters.
In a non-CDB, a user name cannot begin with C## or c##.
In a CDB, the requirements for a user name are as follows:
The name of a common user must begin with characters that are a case-insensitive match to the prefix specified by the COMMON_USER_PREFIX initialization parameter. By default, the prefix is C##.
The name of a local user must not begin with characters that are a case-insensitive match to the prefix specified by the COMMON_USER_PREFIX initialization parameter. Regardless of the value of COMMON_USER_PREFIX, the name of a local user can never begin with C## or c##.
I am planning to keep password hash in my database rather than plain text. What my concern is when I execute my query from JDBC in a prepared statements like:
SELECT username FROM users WHERE username = 'userName'
and password = dbms_crypto.hash(utl_raw.cast_to_raw('password'),3);
or
INSERT INTO users VALUES ('username', dbms_crypto.hash(utl_raw.cast_to_raw('passowrd'),3);
or If I call PLSQL procedure which expect me to pass the plaintext password and then thse procedures will have queries like above in their body. My concern can somebody tap my passwords sent from my server to my database through these queries via JDBC. Is it better to use prepared statement or plsql procedure to overcome this security concern? Or should I hash my passwords using my java code first and then pass these password for insertion or selection?
The only way to overcome the security issue that you quote is to pre-hash your passwords server-side prior to sending it over the wire.
That's best practice.
HOWEVER dbms_crypto.hash is not secure for password storage and you should not be using it. Instead, you should be using BCrypt with an appropriate salt and cost. Generate the bcrypt hash in your server code, then send it to the database already hashed (for inserts) or pull the hash from the database using the username (for selects).
Additionally, I would like to point out that it's a severe problem if an attacker can get close enough to your database to see the queries you're running on it. While I am a fan of defense-in-depth, so you should protect against the possibility, if that's actually happening that's a massive issue.
I would recommend either encrypting the password before you send the sql with java encryption or secure your SQLNet.
For more information on securing SQLNet refer to orafaq.com they have a short and good description: http://www.orafaq.com/wiki/Network_Encryption
BTW: these SQL statements are not "prepared".
ircmaxell's answer is the best solution.
If for some reason you are unable to pre-hash the value, and must pass the plaintext password to the database, you should at least ensure the database does not cache the statement that includes the plaintext password. A specific statement can be purged from the shared pool, i.e. GV$SQL, with the following code:
--Remove a SQL statement from the shared pool.
begin
for cached_sql in
(
select *
from gv$sql
where lower(sql_fulltext) like
'insert into users values%dbms_crypto.hash(utl_raw.cast_to_raw%'
) loop
sys.dbms_shared_pool.purge(cached_sql.address||','
||cached_sql.hash_value, 'C', 1);
end loop;
end;
/
I'm currently porting a Code Igniter based application from MySQL to Oracle (11g) for a specific client. Both the MySQL and Oracle back-ends have to work in conjunction (i.e. we cannot drop the one or the other).
The MySQL DB uses around 100 tables of which ALL identifiers are in lowercase. When I migrate this DB to Oracle, using Oracle's SQL Developer tool, I end up with a 'properly' converted DB, but... with all uppercase identifiers.
Now, for normal usage this isn't really a problem, but the issue arises when using the CI Active Record class. It generates queries to the effect of:
SELECT "somecolumn" FROM "sometable" WHERE "someothercolumn" = somevalue
The issue is that when the " quotes are used for these identifiers, Oracle forces these identifiers to be interpreted in a case sensitive way, which in this case is wreaking havoc.
Patching the core code of CI and/or the application to either make all queries use case insensitive identifiers (i.e. by dropping the usage of the " quotes around the identifiers) or to convert all identifiers to uppercase ones on the fly, is IMO not desired, as a potential future framework upgrade is then compromised. Renaming ALL MySQL identifiers to become in uppercase is also a very unattractive scenario and has an even bigger impact on the application itself -- not an option for sure.
Instead, what I would like to achieve, is to have the migration process (i.e. using SQL Developer) simply respecting the case of the source DB and to perform the conversion exactly as it does up to now, with the exception that the identifiers do not get changed to their uppercase version.
I have searched a fair deal online to find a way to achieve this, and so far it has been to no avail.
Does anyone know if this can be done, and if so: how?
Is the conversion to all uppercase identifiers by any chance a global DB setting, perhaps?
I would have assumed this to be a trivial thing, but I haven't been able to figure it out so far and what little related references that I did come across do not sound very promising...
If you can acquire a schema script created by the database migration all you need to do is change the identifiers ( tablenames, view names, column names etc ) to be surrounded with double quotation marks. (I'm not sure if SQL Developer migrations actually has the option to preserve the case).
Without the quote marks Oracle will assume all identifiers are case-insensitive. However this is stored internally as upper case strings in the data dictionary. By using quote marks will force Oracle to use the exact case for the schema objects.
eg.
create table Customers
(
Name varchar2(100),
CreationDate date not null
);
will create CUSTOMERS internally in the data-dictionar and you can write queries like:
select name, creationdate from customers;
alternatively:
create table "Customers"
(
"Name" varchar2(100),
"CreationDate" date not null
);
will create "Customers" internally. You can only write queries using quotes and exact case:
select "Name", "CreationDate" from "Customers";
I have hit this before and simply edited oci8_driver.php (../system/database/oci) as follows:
// The character used for excaping
var $_escape_char = '"';
to
// The character used for excaping
var $_escape_char = '';
Stewart
I have to change the character set from AL32UTF8 to WE8MSWIN1252 in a Oracle 11g r2 Express instance... I tried to use the command:
ALTER DATABASE CHARACTER SET WE8MSWIN1252;
But it fails saying that MSWIN1252 isn't a superset of AL32UTF8. Then I found some articles talking about CSSCAN, and that tool doesn't seem to be available in Oracle 11 Express.
http://www.oracle-base.com/articles/10g/CharacterSetMigration.php
Anyone has an idea on how to do that? Thanks in advance
Edit
Clarifying a little bit: The real issue is that I'm trying to import data into a table that has a column defined as VARCHAR(6 byte). The string causing the issue is 'eq.mês', it needs 6 bytes in MSWIN1252 and 7 bytes in UT8
You can't.
The Express Edition of 11g is only available using a UTF-8 character set. If you want to go back to the express edition of 10g, there was a Western European version that used the Windows-1252 character set. Unlike with the other editions, Oracle doesn't support the full range of character sets in the Express Edition nor does it support changing the character set of an existing XE database.
Why do you believe you need to change the database character set? Other than potentially taking a bit more storage space to support the characters in the upper half of the Windows-1252 range, which generally aren't particularly heavily used, there aren't many downsides to a UTF-8 database.
I would say that your best option when you want to go to a character set that supports only a subset of the original characters, that your best option is to use exp and imp back (or expdp and impdp).
Are you sure that no single table will contain any character not found in the 1252 code page ?
The problem of only execute that ALTER DATABASE command is that the Data Dictionary was not converted and it can be corrupted.
I had the same problem. In my case, we are using a Oracle 11g Express Edition (11.2.0.2.0) and we really need that it runs on WE8MSWIN1252 character set, but I cannot change the character set on installation (it always install with AL32UTF8).
With a Oracle Client 11g installed as Administrator and run only the csscan full=y (check this link https://oracle-base.com/articles/10g/character-set-migration) and we notice that are lossy and convertible data problems in our database. But, the problems are with the MDSYS (Oracle Spatial) and APEX_040000 (Oracle Application Express) schemas. So, as we dont need this products, we remove them (check this link: http://fast-dba.blogspot.com.br/2014/04/how-to-remove-unwanted-components-from.html).
Then, we export with expdp the users schemas and drop the users (they must be recreated at the end of the process).
Executing csscan again with full=y capture=y, it reports that: The data dictionary can be safely migrated using the CSALTER script. If the report doesnt have this, the csalter.plb script will not work, because there are some conditions that will not be satisfied:
changeless for all CHAR VARCHAR2, and LONG data (Data Dictionary and Application Data)
changeless for all Application Data CLOB
changeless and/or convertible for all Data Dictionary CLOB
In our case, this conditions were satisfied and we could ran the CSALTER script successfully. Moreover, this script executes the ALTER DATABASE command you are trying to run and it converts the CLOB data of Data Dictionary that is convertible.
Finally, we create the users and the tablespaces of our application and we import the dump of the user data successfully.