As I mentioned previously, I started my project by preparing an "app" for onboarding. Not very intensively, but I’ve spent 8 years here (
How registration works in our app
First and foremost, it is tailored to our target audience (lovers of history and historical simulations), so that users immediately feel right at home. Then, step by step:
Username
The username selection is dynamically verified for availability and correctness. If a name is already taken, similar suggestions appear, taking into account the specificity of the portal — for example, nobel-johne, because johne is already taken.
(Master) Password
I have to say here that I was surprised this was even possible, because I don’t think any onboarding app I’ve used (I’ve tried several, though obviously not all) allows the user to choose their own password — they only generate one themselves. I consider this approach pointless and precisely unintuitive. So, since it is technically feasible, in our case the user chooses their own master password, of course with the necessary restrictions. Obviously, the password is not stored on our side anywhere. This solution brings our registration process much closer to what is used everywhere else. It looks like this:
Security measures
First, we have a CAPTCHA quiz with non-obvious questions and answers, which should nevertheless be solvable for our target audience. Expanding the pool of questions and adapting them for the English version will require some work — this should make it significantly harder for bots to proceed.
Second, as an additional security measure, we have a limit on the number of registrations that can be performed from a given IP address within a specific time window.
Email address
- Security. I don’t know how other frontends have solved this — whether they store these addresses in their own databases — but I assume they do, which somewhat deviates from the blockchain idea. In our case, the email is stored on the blockchain, but encrypted in a way that allows only the admin designated for the application (i.e., sarmatia.app) to read the email addresses. In my opinion, this increases the security of the email database, provided that I take proper care of my own keys.
Most importantly, however, providing an email is optional.
- Why do we need an email? Certainly not for any verification (it’s absurd nowadays to think that this actually protects against anything when someone can have a bot reading the inbox and replying to received emails…). It serves two auxiliary purposes. The first is to increase the ability to communicate with real users, especially when they are inactive. The second is to increase the chance that the user will not lose their keys due to carelessness. For people who provide their email, our application will be able to send them an encrypted, password-protected PDF file containing their keys. Neither the PDF nor its content is stored in any way on our side.
Warnings
Right before final confirmation of registration, the user receives a set of warnings and information about how important it is to safely save their keys and that there is no possibility of recovering them.
It looks like this:
What are the risks
As almost always and everywhere, all risks come down to two sources: bad people and stupid people.
Stupidity
In the case of onboarding, stupidity boils down to two issues — losing (or sharing) the keys and not saving them. I believe that we (me and AI) have done everything possible to minimize such situations without abandoning what is essential to the blockchain and what cannot be compromised (i.e., we do not store the keys, we do not offer the possibility of recovery, nor can the administration change them). I think our target audience will not have this kind of problems at allStrikethrough.
Bad people
What can bad people do with our application? Unfortunately, they can use it to create spam accounts for free or accounts that want to abuse the network in other ways.
But let’s be serious — do micro-fees, registration via X login, or other onboarding methods really protect against this effectively? No, they don’t. So why make it harder for normal, good people to access Hive? The quiz plus the IP limit will filter out the simplest threats. More sophisticated ones won’t be effectively stopped by any other method either.
The only thing that worried me was whether I would be able to generate enough tokens for free registrations. It turns out, however, that the HP I possess is sufficient for a quite decent rate of acquiring these tokens, so I think it will be fine.
If you have any questions or suggestions regarding this process, I would be very grateful if you shared them in the comments :)
Jak wygląda Rejestracja na Sarmatia Mundi
Jak wspomniałem poprzednio, swój projekt rozpocząłem od przygotowania "aplikacji" do onboardingu. Niezbyt intensywnie ale spędziłem tutaj 8 lat (
Jak działa u nas rejestracja
Przede wszystkim jest skrojona pod naszego potencjalnego odbiorcę (miłośnika historii i historycznych symulacji), tak aby od razu czuł się jak u siebie w domu. Następnie po kolei mamy:
Nazwa Użytkownika
Wybór nazwy użytkownika jest dynamicznie weryfikowany pod kątem zajętości i poprawności. Gdy nazwa jest zajęta to pojawiają się sugestie podobnych z uwzględnieniem specyfiki portalu - czyli np szlachcic-jan, bo jan jest zajęte)
(master) Hasło
Muszę tutaj napisać, że byłem zaskoczony iż jest to możliwe, ponieważ chyba żadna aplikacja do onboardingu (używałem kilku, ale oczywiście nie wszystkich), nie pozwala na wybranie swojego hasła, tylko je generuje sama. Uważam to za bezsensowne i właśnie nieintuicyjne. Tak więc ponieważ jest to wykonalne to u nas użytkownik sam wybiera master password oczywiście z obostrzeniami i oczywiści hasło nie jest nigdzie zapisywane po naszej stronie. Takie rozwiązanie znacząco przybliża naszą rejestrację, do tych stosowanych wszędzie indziej. Wygląda to jak poniżej:
Zabezpieczenia
Po pierwsze mamy CAPTCHA quiz ale z pytaniami i odpowiedziami nieoczywistymi, które jednak dla naszych odbiorców powinny być do przejścia. Pracy wymaga rozbudowa puli pytań i dostosowanie ich pod wersję EN, powinno to utrudnić botom przejście dalej.
Po drugie jako dodatkowe zabezpieczenie mamy limit wykonania rejestracji dla danego IP w określonym przedziale czasowym.
Adres mailowy
- Bezpieczeństwo. Nie wiem jak rozwiązały to inne frontendy, czy trzymają te adresy gdzieś w swoich bazach danych ale przypuszczam, że tak właśnie jest, co trochę odchodzi od idei blokchainowej. W naszym przypadku jest on zapisywany na blokchainie ale w zaszyfrowany w sposób, który pozwala odczytać adresy mailowe tylko ustanowionemu dla aplikacji adminowi (czyli sarmatia.app). Jak uważam zwiększa to bezpieczeństwo bazy maili, o ile ja sam będę dbał o moje klucze.
Przede wszystkim jednak, podanie maila jest opcjonalne. - Po co nam mail? No więc nie do żadnej weryfikacji (przecież to absurd dziś uważać, że to zabezpiecza przed czymkolwiek, gdy można mieć bota czytającego skrzynkę i odpowiadającego na otrzymane na nią maile...), tylko do dwóch pomocniczych celów. Pierwszy to zwiększenie możliwości komunikacji z realnymi użytkownikami, zwłaszcza w sytuacji ich nieobecności. Drugi to zwiększenie szansy użytkownika na nie utracenie kluczy przez nie uwagę. Nasza aplikacja dla osób które podadzą maila, będzie w stanie przesłać zaszyfrowany, zabezpieczony hasłem użytkownika plik pdf zawierający klucze. Ani pdf, ani jego treść nie będzie w żaden sposób nigdzie po naszej stronie zapisywana.
Ostrzeżenia
przed samym potwierdzeniem zapisu, użytkownik dostaje porcję ostrzeżeń i informacje o tym jak ważne jest bezpieczne zapisanie kluczy i że nie ma możliwości ich odzyskania.
Wygląda to tak:
Jakie są zagrożenia
Jak chyba zawsze i wszędzie wszelkie zagrożenia sprowadzają się do dwóch źródeł: złych ludzi i głupich ludzi.
Głupota
W przypadku onboardingu głupota sproawdza się do dwóch kwestii - zgubienia(przekazania) i nie zapisania kluczy. Wydaje mi się, że zrobiliśmy (ja z AI) wszystko co możliwe by ograniczyć do minimum takie sytuacje bez rezygnacji z tego co jest istotne dla blokchaina i z czego zrezygnować nie można (a więc nie zapisujemy kluczy, nie dajemy możliwości odzyskania, czy zmiany tychże przez administrację). I sądzę, że nasi potencjalni odbiorcy nie będą mieli tu problemu.
Źli ludzie
Co mogą zrobić źli ludzie z naszą aplikacją? No niestety wykorzystać ją do darmowego tworzenia kont spamerskich czy chcących inaczej nadużywać sieci.
Bądźmy jednak poważni, czy naprawdę mikro opłaty, rejestracja loginem X czy inne metody onboaedingu realnie przed tym zabezpieczają? Nie, więc po co utrudniać zwykłym, dobrym ludziom dostęp do Hive. Quiz plus ograniczenie na IP odsieje najprostsze zagrożenia. Tych trudniejszych efektywnie żadne inne też nie zlikwiduje.
Jedyne co mnie martwiło to czy będę w stanie generować dość tokenów do darmowej rejestracji. Okazuje się jednak, że posiadane przeze mnie HP wystarcza na całkiem niezłe tempo pozyskiwania tych tokenów, więc myślę, że będzie ok.
Jeśli macie jakieś pytania, albo sugestie do tego procesu to będę bardzo wdzięczny za podzielenie się nimi w komentarzach :)