New user's opinion about SQRL in 2020


Iotanbo

New member
Jul 7, 2020
2
0
Hello dear members,
Today I accidentally found this site and immediately got fascinated by the idea.
Here are some of my thoughts about the subject.

1) From a site developer's point of view, one of the biggest problems with SQRL is the ability of
uncontrolled account creation. There must be a mechanism to protect web services from flooding them
with new accounts, something like Proof of Work, account blockchains, or another protection system (maybe I missed something?).

2) Most likely a lot of major web sites will not implement SQRL in the nearest future
because their direct (or hidden) interest is surveillance, tracking and getting as much user data as possible.

3) On the other hand, there are a lot of sites which will benefit from SQRL, and so will users.

4) After trying to type SQRL textual identity on my tablet,
I'd like to make a proposal to use seed phrases (like in bitcoin). That will make typing easier.
https://en.bitcoin.it/wiki/Seed_phrase

Best regards,
Yuri.
 

PHolder

Well-known member
May 19, 2018
1,207
202
maybe I missed something
Yes, I think you did. SQRL is NOT the entirety of the site's user account creation. It is merely part of it. You can add whatever you want in the process of creating accounts. A simple CAPTCHA aught to suffice, IMHO, if you want otherwise anonymous user accounts.

their direct (or hidden) interest is surveillance
There is no requirement for SQRL to be anonymous. See above. A site can still ask for an email address, money (a CC or whatever), or a copy of your drivers license. The issue is not about the site, it's about user acceptance of what the site is requiring. Beyond the *option* to be quick and anonymous, nothing has changed.

I'd like to make a proposal to use seed phrases
This is a possibly good idea, and maybe some of the clients will [optionally] adopt it. (There is no SQRL protocol change necessary for it.)
 
  • Like
Reactions: rxp

Iotanbo

New member
Jul 7, 2020
2
0
After taking a closer look, I must agree with you.
Registration process may look like this: first, user confirms his e-mail or phone number.
Second, after confirmation is complete, user links his SQRL ID to that account.
No problems, indeed.

SQRL is a good idea, and is definitely worthy of implementing. I'll give it a try in my next projects.
 

AlanD

Well-known member
May 20, 2018
124
23
Rutland, UK
1) From a site developer's point of view, one of the biggest problems with SQRL is the ability of
uncontrolled account creation. There must be a mechanism to protect web services from flooding them
with new accounts, something like Proof of Work, account blockchains, or another protection system (maybe I missed something?).
With SQRL it is not possible for a single SQRL client to flood a server rapidly with multiple new accounts as each time it tries to create an account, it will have the same unique public key. To achieve different unique keys, the client will need multiple client identities, and unlocking each one to switch between them takes several seconds which will mitigate the flood attack.
 

PHolder

Well-known member
May 19, 2018
1,207
202
achieve different unique keys
You're assuming good intentions @AlanD. As a proof of concept I wrote an attack client for @Steve's demo server that generated random private keys and flooded the server with accounts. For such a client, there is no need to encrypt anything, as there is no intention to keep the attack accounts secure.
 
  • Like
Reactions: josecgomez

shanedk

Well-known member
May 20, 2018
420
112
It's certainly possible for a malicious script to flood the server with tons of SQRL login requests, but that can also be done with anything else. A script can flood a server with bogus login requests with random usernames and passwords. DDoS mitigations are there to take care of that sort of thing.

The main difference is, with usernames and passwords, they're doing it not as a DDoS attack, but in the hopes they'll get lucky and hit on a user/pass combination that gets them in (since people tend to reuse these, and some are more popular than others, like "p@ssw0rd"). With SQRL, that can't happen.

There could also be SQRL-specific mitigations, such as not allowing account creation with an invalid nut.
 

AlanD

Well-known member
May 20, 2018
124
23
Rutland, UK
One of the simpler mitigations would be something like "Fail2Ban". This is an application for Linux servers which monitors failed logins, whether web, mail, ssh or any other logs defined, and then manipulates the firewall to block connections from that address for a period. There is no reason why that could not be configured to block sources of repeated failed SQRL logins.
 
  • Like
Reactions: alexT