Views on protecting against throw away identities user registrations

  • New SQRL for .Net Forum
    Guest:

    Just a note that we have a new forum to contain discussions relating to TechLiam's "SQRL for .Net" server-side middleware. You'll find it under "Server-Side Solutions."

    /Steve.

aitorpazos

New member
Feb 19, 2019
3
0
Hi all,

I have a concern and I'd like to see what are the views of the community on it.

I really like the idea of SQRL and that is why I enabled it on my site as soon as I could.

However, to accept new SQRL logins I had to enable users registrations and that opened the door for wordpress user registration bots (using traditional username/password). No big issue I can handle that, but that got me thinking.

If SQRL is successful, how can I protect my site from bad actors generating large volumes of identities that can possibly flood my site. There are some resources usage associated to a user account, so this kind of attacks could be an issue.

I can think on some registration flow similar to the traditional e-mail link confirmation that could prevent the issue with automated registrations. I reckon this is more an implementation detail than an SQRL protocol issue, but I can see how it will be something relevant in many situations.

Have you guys considered this issue?

PS: Congrats for your hard work! I can now log into sites with throwaway ssessions in Firefox Focus and keep sane :)
 

shanedk

Well-known member
May 20, 2018
324
89
Not SQRL's problem. They can do it with passwords, they can do it with SQRL. SQRL doesn't in any way prevent you from doing email verification, it just doesn't mandate it the way passwords do. You can also use CAPTCHAs and other techniques. There are already many Wordpress plugins to help with this situation.
 
  • Like
Reactions: MarkH

sengsational

Well-known member
Feb 17, 2019
115
34
Although it's not SQRL's problem, anything that stands in the way of adoption is SQRL's problem.

We proudly say "SQRL doesn't give web sites any secrets to keep", then the web site, outside of SQRL proper, promptly gathers secrets to keep (like your e-mail address or your cell phone number) so they can do a "loop" in order to keep bad guys from generating multiple accounts.

It's for this reason that I think traction, if it comes, will come as a second factor. The power of userid/password is already weakened from what it used to be. Back in the "old days", if you had userid/password, you had nothing to worry about. Now, you can have userid/password, but very often get the dreaded "unrecognized device". All userid/password did for you is get you to the next authentication step. Web owners treat userid/password as weaker now, and they want more (a second factor). Those are typically something with significant weaknesses, thing like "secret questions" or an SMS loop. And significantly hard to set up, hard to maintain and error-prone. What if the next authentication step was easier to set-up and easier to mange than those authentications and air-tight strong? I just think that the "sales message" for SQRL as a second factor is much stronger than it is for SQRL as primary factor in place of userid/password. Broken record, I know. :)

It would work like this: You establish a relationship with a site, the same way that you do today (userid/password). After the site trusts you enough, maybe during account creation, or maybe later, they offer to you the option of having SQRL as a second factor. You'd associate your SQRL identity with them while in an authenticated session. Maybe you run the user through primary and existing secondary factors before allowing them to associate their SQRL id. Once the first successful SQRL authentication, the user probably should be given the option to turn off the weaker second factor.
 
Last edited:

PHolder

Well-known member
May 19, 2018
956
128
You establish a relationship with a site, the same way that you do today (userid/password).
This is exactly opposite of what SQRL is designed to do. SQRL has account management built in precisely to mimic all that one would do "the old way".

Your proposal, in response to SPAM, is a sledgehammer to kill a fly. Sites will manage their account signups as they always have... by requiring speedbumps in the process that slow bots down. (Email round trips, CAPTCHAs, a credit card, a SMS message, etc.) There is nothing about SQRL that makes it any easier or any harder to script than a standard username/password... so nothing to be gained by pretending you still need username/password.
 
  • Like
Reactions: Gristle

PHolder

Well-known member
May 19, 2018
956
128
however, to accept new SQRL logins I had to enable users registrations
I don't know the inner workings of Wordpress, but perhaps you can allow registrations but ONLY if they're SQRL registrations? Perhaps this is a feature that @kalaspuffar can comment on.

In any case, you'll want to use one of the usual methods to slow down SPAMmers: Email round trips, CAPTCHAs, a credit card, a SMS message, etc. And ideally new members aren't granted full abilities until they prove themselves in a bit.
 

Vela Nanashi

Well-known member
May 19, 2018
661
112
This might not all apply to wordpress for instance but could be implemented by any server using SQRL:

Also you could allow registration, with captcha, then on top of that have limited initial account, with moderation before posts are allowed through, and perhaps set up an option to time out accounts that have failed to post anything useful, or not done anything else that warrants them being around, or of course allowing easy banning and removal of their account should they try to post spam, you can also limit the number of new accounts a single ip : port or ip can make without getting a post approved, lots of things that do not require gathering any personal data about the user. You could even keep these accounts in a pending database, and inform them that if they do not do X before Y time has passed their account will be forgotten, then once they graduate you can move them to the more persistent database :)
 

kalaspuffar

Well-known member
May 19, 2018
270
91
Sweden
coderinsights.com
I don't know the inner workings of Wordpress, but perhaps you can allow registrations but ONLY if they're SQRL registrations? Perhaps this is a feature that @kalaspuffar can comment on.
Hi @PHolder

We have started one of these discussions on the GitHub repository.

https://github.com/kalaspuffar/wordpress-sqrl-login/issues/37

I've not looked into it yet but having an option to only allow SQRL registrations or other interesting choices is something I want to research. I can't say for certain that it could be implemented. I want to create things that work well with other plugins, and that means I can't override other behavior that other plugins might require to function.

Best regards
Daniel
 

AlanD

Well-known member
May 20, 2018
97
17
Rutland, UK
I have not used Wordpress much, nor delved into the depths of it, but could the solution not be as simple as not having a Username/password box on the login page? Just have a SQRL link. Even if you are using core Wordpress or an addin, it must be possible to modify the html.
 
G

Gristle

Guest
Post removed due to harassment from PHolder
 
Last edited by a moderator:
G

Gristle

Guest
Post removed due to harassment from PHolder
 
Last edited by a moderator:
G

Gristle

Guest
Post removed due to harassment from PHolder
 
Last edited by a moderator:

sengsational

Well-known member
Feb 17, 2019
115
34
@Gristle , @PHolder , time will tell. My premise is that web site owners of significant/established sites simply won't jump in with both feet and give SQRL the same prominence as userid/password (i.e. put it on their login page). They, in my opinion, just won't do that large of a jump. I think we agree that the current state is that they have userid/password as primary and various flimsy second factors that cause them and their users at least occasional pain. I contend that they won't be sticking their necks out much by adding SQRL as yet another option for a second factor. Lower resistence means higher chance of adoption. If SQRL catches-on, it will be trivial to gently promote SQRL to the recommended second factor or even primary factor some day. But we shall see where traction happens. You guys are on record as thinking I'm full of it. Got it.