In what sort of circumstances would an attacker potentially be able to detect a pattern from a series of hashed passwords?
I think the most direct answer is: When the hashing algorithm is not cryptographically secure. The main four points of cryptographic hash function evaluation are as follows (quoting wikipedia):
- it is easy to compute the hash value for any given message
- it is infeasible to generate a message that has a given hash
- it is infeasible to modify a message without changing the hash
- it is infeasible to find two different messages with the same hash
As Gumbo pointed out, strong hash functions result in wide variation of output for narrow variations of input. This is true for nearly every hash function ever considered secure, even the now discredited MD5 and Sha-1 algorithms. With most hash algorithms, the main attack vector is a collision and a close second is a decryption. I expect in my lifetime that MD5 and Sha-1 will be broken, either through trough decryption or exhaustive lookup tables (for inputs under a certain length). So pattern detection in hashes may receive some further analysis. I expect that the capability to detect the presence of a pattern will arise, but the ability to definitively state what the pattern is will hinge on the ability to retrieve the plain text.
In other words, this is likely:
We can say with 90% confidence that the plaintext of these hashes are a maximum of x-degree difference from each other.
This is extremely unlikely:
Clearly, the user is following a pattern of incrementing the highest bits of their password every week.
Especially considering that all of the attacks on hash functions are actually interested in this:
Oh, the hash is x? y, z, a, b and c plaintexts can all be used for that.
Since you phrase it from the perspective of a hacker obtaining hashes of your password, let me put it to you another way. How much do you trust the security of the entity storing your hashes? Supposing that said entity is storing your previous hashes (which given the requirement to change it every week, I also find it likely that they will enforce a difference or minimum degree of difference which pretty much requires them to store a history), if they are breached such that the complete list of your previous password hashes are taken, it's not that much more unlikely the attacker can compromise the systems in an ongoing way and simply start recording password plaintexts as they come in.
There is a particular situation where you may be at risk in the way you imagine. If you are ever told that your new password is too similar to a previous password, then the authority almost certainly storing a list of information about your previous passwords which is less cryptographically secure. If this list is taken along with the hashes, then you're much more likely in danger of your pattern being found out. Read up on string metrics if you're interested in this - most of those metrics (as solutions for enforce password differences) would certainly require your password to be stored in plaintext.
If you suppose that one of your plaintext passwords is known, that does change the problem by quite a lot. I feel I should emphasize again, however, that this would be really a very outlandish attack on your password. Almost all attacks on hash algorithms remain theoretical. If there were to be a sudden break through in a pattern/similarity attack on hashes, it would certainly make headlines (in certain circles). If we really are talking major research efforts here, and we suppose that a number of your password hashes are known and a plaintext version from your history is also known, the attacker would probably also need to know what hash algorithm is being used and what salts are used for the given passwords.
But, if a plaintext is known, it's far easier attack, in my opinion, to simply compute variations on the plaintext yourself. Given a plaintext, a known algorith and salt values, and just one other hash result, your example pattern could be detected in just 32 attempts
- increment a character
- compute the hash
- not a match? next character
If you complicate the pattern, the amount of attempts required increasing. For example, you have a pattern for choosing which character you increment each time, then for the attack to predict your next password, they must have at least as many hashes for the length of your pattern to repeat. But for most attacks (e.g. drain your bank account, hijack your facebook) only one successful match. This is essentially defining a search space for the number of permutations. So assuming a plaintext is known, and they predict that only one character has change, then only
n * m possibilities exist. So for your example passwords with 32 character length (n) and call it a-zA-Z0-9!-+ 72 possible values, that's only
32 * 72 = 2304 possibilities to search, far less than the 2^20 possibilities in the theoretical lower bound of MD5 algorithm security.
Changing a second character to an arbitrary value (not an incremental value), squares the search space, which gets you back into the range of cryptographic security (2304^2 ~ 2^22). But if they have a history and know you're only changing one character at a time, then it's only 2304 searches for each step in the history (multiplicative, i.e. linear growth of the search space instead of exponential).