Is there an idempotent hash function? -

is there hash function idempotent? know md5 , sha256 not:

$ echo -n "hello world" | md5sum 5eb63bbbe01eeed093cb22bb8f5acdc3  - $ echo -n "5eb63bbbe01eeed093cb22bb8f5acdc3" | md5sum c0b0ef2d0f76f0133b83a9b82c1c7326  -  $ echo -n "hello world" | sha256sum b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9  - $ echo -n "b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9" | sha256sum 049da052634feb56ce6ec0bc648c672011edff1cb272b53113bbc90a8f00249c  - 

is there hash algorithm can this?

$ echo -n "hello world" | idempotentsum abcdef1234567890 $ echo -n "abcdef1234567890" | idempotentsum abcdef1234567890 

if such algorithm exist, useful cryptographically? i.e. reasonable inputs, computationally infeasible guess input known output?

if such algorithm not exist, not exist because nobody has bothered find or mathematical impossibility?

context

i'm working on system user may want save password in password manager. particularly paranoid user may prefer save password in hashed form rather in plain text. i'd user able authenticate hashed password. rather trying authentication twice (once assuming user's password hashed , once assuming not), wondered if there algorithm let me once.

i know there alternative ways of allowing users store authentication tokens rather plain-text passwords. idea popped head, , curious. couldn't find on google or so.

edit: not suggesting allowing user authenticate hashed password means ok server not salt/hash password. server must still salt/hash original password or client-side hashed password.

edit: not suggesting allowing user log in client-side hashed password genuine security improvement. far know possible benefit add if user used password more 1 purpose. in case, if user's hashed password discovered attacker, access service compromised rather services sharing password. however, best practice not use same password multiple services.

if such algorithm exist, useful cryptographically?

well, consider this: hash typically map between 2 sets:

a -> b 

where b set of possible hashes, , set of things hashable.

now, bigger b -- hashes shorter "checksums" can calculated larger streams of data. typically, you'd still want little collisions possible in hash, meaning statistically, elements b should have same number of elements map them, , elements map same element in b should "far away" each other under metric. implies, b tries hard possible whole set of words of constant length. immensely harder find systematic function that, still maps each element b same element in b; "enforce" collision. in general, that's cryptographic weakness, , serious 1 @ that.

now, considering password case: don't see how make sense. it's cryptographically bad idea let user authenticate either his/her hashed password or in plain, because no matter you'd do, you'd give away full information on how forge authentication eavesdroppers.