kpdyer

4 ms·

1. 1.▲
   by kpdyer 10y ago

   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.
2. 2.▲
   by kpdyer 10y ago

   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 cla
3. 3.▲
   by kpdyer 10y ago

   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
4. 4.▲
   by kpdyer 10y ago

   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
5. 5.▲
   by kpdyer 10y ago

   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 connection
6. 6.▲
   Encryption vs. Censorship, Round 2 – Tom Shrimpton – TEDxMtHood(youtube.com)

   1 points by kpdyer 11y ago|0 comments