kpdyer

That's a good idea but it doesn't work for other common typos: wrong case of only the first character, an extraneous character at the end of the password, etc.

A few other cases: transcription errors (i.e., mistaking 1 for l), wrong case of the first character of the password, extraneous character at the end of a password, etc.

The paper I linked to actually does a good job motivating specific classes of typos by looking at real typos from Dropbox users.

Actually, I don't think there's a need to store multiple hashes.

Here's one idea: Let's say the user's password is P. The user enters some password P' with a typo. The authentication check is "does H(T_k(P')) == H(P)" for some set of transformations {T_1, T_2, ..., T_n}. Each transformation T_i hypothesizes that the user made a specific mistake. (e.g., T_1 is the caps lock is on so we need to flip the case of all the characters)

I agree that password-typo tolerance may seem like a horrible idea on the surface. The "str to lower" approach is an especially aggressive way to increase usability.

However, there's recent work [0] from Cornell that explores the security-usability tradeoff when correcting password typos. It turns out that accepting specific classes of typos (e.g., caps lock on: if password is "Password" then allow "pASSWORD") can increase usability with minimal security impact.

[0] https://www.cs.cornell.edu/~rahul/projects/pwtypos.html

fteproxy [1] can superficially mask the protocol that you're using (e.g., makes Tor look like HTTP) using regular expressions.

marionette [2] enables control over what protocol it looks like you're using and duration of connections generated, amount of data sent per connection, etc.

[1] https://fteproxy.org/ [2] https://github.com/marionette-tg/marionette