Tag Info

New answers tagged

1

It is not currently possible to bruteforce an SSH connection using only keys-based authentication. A VPN on top of an SSH connection does not therefore add substantial security. It would be better to concentrate on reducing the collateral effects of bruteforce attacks on your SSH connection (DoS and logs trashing would be the top ones), which is described ...


1

SSH and VPN provides basically the same encryption mechanisms. Let’s imagine they both provide the same security, and you configured them well. If an attacker is able to decrypt your VPN communication in a reasonable time, it probably means that he can do the same thing for SSH in roughly the same time. So, you did doubled your defence, but at a relatively ...


1

The calculation is simple. First, figure out how many "tries" a computer can do per second, minute, or hour, etc. Obviously it depends on the computers. For example, let's say 1000 calculations per second. So time in seconds = 2^1000 / 1000 = 1.071509e+298 Then you can convert in minutes by dividing that number by 60, and so on. The formula is: timeInUnit ...


0

I don't think there is any general metric/rule of thumb that can be applied as the time to brute force is completely dependent on the nature of data being brute forced and the power of the system it is being done on. Without being able to give values to those two variables there is no way you can estimate how long it will take. What you can do calculate a ...


1

Short answer to your question is yes, Hydra and Crunch can be used in combination. Your statement that "bruteforcing is generating every possible combination in order to guess..." is correct but the term "bruteforcing" is often used in relation to guessing based on a wordlist, so we just have to deal with the impercise term. On to your goal of recovering ...


0

While extending the character set used in your password makes it stronger, it also makes it hard to type and doesn't provide 100% garantee against attacks. More importantly, using rare characters exposes you to situations where you know the password but cannot use it. Imagine not being able to use a recovery tool because it is not compatible with your ...


0

Your solution will depend on how variable the places the authorization system (AD, ldap, ...) is accessed from are. Is the application you mention the only one to use the authentication service? If yes: the throttling will work fine.You may have users which are surprised by the slowness of the application (as perceived by them) but this may not matter ...


-1

Yes. It is VERY crucial. A program called Crunch generates wordlists for you. Ranges like 1-17 characters will take up 15610 petabytes! However, if a hacker know your password is exactly 17 characters, it will take a lot less. That is why it is crucial.


0

Anything that reduces the entropy of your password reduces its strength. It might be that even when you disclose the password length, the remaining possible password's pool is still large enough. Regarding a concrete example, the set of all passwords of length 17 is surely strong enough against almost all attacks. Provided you did not reveal other details ...


0

In shorter passwords, no. But if you have long passwords it will.


2

I disagree with the accepted answer. Let's look at 2 scenarios, one is we have 10'000'000 passwords and want to crack as many as possible, the other is one password and we want to crack it. In both scenarios the difference turns out to be significant. As usual, all information can be abused in an attack, even if it doesn't seem so at first sight. Scenario ...


2

In addition to the answers which give a good overview of your question, there is one more thing to take into account: when making your risk assessment you must assume that the attacker knows everything about the methodology you use to build your password. In other words, if your password is composed of four average English words glued together, all ...


0

I can suggest you to update your version wordpress, update your template, your plug-ins and change password of all admin. Another thing, you can install plug-ins 'WordPress Security', Wordfence (prevente you and banned the ip of attackers after 1-3 false password and bruteforcing session).


-1

With or without bruteforcing, When you logIn in the account in 5x tentatives with false password, the account Will blocked by WAF (Web Application Firewall) Google Security. So if you change your IP or not, is the owner account only can re-activate it.


1

An attacker will not use a brute force attack, trying every possible password, but try more likely passwords first. A totally random eight letter password may be harder to crack than a simple-to-guess seventeen letter password. As a result, the attacker will not try all short passwords first, but will try passwords of various lengths throughout the attack. ...


0

If the security is based only on a belief/assumption that an attacker will not use technique X, this is a pretty security. It should be assumed that an attacker knows it. This is like in the chess, make the strongest move as if your opponent knows your intentions.


5

Revealing the length of the password does influence. If your password is weak (short password), an attacker may focus on cracking it. If the password is strong (long password), an attacker might explore other vectors of attack. So the knowledge of the length of password allows a hacker to choose a better strategy while saving time.


1

Deliberately disclosing the password length, provided you only use very long passwords will, as Steve Sether points out in his answer, make it less likely that hackers will try to guess it. So, you actually enhance security by deliberately leaking that information about your password.


11

Revealing your password length reveals something about the strength of your password. So you're in essence giving someone a hint about how hard it might be to guess. So if your password is very long (17 characters in your example) it's largely useless information. If the password is short, (6 characters), it tells an attacker that you might be worth ...


40

Apart from the maths detailed by @Mike, consider also that the password length leaks all over the place: When it is typed, a sneaky bystander can learn it, either by counting the '*' on the screen, or listening to the keystrokes (in the latter case, he can record the sound with his smartphone and play it as his leisure). In a classic "Web browser" ...


114

Well, let's start with math: If we assume that your password consists of lowers, uppers, and numbers, that's 62 characters to choose from (just to keep the math easy, real passwords use symbols too). A password of length 1 has 62 possibilities, a password of length 2 has 62^2 possibilities, ..., a password of length n has 62^n possibilities. So that means ...


-1

Client side CPU is cheap but you can also use dual encryption on Client side => Bcrypt and on Server eq. hash_pbkdf2. As you know Bcrypt had cost param, normally on server you use 10-12 because is fast if you use more than 14 it take some time. So if many users login into you webiste they can DDOSed you. In my implementation i use also different hash ...


0

The real danger is not structured guessing I think. Guessing takes to long for 30+ passwords or passphrases on average. But on average also implies they might have some luck on day 1, and you don't want your password to be the lucky one. The real danger are existing lists with millions of known passwords. Hashing them one by one and comparing the hash with ...


1

No, a 30+ random character password is safe If your password is 30+ random characters, the number of possible passwords is well beyond 95^30, which is 2.14e59. The Oclhashcrack page gives a sample crack rate for SHA256 of 16,904 Mh/s. So lets assume the "budget equal to the world GDP" would allow for a million of these computers to perform the cracking. ...


7

There are a few reasons to use larger keys. Your quote only mentions brute-force attacks against symmetric keys. If there is a weakness in the algorithm, then there are faster attacks than brute-force. That is a good reason to design algorithms with some safety margin such that it doesn't get broken as soon as somebody finds a little weakness in the ...


3

Key with a strength of 128 bits or higher are currently considered impossible to break. However, that doesn't necessarily mean that the key itself is 128 bit. The key size is related to key strength, but it doesn't even have to be linear with the key strength. Take for instance RSA; you need a 15K bit key to be near 256 bit security. The best way to see how ...


17

Your quote describes symmetric key strength, but your counter examples (1024, 2048 bits) reference keys used for asymmetric cryptography. The number of bits required for strength is different between the two. Your quote is from section 7.1 of Applied Cryptography; if you move ahead to section 7.2, for example, you'll see Schneier's predictions on what ...


2

It's true that attacks other than brute force might be mislabelled brute force, or that the author is talking about brute-forcing against a hashed password hypothetically stolen from Google (you'd very much hope they'd disclose if that happened and force password changes). However, taking the claim at face value, is it true that: For reasons too complex ...


0

I'm not sure how your site is configured - but one thing to double check is that that the names that are posted up along with blog posts are not the same as the posters login id. I'm not sure if it's still possible but at one time it was possible to enumerate users by just ticking through each author: myWordPressSite.com/?author=1 ...


3

There are open source tools such as wpscan, that allow for enumeration of wordpress usernames. To stop it you could try something like this WordPress plugin which claims to be able to stop wpscan's username enumeration


32

For starters, that article misuses terminology. Whatever vulnerability they may be referring to it seems pretty blatant that it is not "brute force" as that would contradict the premise of that very sentence. As another answer suggested it's possible that some form of social engineering was employed, but in this case any rounds of "guessing" left would not ...


4

Above that paragraph it says: It’s possible, too, that my wife’s password was simply “guessed,” though in a different way from what laymen might assume. Guessing less often involves social engineering—trying your birthday or your hometown or your relatives’ names—than “brute-force attacks,” Which is most likely what he was referring to. In ...


2

I'm not sure why it'd be any more difficult to implement than locking the account, or why load balance rs would have any effect. Both approaches require centralized co-ordination about what to do (lock vs delay). I think the main reason is that it's strange behavior, and makes your website look like it's broken (I don't think this is simply patience). ...


4

To turn your attack scenario through 90 degrees; consider the attacker who, instead of using a list of passwords against a single user, instead uses a single password against a list of users. Imagine I (as the attacker) don't care which account I get access to, I simply want access to any account (say, a bank account). Instead of trying to brute force a ...


3

Drawbacks I see from this approach are: More complicated to implement, especially over a scalable platform, cross thread. May not be effective across load balanced servers. Users may need to be patient. For the above reasons it is not widely implemented.


1

By defualt WordPress usernames are not a secret by any means. As the other answers point out there are many ways of finding the usernames either by URL or even inside the content of the page itself (author class names). There are numerous methods of hiding usernames and/or fighting against brute force attacks, but the simple answer to your question is that ...


3

I had the same problem and blocked the requests for the author scanning with the following htaccess: # Stop Author Scanning RewriteCond %{QUERY_STRING} (author=\d+) [NC] RewriteRule .* - [F]


0

i believe there are too many variables here to give a precise answer. it depends on the below, as far as i know: the cracking software and/or the algorithm used the number of cores in the GPU the architecture of the GPU the architecture of the CPU no of bits in the RSA key


0

This question gives a good overview as to why GPUs are good at cracking passwords. Thomas also gives a rough comparison between a (quite old now) GPU and CPU, an the ratio is about 3:1 in favour of the GPU. However, this is of course going to change depending on which CPU and which GPU you are testing. A modern CPU may well be better than an old GPU, for ...


0

Here are two more issues to add to the list: Start a digits auth on your device against your target's phone number. Then shoulder surf your target to get the auth code from their phone's lock screen (use your device to take a picture of the target device if necessary). Enter the code on your device and you are in the target's account. Since it is locked to ...



Top 50 recent answers are included