

A secure CAPTCHA-free login design - est
http://blog.est.im/archives/4431

======
jzs
There is one tiny issue with this approach. Your method forces storage of the
password cleartext on the server which is strongly discouraged.

You should always store the password on the server as a hash of some kind to
protect your users against breaches on your side.

~~~
est
> Your method forces storage of the password cleartext on the server which is
> strongly discouraged.

Actually, no.

There is no removing or replacing of characters. You can restore password back
on server. Then hash, match against hashed password.

~~~
jzs
Yea i just thought about it. As long as you re-arrange before comparing to the
hash.

My mistake.

------
mooism2
And it's inaccessible (like CAPTCHA). And will probably harm usability too.

------
rorrr
This is stupid for a few reasons

1) There are only a few types of questions, a bot can be programmed for all of
them.

2) You don't need to program a bot for all of them. Even if you cover 1%, it's
enough to break through and spam (attempts are cheap).

3) I don't think I've ever seen a captcha on a login box. Most of the time
captchas are used for submitting anonymous (or semi-anonymous) comments, or
verify a human if there are too many actions from one account.

~~~
est
> There are only a few types of questions

Yet the answer is more flexible than traditional CAPTCHA. Remember, you have
to type the correct password to check if CAPTCHA OCR is working

~~~
rorrr
You're comparing a working solution (CAPTCHA) to a non-working solution
(yours).

Flexible or not, it's completely useless.

