First things first: passwords are not (or at least, never should be) encrypted. They are hashed, a one-way transformation that takes an arbitrary input of arbitrary length and produces a constant-length (for any given hash algorithm), deterministic (the same input always produces the same output), and high-entropy (hard to distinguish from random) digest (also simply called a hash). For cryptographically-secure hash functions, there is no way to tell, given a digest, what input string produced it (and of course, there may be an infinite number of possible inputs that would produce it, since there are infinitely many possible inputs but "only" a limited number - such as 2^256, for 256-bit hash functions - possible outputs). In other words, you cannot reverse a hash function. Additionally, any changes to the input of a secure hash function, be they large or just a single bit-flip, generally produce a dramatic change in the digest.
Due to that, the standard attack on password hashing has long been to hash a large set of candidate passwords with the same algorithm, and check if any of the outputs match the digests in the dumped collection. Originally, this could be done with large, pre-computed lookup tables (called "rainbow tables") where a password, if it was present in the rainbow table, could be identified from its hash easily (simply search the table for the same digest). To protect against that, password hashing algorithms began to incorporate a "salt", which is a random string of bytes that are generated uniquely for each user, and are combined with the user's password when hashing. This makes rainbow tables useless unless the attacker already knows the salt of the user they want to crack, and even if they do they can only crack that specific user's password and have to generate an entirely new set of hashes for each other password. It also means to users who use the same password will have different digests, as their salts will be different.
However, even salted passwords can fall prey to a simple brute-force attack, because secure hash functions are generally optimized for performance (many of the places they are used, such as HTTPS traffic, require that they be computationally inexpensive). Chips that are optimized for performing the same operations on many distinct pieces of data in parallel - which is exactly what GPUs (graphics processing units) do - can brute-force an enormous number of hashes in a very short time (high-end GPUs can compute billions of hashes per second, for some of the common hash functions). Very, very few users are going to select a password so rare it's not one of the first few billion attempted, so such an approach can crack most passwords in a few seconds, for the cost of a few hundred dollars of graphics card. To defeat this, people started using slow hash functions for password hashing. The simplest way to make a slow hash is to take a fast hash, feed its output (and the salt) back into itself, and do that a few thousand more times; this is the basis of the PBKDF2 function, and it can slow down password brute-forcing attempts by a few orders of magnitude. Over time, more advanced password hashing algorithms have been developed, which resist not only GPUs but even customized chips (FPGAs or ASICs) designed to do nothing but brute-force passwords as fast as possible. No resistance is perfect, of course - the server still has to be able to hash your password when you log in, which puts a limit on how expensive the hash function can be made - but it can be literally millions of times slower to brute-force passwords protected by a proper password hashing algorithm (such as scrypt or argon2) than by a single-iteration fast hash (such as SHA-256). In other words, trying "the first few billion possible passwords" for each user goes from taking 1 second to taking a few weeks. Getting even a single password becomes expensive; breaking thousands of them becomes nigh-impossible.
Now, to answer your questions:
Is there any defense against this kind of attack?
Aside from what I mentioned above - use salt, use a slow hash function, and make it as expensive as possible to brute-force passwords - there's no way to truly prevent brute-force attacks. However, you can make brute-force attacks take so long to succeed that they are de facto impossible, if you can get your users to use passwords that the brute-forcing tool won't try within a reasonable timeframe. Simple permutations and common substitutions, like "password" to "Pa$sW0Rd", are easy for programs to try and therefore add little security, even though they'll get past the foolish "complexity" requirements many sites have. Using long passwords, generated with an element of genuine randomness, works much better. For example, a passphrase generation algorithm such as Diceware (online generator) can produce passphrases that aren't too hard to remember but are extremely strong. With reasonable length choices and generous estimates of cracking speed and technological progress, Diceware-style passphrases should be safe for at least a few decades (and potentially for centuries) even against an attacker who is doing nothing but try to crack that one passphrase using constantly-improving cutting-edge technology.
Does it help to increase the length of the encrypted keys?
Not really. Leaving aside that they aren't "encrypted" at all, the strength of a password hashing function has very little to do with the length of its digest. Obviously you should not use extremely short digests, because then you have a high risk of collisions (two unrelated passwords that hash to the same thing, and either one would be accepted for that user), but all secure hash algorithms have a digest of at least 128 bits, which is plenty to avoid that particular risk. Longer digests do technically make the comparison step of the brute-forcing attack take longer, but the difference is irrelevant next to the time it takes to compute a slow password hash in the first place.