Security improvement for brute-force collection
BrunoBernardino opened this issue · 7 comments
We should make a change in all back-end packages:
Add a random length of garbage information (just 1-50 bytes, for example) to any image when showing it, so the image sizes/hashes would never be the same if someone tries to download and create a database of image -> checksum.
I fear that simple change in signature is not enough for a brute force counter-measure. The content of the image can be quite easily compared visually using a tool like http://phash.org/ against a predefined set of images. Then the difference in file checksum won't have any effect.
Note that even with just guessing, one in five attempts will succeed (or worse #17).
Having a single image where the images are randomly placed already makes it more difficult, storing the correct coordinates in the session. Adding a non-white background might make it secure enough. At least to keep out casual hackers.
Click on the printer
I like this concept. Delivering one single generated image instead. It will increase the server processing and requirements, but should not be a big deal. As for accessibility concerns (for color-blind), the accessibility option should be a good alternative.
Maybe the front-end can set the image size and number of images to deliver, and the server will have a reasonable limit for both options (as per #17).
Sounds good?
After some deliberation, I've went with the simpler option to increase the file size randomly, in order to not cripple the UX.
The main goal of visualCaptcha is to be extremely user-friendly and accessible, even if that means not being the most secure option out there. There's a very good one for that already (reCaptcha).
@BrunoBernardino You should add some image corruption to make it harder for hackers to crack, for example adding random colored dots to the image and changing the color of the image. That would make it significantly more secure.
@CrazyPython Thank you for your suggestion. That's been discussed before and discarded in the comment above.