database Brute-force protection

hi all,

Can DB2 has built in Brute-force protection ? what tools /configuration needs for this.
LVL 1
marrowyungSenior Technical architecture (Data)Asked:
Who is Participating?
 
NerdsOfTechTechnology ScientistCommented:
I tend to look at attack potential from the perspective of a potential attacker. Brute force is attempting to use every permutation of characters. Often times brute force attackers don't start with brute attacks per se; they start with the most common passwords people use (rainbow [table] attack) e.g. password1 ... password123 ... Password123 ... myPassword1... etc, then they move onto word and alphanum combinations (dictionary attack) e.g. GreenApple1 ... Mt.Everest123 ... etc, finally the last resort is brute force where they try 4-15 character combinations in order. 0000 0001 0002 ... ABCx ABCX ABCy ABCY ... ZZZY ZZZz ZZZZ ... etc. The time cost is a mathematical exponent of length, of all characters used in a password.

0-9a-zA-z!@#$%^&*()_+-=/?<>,.:;"'{[}]\|`~

(10[digit]+26[lower-alpha]+26[upper-alpha]+34[normal-special-characters])
or 96 typical characters in a strong password.

96^length

If n=length, the amount of permutations possible is this, when a password that uses only:
digits (such as a PIN): 10^n
lowercase letters: 26^n
digits and lowercase: 36^n
digits and any alpha: 62^n
digits, any alpha, any typical special character: 96^n

So if the password requires a strong password of 8 length and the user uses the minimum the attacker would have to exhaust 96^8 tries:

7,213,895,789,838,336 (7.2 quadrillion tries).

Now if your security allows all 7.2 quadrillion attempts something is wrong. In fact, you should notice when not only when the attacker fails twice or thrice, but when a user does too. There should be a lockout policy in place. At a minimum the next try should be harder (a CAPTCHA test, for instance, on the first lockout, will often times separate brute force BOTS from human users). Some security experts require dual authentication, where the user signs in with a password and a code which is sent to a known device owned by the user (cell phone, etc) or via and authenticator app.

I hope this additional information helps.
0
 
NerdsOfTechTechnology ScientistCommented:
There is no defense to brute force attacks except credential complexity or failed login lockout strategies.

The more complex the user/password is, the more time it will take to break by brute force; retry lockouts delay the attacker further.
0
 
marrowyungSenior Technical architecture (Data)Author Commented:
any more input ?
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

 
marrowyungSenior Technical architecture (Data)Author Commented:
tks for changing it for me.
0
 
AlanConsultantCommented:
Hi marrowyung,

It really depends on the form of the attack.

If the attacker is coming in remotely, or via a running interface, then as mentioned above, a simple control based on a number of failed logins should be sufficient to stop a brute-forece attack.

Often it is set low, but in reality this could be ten or a hundred attempts before being locked out, and even if you only allow upper and lowercase letters, plus numerals, if you have a minimum password length of, say, eight, then the possible combinations are (26+26+10)^8=62^8 which is greater than 10^14 combinations.  Trying 100 and hitting one by accident is highly unlikely (setting aside silly passwords like '12345678').

However, if the attacker can get a copy of the database, and hammer on it statically, then there is no way to limit the number of attempts they can make.  In that scenario, it comes down to how many they can try, and the size of the password 'space'.

I recommend that users do not use less than fifteen character passwords, and encourage at least twenty.  For myself, I always use at least 31 characters (assuming the application will allow it).  Remembering a 31 character password (or phrase) is actually not all that hard, but if people use a password manager, then it is a non-issue, so they can just go to 63 random characters or more.  At those levels, breaking by brute-force is just not mathematically feasible.

So, allow and force long passwords if you can.


Alan.
0
 
marrowyungSenior Technical architecture (Data)Author Commented:
NerdsOfTech,

"There should be a lockout policy in place. "

lock that account if login failed many time policy exists.

"Some security experts require dual authentication, where the user signs in with a password and a code which is sent to a known device owned by the user (cell phone, etc) or via and authenticator app.

yeah. that one is called 2 or n factor authentication.

so this is not on DB side, agree?

Alan,

"Often it is set low, but in reality this could be ten or a hundred attempts before being locked out, and even if you only allow upper and lowercase letters, plus numerals, if you have a minimum password length of, say, eight, then the possible combinations are (26+26+10)^8=62^8 which is greater than 10^14 combinations.  Trying 100 and hitting one by accident is highly unlikely (setting aside silly passwords like '12345678')."

here will lock when 5 login failure is detected, spec in banking environment.

" if people use a password manager, then it is a non-issue, so they can just go to 63 random characters or more."

we use CyberArt here. no fix password.

so you all saying long password and password policy solve the problem.

but I focus on DB side only . so it seems we are takliong about DB password policy but system policy. right?
0
 
NerdsOfTechTechnology ScientistCommented:
Yes, lockout policy, password length, password strength (pool of characters required) are important to fight against brute-force.

Another issue would be common passwords, repeated characters, dictionary words, etc. These are more advanced issues that are commonly solved be issuing passwords.

Issuing passwords can also be a problem as well to those using the passwords: they aren't easily remembered so they have to be stored somewhere (on paper, in a phone, etc.) which can be easily lost or stolen.

Password rotation sparks a similar problem in a way. The user must 'remember' their last password. Writing it down somewhere or storing it somewhere would be common yet would  potentially expose this information.

N factor Authentication seems to be the way to go to avoid some of these advanced issues when possible.

It seems you have many options in DB2 for authentication.

https://www.ibm.com/support/knowledgecenter/en/SSEPGG_9.7.0/com.ibm.db2.luw.admin.sec.doc/com.ibm.db2.luw.admin.sec.doc-gentopic1.html

In my opinion, the more sensitive the information, the stronger the password policy should be. Convenience is also a factor. It's the old convenience versus security battle.

Wouldn't it be terrible if you were forced to have a strong 8-64 character alpha/digit/special-char bank PIN for ATM transactions instead of an easy 4-8 length 0-9 PIN?

Sounds like you have CyberArk Enterprise Password Vault. So rotation and management sounds like it is in place.

I hope some of this information gives some insight.
0
 
marrowyungSenior Technical architecture (Data)Author Commented:
this question is about DB2, so this means we can' only relies on system password policy and n factor authentication to prevent ?
0
 
NerdsOfTechTechnology ScientistCommented:
0
 
NerdsOfTechTechnology ScientistCommented:
You might ask yourself if you are experiencing brute-force attacks or just stolen passwords?

It might be that the passwords are too strong and that passwords are being recorded where they can be compromised...
0
 
marrowyungSenior Technical architecture (Data)Author Commented:
"You might ask yourself if you are experiencing brute-force attacks or just stolen passwords? "

for audit purpose, we need to implement before experiencing it. it will be too late if we don't do it right now.
0
 
marrowyungSenior Technical architecture (Data)Author Commented:
0
 
NerdsOfTechTechnology ScientistCommented:
I believe the Kerberos N factor solution is additional as they are third party.

"Kerberos is a third-party network authentication protocol that employs a system of shared secret keys to securely authenticate a user in an unsecured network environment. The DB2® database system provides support for the Kerberos authentication protocol on AIX®, HP-UX, Solaris, Linux IA32 and AMD64, and Windows operating systems."
0
 
marrowyungSenior Technical architecture (Data)Author Commented:
tks.
0
 
marrowyungSenior Technical architecture (Data)Author Commented:
tks all.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.