Earlier quoted context omitted.
HMAC interferes with my design goal of being simple and easily reproducing SHA1_Pass generated passwords on multiple platforms when needed. SHA1 was a design decision to meet that goal. To carry out your attack, you would have to: 1. Somehow know the user used SHA1_Pass with full encodings and a consistent "sentence followed by salt" scheme. 2. Somehow trick the user to log onto your malicious site using a SHA1_Pass…
> BTW: I think I know you from @misc. If you're talking about misc@openbsd.org, yes.
So for HMAC. I've looked at it more and I think your point is valid (even tho it's not very likely to occur). I may add it as an option. I don't really need to use it in the traditional sense (shared secret, integrity, etc) I only need it to better resist the length-extension attacks you point out.
Can the key and the message be the same? I'd rather not prompt the user for a base sentence and a key/salt. But I can't find anyone using HMAC where the key and the msg are the same. I thought you might have some insight into this.
Edit... here is a traditional HMAC (I think):
echo -n msg | openssl dgst -sha1 -binary -hmac key | openssl enc -base64
Here is how I would need to use it without changing functionality:
echo -n msg | openssl dgst -sha1 -binary -hmac msg | openssl enc -base64
I'm not sure this is proper from a cryptographic perspective.