I have a peculiar issue which i cant figureout
Database: Oracle 11g
USER:
PASSWORD_VERSIONS column in DBA_USERS table had value 10g 11g initially.
sec_case_sensitive_logon value in V$PARAMETER is null
SYS.USER$ table had some values in PASSWORD and SPARE4 columns.
I wanted to reset the password for the user SAMPLEUSER to same password again.
Steps performed to reset the password the user to same old password (by a db person)
1.updated PASSWORD_VERSIONS column value to 10g ( not sure if this got updated during below step or it was updated manually)
2.Took the Hash value from PASSWORD column from SYS.USER$ table.
3.used the old hash value(from password column in sys.user$) to reset the password -- alter user SAMPLEUSER identified by values 'hashvalue'
Now the user is not able to connect to DB as wrong password .what is the issue here.
Is it possible to fix the problem?
updated PASSWORD_VERSIONS column value to 10g
You should not be directly updating data dictionary views.
What version of the client are you using? If the only hash you provided in the alter user command was the 10G version, then you may not have re-created the proper hashes for higher version clients.
The only way to set PASSWORD_VERSIONS is by changing the SQLNET.ALLOWED_LOGON_VERSION parameter (11g) SQLNET.ALLOWED_LOGON_VERSION_SERVER (12c and up) parameter in the server's sqlnet.ora file and restarting the server. This will change the types of clients that the database can support, as specific client versions will require specific password hash values. This should NOT be set to 10 unless you actually support 10g clients. It should always/only be set to match the minimum supported client version in your architecture.
In Oracle 11g, the setting of SQLNET.ALLOWED_LOGON_VERSION has the following effects:
SQLNET.ALLOWED_LOGON_VERSION = 10 will allow both 10G and 11G passwords
SQLNET.ALLOWED_LOGON_VERSION = 11 will allow only 11G passwords
In Oracle 12 and up, the setting of SQLNET.ALLOWED_LOGON_VERSION has the following effects:
SQLNET.ALLOWED_LOGON_VERSION_SERVER=11 will keep generating 10G, 11G
and 12c password versions
SQLNET.ALLOWED_LOGON_VERSION_SERVER=12 will
generate both 11G and 12C password versions, and also remove the 10G
password version.
SQLNET.ALLOWED_LOGON_VERSION_SERVER=12a will
generate only 12c password versions
See the following link on how Oracle creates and stores password hashes, with examples for using 'identified by value' with multiple hash types for 10g, 11g, and 12c passwords:
https://seanstuber.com/how-oracle-stores-passwords/
And this advice for making sure passwords are as secure as possible given the setting of SQLNET.ALLOWED_LOGON_VERSION or SQLNET.ALLOWED_LOGON_VERSION_SERVER (specifically getting rid of the least secure 10G passwords, if possible):
https://docs.oracle.com/en/database/oracle/oracle-database/18/spmsu/finding-and-resetting-user-passwords-10g-password-version.html#GUID-D7B09DFE-F55D-449A-8F8A-174D89936304
Related
I'm considering using remote OS authentication to connect to an Oracle database (version 11g). What are the guidelines for using [remote_os_authent]
Here's what I want to do:
We set up a catalog DB to used by RMAN to store metadata about Oracle databases.
I want to connect to the catalog DB via the local machine and execute this command for resync catalog db:
rman target sys/pass#localdb;
connect catalog catuser/password#catdb;
RESYNC CATALOG;
Is it possible for me to do this through oracle Enterprise Manager job?
(I did this process by calling the execute file, but the problem is that the passwords are clear in the executable file.)
I need it because I do not want user passwords to be available and visible.
I can't use oracle valet for passwordless connection.
Using remote os authentication is considered a bad habit because it is insecure.
If you want to have scripting without having to store passwords in a readable format to prevent leaking passwords, easiest is to use the oracle wallet for this.
This still keeps you busy maintaining passwords in the database and in the wallet but it is pretty safe.
Your connection would be something line sqlplus /#tns_alias
where the tns_alias is the key into the wallet that fetches the username and the password.
An example of setup can be found here: http://ronr.blogspot.com/2017/01/cleartext-userid-and-passwords-in.html
An other option could be to enable Central Managed Users (CMU) and kerberos. This does need quite a bit of setup and is less suitable for scripting. For interactive use it works very nice, assuming you have kerberos correctly setup.
An example of CMU setup can be found here: https://blog.pythian.com/part-1-creating-an-oracle-18c-centrally-managed-users-testbed-using-oracle-cloud-infrastructure/
Please change back remote_os_authentication to false. It is not safe because users can easily be spoofed.
I enabled Always Encrypted option on a varchar column in database (MS SQL 2019).
Now, ColdFusion (2016) application is generating an error ByteArray objects cannot be converted to strings.
How to enable or register encryption for this database in the CF 2016 server?
UPDATE:
Thanks to Miguel-F comment, I went with this guide below to enable Always Encrypted and configuration of data source in CF Administrator.
https://community.hostek.com/t/sql-server-always-encrypted-columns/315#heading--ColdFusion
But, I stack on the paragraph under the heading
Using Always Encrypted Columns with ColdFusion
....
You must also ensure that the ColdFusion service account has access to the
private key. This service usually runs under the ‘cfusion’ user so you will
want to give read permissions for that user to the private key of the
‘Column Master Key’.
Do I need to create a standard user and login as that user and assign to the service ColdFusion 2016 Application Server? Does this service is reffered here as a "cfusion"?
Then, how would I give that user read permissions for the private key of the ‘Column Master Key’? Is that running certlm?
The column that I encrypted with Always Encrypted option is nvarchar(50), when encrypted, the collation changed to Latin1_General_BIN2.
Still getting this error while open the page with the reference to the column
ByteArray objects cannot be converted to strings.
Any help would be greatly appreciated.
Gena
This statement returns null instead of 64 random bytes:
select DBMS_CRYPTO.RANDOMBYTES(64) from dual;
What is causing it to return null? Database is Oracle 10.1.0.2.0 running on Windows Server 2003 and I want to use the random bytes as salt for password hashing.
Edit: Here's the output from sqlplus:
Connected to:
Oracle Database 10g Release 10.1.0.2.0 - Production
SQL> select DBMS_CRYPTO.RANDOMBYTES(64) from dual;
DBMS_CRYPTO.RANDOMBYTES(64)
--------------------------------------------------------------------------------
SQL>
Edit2: When switching to Oracle 11 the query works. I have no idea why it doesn't work on Oracle 10 but have decided to not use that old database.
It works perfectly. I have tested it on Oracle 12c.
Update
I have checked My Oracle Support(Metalink), however, did not find anything related to this function returning NULL. Certainly, not a bug.
Anyway, looking deeper into the function and it's usage in the documentation, I came across SQLNET.CRYPTO_SEED
SQLNET.CRYPTO_SEED
Purpose
Use the parameter SQLNET.CRYPTO_SEED to specify the characters used
when generating cryptographic keys. The more random the characters
are, the stronger the keys are. The string should be 10-70 random
characters. This optional parameter is required for when encryption or
checksumming are turned on. Encryption is turned on if the
SQLNET.ENCRYPTION_CLIENT parameter is specified for the client and the
SQLNET.ENCRYPTION_SERVER parameter is specified for the database
server; checksumming is turned on if the SQLNET.CRYPTO_CHECKSUM_CLIENT
parameter is specified for the client and the
SQLNET.CRYPTO_CHECKSUM_SERVER parameter is specified for the database
server.
It might be possible that the parameter is not properly set in your environment. I don't have 10g version(obsolete though) to test.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing option
SQL> select DBMS_CRYPTO.RANDOMBYTES(64) from dual;
DBMS_CRYPTO.RANDOMBYTES(64)
--------------------------------------------------------------------------------
427AECD44D27CDF6CDC8F290D9F8079109BAB8AECD7E687E7ADF8E15825BBDF3D746FBC181059443
965B1425B224CC46E8CD07CC2D02B2E023238E8883520A19
SQL>
Is there a way for a normal user (client-side) without elevated privileges (no special database permissions, local administrator, or any of the sort) on the server to get any kind of unique ID from a server (MAC address, database installation ID, server hardware ID) or anything of the kind?
Basically I am looking for an ID to verify the installation. I know I can do it by writing some sort of ID into registry and the database to install server-side, but is there a way to do it without installing anything? The minimum requirements for that is that I get that from MySQL and SQL Server with Linux and Windows.
My current research suggests that there is no such thing. As seen in the comment below:
I think any answer is going to require xp_cmdshell since unique
hardware information is not exposed directly to SQL Server
I dont think you can get hardware details directly from Sql-Server . it may possible throw the other programs which can contribute with both sql-server and your system hardware .
there is a pre-define function in sql server which will give you unique and random id .
create table TableName
(
id varchar(max) default newid()
)
Best I can find is that you can use file_guid from sys.database_files. You only need to be in the public role to do that and that should be unique per DB. If you create or remove database files, you'll run into trouble, and it doesn't do anything about verifying that you're on the same server.
Note that if your DB was created prior to SQL Server 2005, this value will be null since it didn't exist.
I am having a asp.net web application in which I am connecting to a Oracle DB using oracle.DataAccess component. My DBA created a new account and when I try to login with that account in toad, it simply worked fine but when I am passing the values in connection string in SERVER A it is giving me invalid username/password. I double checked the credentials and they are correct. Then I copied the entire website into a new SERVER B and when i tried, I am able to login to the oracle DB. I am very much confused about whats happening. Any Ideas? Is it possible to enable any trace on my servers?
Which version (Oracle DB and Oracle.DataAccess) do you use?
In Oracle 11 passwords are case-sensitive (by default), in prior version it was not. Thus Oracle.DataAccess version earlier than 11 may have problems dealing properly with case sensitive passwords.