I wrote about the new defaults in 10gR2 more than 5 years ago
FAILED_LOGIN_ATTEMPTS default to 10 in 10gR2
This new DEFAULT increases the security by preventing the users from trying millions of different passwords. However the locking of application users is noticeably decreasing the database availability 🙁
My recommendation :
– create a separate profile for the application users with high availabilty requirement with a default of 1000
– add 2 characters to the password of those accounts
SQL> create user u identified by a4sec2pw;
User created.
SQL> grant create session to u;
Grant succeeded.
“U” is a critical user in your application where account locking would mean downtime !
Let’s try to make the schema 10 times more secure and 100 times more available :
SQL> create profile failed1000 limit failed_login_attempts 1000;
Profile created.
SQL> alter user u identified by a4sec2pwx1 profile failed1000;
User altered.
OK?
How long would it take for a java routine to make 1000 intentionally failed attempts to log in ? A few minutes ?
If you want to prevent a targeted DoS then you need to leave it unlimited.
But also test what your application does if it hits an invalid password error on connection. Perhaps it retries, either intentionally or because it calls some error logging routine that tries to log the error in a table which needs a db connection…