[handsomeransoms]

Are you generating the User ID with the additional characters and expecting the user to remember/keep track of it? I do think that is very user-friendly, even with the cookie trick you describe.

It seems like you are trying to force your user to remember a salt. Why not just use a proper salt and a strong password hashing function?

Also note that this protection is only useful in the case where an attacker can get a database dump but cannot perform an active attack on the server.

On the other hand, I have seen some sites (gandi.net comes to mind) do something similar to this. Wonder if they have a similar security reasoning?

[MarkMc]

> It seems like you are trying to force your user to remember a salt.

Yes, essentially I'm trying to force the user to remember a client-side 'salt'.

> Why not just use a proper salt and a strong password hashing function?

Because it wouldn't protect against the attack described by userbinator (ie. 'just trying these 20 passwords gives you a ~18% success rate for any username'). Having a client-side 'salt' gives you that protection.

> I do [not] think that is very user-friendly, even with the cookie trick you describe.

Yes, this system imposes a cost in terms of user-friendliness. But for sensitive sites (eg. medical or financial) I think it's worth it.

[kbart]

Sensitive sites should use 2-factor authentication by default as your method won't help against keyloggers and other malware. I don't like 2-factor authentication (it's more time consuming and costly to get a throw away phone number than a new single purpose email address to register to a random site), but this method is even less user friendly as you can't expect an average user to remember a random symbol string in few months. What would really improve security situation is a good, easy to use, cross platform, cross device password manager that would be included in major browsers by default.