- May 24, 2018
The main issue I have with all these ideas is that they require additions to the protocol that need to be reflected both on the server & in the client. At present we do not know what the support requirements are for server instances or if such a DOS is possible, that I'm sure will come. Also I'm not against proposals for future versions supporting this though I believe there are lower hanging fruit, the support of TLS channel binding for example.I will trow a really bad idea now =)
Is the site under attack? Are "they" creating accounts like there is no tomorrow?
Make the client produce a random RSA key with a random value between 4000 and 6000 bit, create the cert with a personalized "CN" and "serial number" value, and send back a value sign with that key using Skein1024.
If still not enough make them produce a random RSA key between 10,000 and 11,000 bit.
I think that common Internet Of Things crap with malware on bot networks will go out of the window immediately with such a requirement especially with the 10,000 to 11,000 bit RSA key one... they may even crash or something =)
That said I think there may be one or two ways that are within protocol to mitigate against a potential bulk sign up DOS, i.e.
If on server side the SQRL service believes there is reason to believe an authentication DOS is in progress (need to define dynamic heuristics for this), it can:-
- Decide to limit use of the API on an N uses per IP per minute
- Returning the ASK verb to 2nd loop queries with a non-guessable question & random answer position thus adding a CAPTCHA to complete use of the API
1/ This is good against all query verb types but in light of carrier NAT needs to be done carefully & verb targeted so as not penalise fair use & foul equality
2/ This is most useful targeted at the specific protocol function being abused as a method to slow it down to what can be done by human responders, even those indirectly performing the task as a porn CAPTCHA (we have seen this on Yahoo sign-ups)