we have oracle set up to lock a user after 3 failed login attempts. however, when we change a password, we have some systems that will continue to use the old password for a few seconds. This is causing these accounts to get locked.
The purpose of locking an account is to prevent people from brute forcing a password.. but if systems just try the same password over and over, that's not really the point of locking the account. is there any way to allow the same password to be tried repetitively, but lock the account after 3 different passwords are tried?
I don't believe there's any simple syntax for this.
Looking here you can probably develop a DDL trigger fired after an ALTER USER command that determines, from expiry_date on DBA_USERS, whether the password has just been changed. In that situation, it can change the profile to a less restrictive FAILED_LOGIN_ATTEMPTS. Then you'd have a batch job that picks up accounts with that profile after an hour or two, and sets it back to the standard profile.
Related
My company has a database for vehicle tracking system. And It has a website for user to log on and use.
After I change the sys and the main user password through "ALTER USER --- identified by' command. The website login became dysfunctional. Our DBA just quit so I have no idea how to troubleshoot.
Is there any guideline I can use?
It appears as though the application has the passwords either hardcoded or in a configuration file somewhere. If you can find where that is, then simply changing the corresponding values (ie passwords) should resolve the problem. If that doesn't work, you can try to change the password back to the what they were before using the same syntax you used to make the initial change ... "ALTER USER --- identified by ...
Can possibly be more help if you can tell what web server is hosting your site.
I have an application storing it's data in an Oracle 11g Express Edition database. When the Oracle user password is starting to expire (entering grace period), the application is throwing an exception (ORA-28002) and just stops working. I need to find a way to keep the application running during that period and inform an administrator, so the password can be changed before it expires.
However my real problem is, I need to set my database user in that grace period so I can program and test my application and see if my code works. I tried to change the expiry date in dba_users, but I do not have the required privileges to do so. I'm not even sure this is the correct approach.
What could I do to make the database server think my user account will expire soon so I can write code to handle that event?
You'll need privileges to do so at the database level. A normal user cannot even explicitly lock or expire his own account. (You can lock it by purposely using the wrong password if your profile is setup so)
The only other way I know to expire your user (without a database level command) is to fool the database by setting the clock forward.
If you don't have DBA privs, it is unlikely that you have privs to change the system clock.
I tried to change the expiry date in dba_users, but I do not have the
required privileges to do so. I'm not even sure this is the correct
approach.
No, don't make changes to DBA_USERS. You would need to alter the PASSWORD_GRACE_TIME for the DEFAULT profile using "ALTER PROFILE" command. All associated changes require ALTER PROFILE system priv to do so. So, without DBA privs, you can't do it.
Look in USER_USERS
It will give you the logged in user's own expiry date so that your application can warn the user ahead of the account expiring.
Solved:
Somehow my database admin changed the user profile from DEFAULT to EXPIREPROFILE. Then I modified the password life time and grace period of the profile:
ALTER PROFILE EXPIREPROFILE LIMIT PASSWORD_LIFE_TIME 1;
ALTER PROFILE EXPIREPROFILE LIMIT PASSWORD_GRACE_TIME 21;
I expired the account and changed the password. When I looked into dba_users the password expiry date was tomorrow. But after that the account didn't expire right away, it entered the 21 days grace period.
Now I can write code to handle this specific situation and test it. Thanks everyone for your help :)
From time to time, Oracle is changing the password for my account. My project has one database pooling for each 60 seconds and another for each 600 seconds.
I don't believe this is the cause, but it abruptlies changes the password causing my code to try to login with wrong username or password that leads to an account lock.
The password is always the same and there's no way the program is trying to connect with a different username/password than the valid ones.
ORA-28000 is not a password change, it is an account lock either by the DBA or because the wrong password has been entered more than FAILED_LOGIN_ATTEMPTS times.
I have to wonder if there isn't one chunck of code somewhere that has a hardcoded, incorrect password that is being run. That or you just get too many people mis-typeing a password in a given time span.
If you want to track failed logins to try and identify what is causing this, check this link: http://www.dba-oracle.com/t_tracking_counting_failed_logon_signon_attempts.htm
Note that, from ORacle 10.2 on, the default for FAILED_LOGIN_ATTEMPTS in profiles is 10, not the unlimited that it used to be. for the default profile, check it with:
SELECT *
FROM DBA_PROFILES
WHERE profile = 'DEFAULT' AND resource_name = 'FAILED_LOGIN_ATTEMPTS';
Bet you get 10 back, and that this is the issue. You can update to a higher value, or backl to unlimited e.g.
ALTER PROFILE default LIMIT failed_login_attempts UNLIMITED;
(I think that is the right syntax - I'm away from my DB at the moment)
Well, it turns out that it was a configuration in the company lib that I was not aware of... sorry for all the mess....
Does anybody knows how could I make a trigger or anything else to prevent people to connect on my database with any kind of applications besides mine?
Note that the super-old-and-unsecure trigger to block few .exe such TOAD or watever does NOT really works, since you can just rename the EXE to MyApplication.exe.
Hints?
An easier method would be to move the security to a role that can be enabled only by your application - see a previous answer of mine here
WIth this method another application may create a session but has no other privileges since the role is not enabled.
You may wish to consider Oracle's Secure Application Roles -- it won't prevent people from logging into the database through a rogue application, but it can prevent them from accessing tables and packages if the application doesn't set the role using the password that only it knows.
You can find an tutorial on deploying it here, although to secure it, you'd have to create the role with a password, and your application would have to know the password when issuing the SET ROLE rolename IDENTIFIED BY rolepassword; statement.
I don't know that Oracle has any functionality to help with this (I could be wrong though) so the next best thing might be to write a small server app that lets you have much better control over the login process and acts as the middle-man between the client apps and the database server. That way, all connections to the database come through your server app, and you can control how your server identifies which client app is legit. This will add a bit of complexity to the system though.
If you don't trust the program name in v$session then the only options that come to mind are to have your application encode the password, so that what they type in isn't actually what's used to connect to the DB; or have your app log in with a private username/password and authenticate users against your own users table instead of having Oracle user accounts for them. Both options make management of accounts more complicated though.
When your application logs on, you call a stored procedure that associates the current oracle session as a "trusted" session. Do this by creating a trusted sessions table with a field for sessionID and trusted bit (and optionally a random hash to prevent user tampering).
Create a system wide trigger, that checks the your current session id (and random hash) to detect if it is trusted. If the session doesn't exist in the table, you don't allow the query, and log off the user.
You should also setup a shutdown trigger to clear the trusted session table on exit.
We want to allow DB access (Oracle) to our users only through our own application - let's call it "ourTool.exe", installed locally on the users computers. Currently, the users must provide username/password whenever they start "ourTool". The provided password password gets decrypted and we use username/decrypted-password to finally log in to the Oracle DB. This approach prevents the users from directly accessing our DB using third party tools (SQLplus, Excel, Access, ...) and everything in the DB is guaranteed to have been entered/edited using "ourTool".
Now, one of our clients wants to allow its users "single sign-on" (with SmartCards/Oracle PKI). With this, the user will be able connect to our DB without providing any password every time they start "ourTool". But the same will be true for the potentially dangerous tools like SQLplus, Excel, Access, etc.
Is there a way to prevent this? How can we make sure that every record in our DB is only created/edited/deleted using "ourTool" in this scenario?
Since it's your application and you have control of the source, you can use either password protected database roles or Secure Application Roles that are enabled from ourTool.exe. (see http://www.oracle.com/technology/obe/obe10gdb/security/approles/approles.htm ).
For example, with a password-protected database role, the initial connection would be with only the CREATE SESSION privilege, and then ourTool.exe would issue the SET ROLE with password known only to you. Any other application doesn't have the information to set the role. Obviously, the privileges are granted only to the role and not directly to the user in this configuration.
By default, OCI transmits the calling application EXE name and you can access it by querying v$session:
SELECT program
FROM V$SESSION
, which you can do in an AFTER LOGON trigger.
But this can be easily overriden and should not be relied upon.
I renamed my sqlplus.exe to myTool.exe and after making a connection with myTool.exe
SELECT program
FROM V$SESSION
where username = 'SYSTEM';
Returns:
myTool.exe
So be aware, as Quassnoi said: although usable in some circumstances it's certainly not bullit proof.