This looks very interesting on a technical level, but I'm not sure it really solves the problem of people using bad passwords, and it has some serious usability problems.

As far as I can see, this method is likely good enough to help in cases where people choose short but otherwise good passwords, but not in cases where people just plain choose bad passwords. Computers are getting increasingly good at solving captchas, and you can get human-solved captchas done very cheaply [1]. When the most common passwords are in use by more than 1% of your users [2], just trying those and using a combination of heuristics and cheap human labor still gets you a pretty large number of compromised accounts.

Even in the cases where it works, though, it comes at the cost of a really awful usability problem: users need to read and retype a long random string from the captcha every time they log in, and people hate catpchas. That alone is likely to prevent this being used in any application that depends on getting traction with a large number of users. Slow hashing algorithms like bcrypt or scrypt do a good enough job of protecting short-but-good passwords for most purposes.

The only cases where I can see this being actually used are in applications with very high security requirements, where people have no choice about whether to use the application, and where there are mechanisms in place preventing very bad passwords from being used. However, high-security applications are likely to have much lower traffic, which means that setting a very high bcrypt or scrypt work factor will accomplish much the same thing. That might take a bit more computational power for the application server, but if the traffic isn't very high, that cost isn't likely to be an insurmountable obstacle, and then you get to avoid all of the usability headaches that complicated captchas come with.

[1] http://motherjones.com/kevin-drum/2010/08/price-captcha

[2] http://blogs.wsj.com/digits/2010/12/13/the-top-50-gawker-med...

Summary:

1) People dont like remembering long complex passwords so they end up using short easily brute force-able passwords.

2) So, break up a complex password giving the user something short and easy to remember and store the remaining complex part of the password in an encoded image that when decoded reads like a captcha image.

3) The "profit" here is that despite the user still using small simple passwords, in order to brute force the system you need to rely on artificial vision to read the noisy image for the second half of the password. Which is slow and inaccurate.

The idea is simply adding more computational time to the brute force method. Ie, it's more of a setback than a solution.

Unfortunately/fortunately technology is moving along too fast for this setback to provide significant benefit to justify the efforts to implement it.

not surprisingly, SHA2 for example is something like 7th (if i remember correctly) degree linear system in its core with 2 highly-non-linear (and non-continous, bitshift type) components added to 7th and 4th degrees i.e. something like this:

X(n+1) = I X(n) + Y(n)

where "I" is a shifted diagonal identity matrix and Y(n) is vector with 7th and 4th components being non-zero.

As one'd expect and require for a good hash function - such dynamic system is highly chaotic.

Regarding embedding hidden words in these binary images, I'm sometimes alarmed that people seem unaware of how well computer vision can work in restricted scenarios like this. After all, we've had realtime face detectors in cheap cameras for awhile now. It's one thing to prevent spam with captchas but another to protect sensitive information with them.

Not related to the paper, but interesting nonetheless. ReCaptcha only checks 1 of the words; the other is used to help transcribe old writings. As long as the $control is correct, it doesn't matter what you put as the second word.

Is the idea just to make brute forcing slower, or am I missing something? Because bcrypt and the others already do that and they don't make the user read a captcha.