Silly question but. If hackers got Adobe ID's and passwords whats to keep them from changing the password ?
They got encrypted passwords, which are useless without decryption.
Specifically, the passwords are stored in a hash. What happens is you select your password and Adobe takes that password, does some math to it, then stores the resulting hash in their database somewhere, rather than storing your actual password. Then, when you enter your password to log in, it does the same math on it, and compares the result to the hash they have stored in the database. If the two hashes are the same, it knows you entered your password and it lets you in. If somebody gets the hash straight off their database, as would seem to be the case here, that doesn't help an attacker know what password to type in when they want to log in with your account, unless they can reverse engineer the hash algorithm. So, it really depends on what kind of hash algorithm they used for their database, as to how secure your password actually is.
Generally, it's a good idea to have everyone change their password anyway, just in case the algorithm eventually proves to be vulnerable to attack, or an attacker is properly motivated and willing to spend enough time to crack your password. Some hashes still in use today are considered vulnerable, though, so attackers may very well already be crunching through the hashes and getting plaintext passwords. One can hope Adobe is using a more secure hash, but plenty of big companies have used insecure algorithms in the past.
Hashes are designed not to be reversible, unlike regular encryption designed for actual decrypting at some point, but if the algorithm is known it's possible to simply use it to hash a bunch of password guesses, and then compare those guesses to the hashed passwords. Just search through the database for hashes you've made yourself, and you know the password for each of the accounts with the same password hash. It's essentially a dictionary attack, but it bypasses whatever system Adobe uses to prevent unlimited repeated invalid password entries (like locking your account after a certain number of attempts, or adding delays to the algorithm/webpage so it would take a prohibitively long time to try every possible password).
One method of preventing lookup table attacks like the above is to add a "salt" to the password before it's hashed so the result in the database isn't something the attacker can generate for a table without knowing the salt. Any old salt won't do, though. It needs to be a cryptographically-secure pseudo-random number, unique to each account, never reused when a user changes their password, and long enough that an attacker can't simply make as many tables as there are possible salts. Bear in the mind, the salt still has to be stored alongside the hash in order to authenticate a user, so an attacker knows the salt to use. But, by using a nice long pseudorandom salt for every individual password, each individual password needs a separate lookup table to brute force. Dictionary attacks are still possible if the hash algorithm and salt method is known, but take incredibly long amounts of time to crack the whole database and incredibly large amounts of storage. Against a single specific user, their password may be discovered, but only that one user, and only if they used a guessable password, and each single specific user will require a separate attack. In other words, they're still doing an ordinary dictionary attack, and the usual rules about making your passwords resistant to dictionary attacks apply. Properly salted passwords hashed with a modern secure algorithm are simply not feasible to extract from a database like this, en masse, but it's still a good idea for everyone to change their passwords. It's also a good idea to change any other passwords you have if you've made the common error of reusing passwords on multiple sites.
