Proposal to address the question raised during Gothenburg, Sweden Meetup about preventing a DDOS from computationally cheap SQRL clients


Status
Not open for further replies.

ramriot

Well-known member
May 24, 2018
127
14
I will trow a really bad idea now =)
Is the site under attack? Are "they" creating accounts like there is no tomorrow?
No problem!
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 =)
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.

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:-

  1. Decide to limit use of the API on an N uses per IP per minute
  2. 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)
 

shanedk

Well-known member
May 20, 2018
408
107
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
That's interesting. Are you thinking of it like one of those text CAPTCHAs? Like, the question would be "What is three times two?" and the buttons would be "Six" and "Five"?
 

ramriot

Well-known member
May 24, 2018
127
14
That's interesting. Are you thinking of it like one of those text CAPTCHAs? Like, the question would be "What is three times two?" and the buttons would be "Six" and "Five"?
That would be one option, I think we can all think of a few other options that can be used randomly.

While I think of it there could even be a config option & a bidirectional API for Abuse Mitigation such that people can write all sorts of heuristics in the same way that things like Postfix has
 
Status
Not open for further replies.