Tag Info

New answers tagged

0

it is really not clear to me what is the question but it seems you have a problem with sending and receiving the cookie. But I think you should look at the following python package http://docs.python-requests.org/en/latest/user/quickstart/# http://docs.python-requests.org/en/latest/user/quickstart/#cookies But I think this is really a programming ...


0

Fail2ban is an interesting tool for that. From the official wiki page 1: Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs that show the malicious signs -- too many password failures, seeking for exploits, etc. Generally Fail2Ban is then used to update firewall rules to reject the IP addresses for a specified amount of time, ...


4

One way to mitigate this issue would be to implement egress filtering on your network. For example most web servers should have no requirement to make connections to the SSH ports of arbitrary hosts on the Internet, so if you block this traffic at the firewall your systems become less useful to attackers Also this can help reduce the risk of compromise in ...


5

It would be pretty easy to write a script that will generate every possible key according to those rules and dump them in a .dat file. If you want, I can whip one up for you in python and post it here, but I don't think that would actually solve your problem. Taking a rough squint at the math, you have an alphabet of 37 characters (26 letters + 10 numbers + ...


-1

Look for tool Crunch it is word list generator, then try brutoforce.


0

I think 80 bits is just a reference to the general lower limit of what's considered computationally infeasible to brute force. From wiki: In 2002, distributed.net cracked a 64-bit key in 4 years, 9 months, and 23 days. As of October 12, 2011, distributed.net estimates that cracking a 72-bit key using current hardware will take about 45,579 days ...


1

How are you planning on implementing the lockout? Is is per username or network address. If you consider the first option bear in mind that the attacker can launch a denial of service attack for any number of valid users(he can simply brute force a number of (very likely) invalid passwords for each valid username and thus lock out the respective user). ...


3

As others have mentioned already, currently the recommended way of implementing lockout is to require a Captcha only after a few failed login attempts. This method is good from both a security and usability standpoint - the Captcha is very effective on stopping automated attacks, but only requiring it after a few failed logins makes it so that legitimate ...


0

You're correct, the only way to protect against bruteforce attacks is a lockout. This is always implemented when the password space is very small e.g. for 4-digit PINs in bank cards or phone SIMs. Be careful as option #1 (disallow login after n failed login attempts) can be used as a DoS to lock out a customer. If you want to do this, you should put a ...


4

Part of the problem is that keeping the connection open while you wait for the delay to expire uses precious resources, particularly under certain popular configurations where the number of simultaneous connections allowed is pretty minimal. An ideal solution is to architect your system as follows: Design the logic first into the UI. A failed login ...


1

Online bruteforce attacks Indeed, sites that don't implement some form of protection against online bruteforce attacks are leaking their users' passwords. Many sites don't have any form of protection in place, and many others do. Simple blocking has issues: If we block the user's IP after x failed tries, a 10'000 strong botnet gets to try x* 10'000 ...


3

You want your server to do as little work as possible, to avoid DoSing yourself. Account lockout is great for DoSing your users. if count(unsuccessful authentications for user U) > threshold then demand solved CAPTCHA if count(unsuccessful authentications for password P) > threshold then demand solved CAPTCHA if dislike CAPTCHA then demand Proof of Work ...


28

I assume that your intention with the failure delay is to prevent brute force attacks: if an attacker is trying to guess a user's password, she will first fail many times; if we can make those failures take a substantial amount of time longer, then it will make the attack an order of magnitude harder, and thus unlikely to succeed (in a reasonable time ...


5

A traditional delay would mitigate web browser based attacks, for example if someone uses phantomjs to automate login attempts the normal delay (in your case "more than one second") would be enough to stop anyone from trying to brute force a password, it just takes too long. However, most brute force attacks are not ran in web browsers but in scripted ...


1

There are a number of ways of mitigating brute-force attacks, depending on the level of control and access you have to the systems in question. At a firewall level, you may be able to do rate limiting to throttle the number of connections from a given IP address. Also some firewalls will have Intrusion Prevention System capabilities which could allow for ...


0

Going back to high school probability math, the following should be close. Given amount valid keys in a space of size space, the chance of any random guess being correct is winChance = amount / space. Given a number of guesses (which is easily calculated from rate and time), the chance of finding 0 valid keys is (1-winChance) ^ guesses. That makes the ...


2

For the expected case (average) the number of attempts has a linear relationship to the probability of success being considered. expected_time = probability * keyspace / ( rate * 2) So if the keyspace consisted of 1 billion codes and the attacker could brute force 1 million codes per second to have a 10% chance of success the attacker would need 50 ...


0

Have you considered instrumenting OpenSSH to log password attempts. Its common to log thousands of attempts every day for an internet connected host. That will give you a list of several thousand common passwords that have some track record of success AND hint at users other than root which are common targets (e.g. nagios, db admins etc). Once you have a ...


5

I'd be happy to explain my comments further :-) Unfortunately it's not a simple explanation. For a bcrypt-hashed password, how much of an advantage would this give the attacker? Can this be quantified? Quantifying this will be hard since guessing at the runtime of an algorithm is tough, especially if the attacker is allowed to make specialized chips ...



Top 50 recent answers are included