5 ms·
The "unless it's a common word" thing is the problem, really. I tried to do a more Markovian filter at my work and it bombed -- nobody enjoyed trying to get aro
by drostie 14y ago
The "unless it's a common word" thing is the problem, really. I tried to do a more Markovian filter at my work and it bombed -- nobody enjoyed trying to get around its entropy restrictions. All it did was assume that your next letter would be predictably "like" your last one, so "password1" would have just one domain change in it. I didn't even go through, e.g., John the Ripper's dictionary to build an optimized order for going through letters.
- kijin 14y agoBan common words. Ban common words with 1-2 numbers attached to the end. Ban common words with 1-2 letters replaced with similar-looking numbers. But unless your website deals with very sensitive information, I don't think it's an efficient use of resources to try to use a more sophisticated filter. Simply imposing a logarithmic delay between login attempts, and banning IPs / disabling accounts after a certain number of failed attempts, go a long way toward protecting any password that isn't in the top 1000. "password1" is too easy to brute-force. "pAssword072" is not even in the top 10000, and therefore it is already stronger than at least 98.8% of passwords that are out there. The idea is to allow weaker passwords for the sake of convenience, but compensate for their weakness by adding protections in other areas. For example, you might require users with weaker passwords to change their passwords more often, disable their accounts more aggressively when a brute-force attack is suspected, or use more rounds of bcrypt to encrypt their passwords. Some of these measures will be helpful even in the case of a database breach.