4 ms·
I imagine that this limitation is fairly common, although it probably wouldn't cost them any more to move to truncating at 512 characters or something like that
by snazz 7y ago
I imagine that this limitation is fairly common, although it probably wouldn't cost them any more to move to truncating at 512 characters or something like that. There has to be a limitation at some point to prevent denial of service attacks caused by hashing super long passwords. Maybe 32 characters seemed like a reasonable choice when they set the system up. I'm guessing that a large number of rounds of a secure hash function on 32 chars is more secure than a smaller number of rounds on 64 chars (given that most passwords are well under 32 characters long).
- londons_explore 7y ago> I'm guessing that a large number of rounds of a secure hash function on 32 chars is more secure than a smaller number of rounds on 64 chars (given that most passwords are well under 32 characters long). The number of rounds increases brute-force complexity linearly. Adding more characters increases complexity exponentially. Exponential is exponentially better than linear...
- snazz 7y agoBut if the average password length is 12 characters, does the maximum password length make any difference for the average user? More characters would certainly be better for those users who generate super long passwords, but for the service as a whole I would think that setting a lower maximum and more rounds would be better. Did I misunderstand something?
- deleted 7y ago[deleted]