If this were true, there would be no reason to hash passwords.

There are hashing algorithms (bcrypt, scrypt, PBKDF2) that are specifically designed to be slow to prevent these attacks.

PBKDF2 is not memory hard, so even with known technology it can be broken relatively easy. Bcrypt seems secure for now, but you shouldn't rely on security through obscurity, which is essentially what putting faith in the irreversability of a hash is. The reality is that if a hashed password leaks, you should assume it will be broken. It's like with bank vaults. They're not designed to withstand attack, just to delay it. Well-hashed passwords delay attack, but they do not prevent it.

Hashes are mathematically proven to be irreversible except through rainbow tables (easily beaten with salting) or brute force. There's no faith needed (well, I suppose that non-mathematicians like myself have to put faith in the math, but I trust the hundreds of independent studies of these algorithms quite well), and it's not anything close to "security through obscurity".

That said, you are right. You should always change passwords that are leaked. This, however, is due to the poor security practices of most companies, not some bizarre distrust of hashes.

Brute force was exactly what i was talking about. It doesn't matter whether a hash is broken through a mathematical flaw, or through improvements in the brute forcing process, if in practice it still gets broken. Once a hash is leaked brute force becomes possible in theory, and what is possible in theory is usually possible in practice with sufficient dedication.

There have been such huge improvements in hashing through tools like hashcat and hardware implementations that i don't think it's unreasonable to distrust hashes. Once a hash is leaked you're essentially hoping that brute forcing it is too high of a cost. Given the history of order of agnitude improvements in hashing speed, i consider it unreasonable to believe that any password database remains safe indefinitely once leaked.

I find your trust in the difficulty of brute forcing a hash just as bizarre as you seem to find my distrust of hashes.

IANASE (I am not a security expert): Would the following service work:

Assume a central account/profile service. This service would allow you to have a single login to this service, with a directory of pretty much any/all sites and services online.

The external services would receive a hashed token of your account/authorization. They would check for the validity of the token each [interval|day|time-the-service-was-accessed] to determine if the token/auth is still valid.

They would also be able to tell the central service whether or not they require an updated token/auth, for circumstances just like this.

Further, form data could be stored on the central service, like mailing, shipping, billing, etc info. A log of all sites/accounts that request/require/use this information is kept.

Access to this and all other profile information can be reviewed/revoked by the user at any time.

Groups and layers of account information would be something that could alternately be added to the central service. I.E. - you could have a first level login to get to your dashboard, but additional security could be required to change various portions of your profile details (one passwd for address info, another for accounts)....

Avatar galleries would be available and you could tell each service which avatar to associate with what.

While it would work in the sense that compromising the other systems wouldn't compromise anything else. It does leave that central service as a very very very big and attractive target. It introduces a single point of failure (security wise) that lets someone compromise everyone at everything all at once. It would also make it a good target for warrants and subpoena to be sent to gather information about people without their knowledge (less of an issue, but still a concern for privacy).