Hi there stack exchange,
We're seeing numerous issues in our environment of misconfigured systems repeatedly trying old passwords and causing the accounts to be locked out.
I can see no value in locking out accounts where the same password is tried multiple times, this does not get a (potential) attacker any closer to guessing the password as far as I can work out? I would like to know if there is a way to securely configure a system to count the number of distinct/unique password attempts per user, rather than just the number of attempts before lockout occurs?
I can appriciate that recording password attempts using a reversable derivitive might be bad for security, but surely there's a way to distinguish if the same password is attempted multiple times? Recording recent attempts in a long hash or something?
At the very least is it possible for a system to know that the immediately previous password has been attempted, or even a few back, and not count those as failed attempts? I have seen this implemented and it would seem simmilar to the need to judge uniqueness/distinction?
If the only purpose of a lockout policy is to prevent online brute force password guessing, rather than as a tool to DoS accounts, why is incrementing failed logon counters after only distinct password attempts uncommon?
Lots of question marks sorry, but for clarity the main question is again;
I would like to know if there is a way to securely configure a system to count the number of distinct/unique password attempts per user, rather than just the number of attempts before lockout occurs?
Thanks for any thoughts!
Kind regards,
Xeotech
Related
I need to implement a lock and unlock mechanism in opendj 2.6 based on a fixed failed login attempt. I've already seen that there are two methods (https://backstage.forgerock.com/docs/opendj/2.6/admin-guide/#chap-account-lockout). a manual method (which I don't care about at all because I've already done some testing and found that it only allows manual locking and unlocking) and the second one which was perfect for me because, by modifying the password policy, it allows me to set a fixed number of failed attempts and set a lockout time out.
my goal: I need to find a way to unlock this type of locked users without spending the entire lockout time.
my problem: i have already read the documentation and apparently resetting the user's password is the only way.
ps: I also noticed that, when a user is locked, some attributes are added to his entry, such as: pwdAccountLockedTime and I thought I could delete this attribute manually, but that field was a non-editable field (and also I had no certainty that it would work).
Do you have any suggestions? Or is it simply not allowed?
As you have already identified, the proper way to unlock an account after N consecutive failures is to reset the password. If a user is entering a wrong password 5 times, do you think he will know the correct one the 6th time ?
Otherwise, OpenDJ has a tool called manage-account, where specific operations are possible. This should only be used by an admin with care.
I believe not all operations are documented, but you may read the code to understand them all.
I need to do some security validation on my program, and one of the things I need to answer, related to authentication is" Verify that all authentication decisions are logged, including linear back offs and soft-locks."
Does anyone knows what linear back off and soft-locks mean?
Thank you in advance,
Thais.
I am doing my research on OWASP ASVS. Actually Linear Back-of and soft-lock are authentication controls that are used to prevent brute force attacks and also can help against DoS.
Linear Back-of can be implemented through some algorithm by blocking user/IP for a particular time and after every failed login attempt that time is increase exponentially e.g. for first failed login block for 5 minute, for second failed login block for 25 minute for 3rd 125 min and so on.
As per my understanding as I have seen in some articles and implemented in some application like Oracle WebLogic Soft lock is much easier to implement, IP Address (Which is I think is also helpful to protect against DoS and Brute force using automated tools) or user name is logged in database for every failed login attempt and when a certain threshold number of failed login attempts (e.g. 5) block IP address permanently. Once the account has been soft locked in application runtime, it does not try to validate the account credentials against the backend system, thus preventing it from being permanently locked.
ASVS Verification requirement is very much clear on this though.
"Verify that a resource governor is in place to protect against vertical (a single account tested against all possible passwords) and horizontal brute forcing (all accounts tested with the same password e.g. “Password1”). A correct credential entry should incur no delay. For example, if an attacker tries to brute force all accounts with the single password “Password1”, each incorrect attempt incurs a linear back off (say 5, 25, 125, 625 seconds) with a soft lock of say 15 minutes for that IP address before being allowed to proceed. A similar control should also be in place to protect each account, with a linear back off configurable with a soft lock against the user account of say 15 minutes before being allowed to try again, regardless of source IP address. Both these governor mechanisms should be active simultaneously to protect against diagonal and distributed attacks."
It seems to be common practice to lock user accounts after enough failed attempts in a particular time window.
I am wondering how you prevent denial-of-service attacks since a malicious user who had the username of someone he wished to DoS could simply rapidly make logon attempts.
Is the remedy to lock the account for only the IP address of the user who exceeded the logon attempt count+window ?
Is there any better way?
EDIT:
I don't want to make my users solve a captcha on each login attempt.
You shouldn't block the user by its IP, because maybe it is a real user that forgot his pass and did the retries manually.
The worst thing (business-wise) is that a real user will not be able to access your service.
So, your problem is actually "How do I know that the user is not a robot?".
One of the most popular ways to deal with this is to use a different mechanism for multiple login attempts.
For instance, Google uses Captcha after about 3 trials,
so an automatic bot will get stuck on this stage.
Of course it is possible to get the bot to read the captcha, but it's a start.
You can read more about captcha implementation in their official site: http://www.captcha.net/
Other alternative ideas here: http://econsultancy.com/il/blog/63144-six-alternatives-to-using-the-dreaded-captcha-images
My co-workers are using a commercial program that encodes and stores login passwords on some database.
Now, I'm developing another program to achieve some other tasks, but I want my co-workers to authenticate to this program with their same username and passwords to avoid confusion.
The problem is, I don't have (and probably never will) any source code to determine which encryption algorithm they've used.
I ran some tests and observed that same passwords always produces same hashcodes with 24 characters in length. For example;
1 XeVTgalUq/gJxHtsMjMH5Q==
123456 0Q8UhOcqClGBxpqzooeFXQ==
Is there any way to determine which algorithm they've used ?
Thanks in advance,
Nope. That is the point of encryption / hashing-- it is supposed to be opaque so that it should not be easy to reverse engineer. The only thing you can do is try a few well-known hash algorithms like SHA-1 and see if the hash values match the other program. But, there's no way to know if the other program added in any "salt" or is hashing together multiple things, e.g. username + password or some other scheme. So you are probably out of luck on that front.
One idea you could try with your new program: if the user has never logged in before, allow them to log in the first time with ANY password. Tell the users that they should use the same password they did with the other program. Then, when they log in, capture that value and hash it using your own hashing scheme, then store that for future logins. So ultimately you would get the result you're aiming for (that users can use their same passwords), without having to reverse engineer the encryption scheme of the other program.
Now, clearly the drawback with this approach is that it is not secure at all for the first login. Someone could hijack another user's account if they logged in as that user before the real user had a chance to log in for the first time (and thereby lock in his password). So this is only an option if there is no sensitive data pre-loaded in the new program that could be compromised. Also you would need the ability for an administrator to reset a users' password so that if this kind of thing did happen, you could correct it easily when the real user reports that they can't log in.
I'm about to implement an RESTful API to our website (based on WCF data services, but that probably does not matter).
All data offered via this API belongs to certain users of my server, so I need to make sure only those users have access to my resources. For this reason, all requests have to be performed with a login/password combination as part of the request.
What's the recommended approach for preventing brute force attacks in this scenario?
I was thinking of logging failed requests denied due to wrong credentials and ignoring requests originating from the same IP after a certain threshold of failed requests has been exceeded. Is this the standard approach, or am I a missing something important?
IP-based blocking on its own is risky due to the number of NAT gateways out there.
You might slow down (tar pit) a client if it makes too many requests quickly; that is, deliberately insert a delay of a couple of seconds before responding. Humans are unlikely to complain, but you've slowed down the bots.
I would use the same approach as I would with a web site. Keep track of the number of failed login attempts within a certain window -- say allow 3 (or 5 or 15) within some reasonable span, say 15 minutes. If the threshold is exceeded lock the account out and mark the time that the lock out occurred. You might log this event as well. After another suitable period has passed, say an hour, unlock the account (on the next login attempt). Successful logins reset the counters and last lockout time. Note that you never actually attempt a login on a locked out account, you simply return login failed.
This will effectively rate-limit any brute force attack, rendering an attack against a reasonable password very unlikely to succeed. An attacker, using my numbers above would only be able to try 3 (or 5 or 15) times per 1.25hrs. Using your logs you could detect when such an attack were possibly occurring simply by looking for multiple lockouts from the same account on the same day. Since your service is intended to be used by programs, once the program accessing the service has its credentials set properly, it will never experience a login failure unless there is an attack in progress. This would be another indication that an attack might be occurring. Once you know an attack is in process, then you can take further measures to limit access to the offending IPs or involve authorities, if appropriate, and get the attack stopped.