Notatki operatora
AuthMe: logowanie i rejestracja na serwerze non-premium
Praktyczny przewodnik po AuthMe Reloaded: od tego, po co w ogóle wymuszać hasło na serwerze offline-mode, przez instalację na Paper i Spigot, wybór bazy SQLite albo MySQL i najważniejsze opcje w config.yml, po hashowanie haseł, integrację z proxy oraz typowe problemy. Z perspektywy kogoś, kto już raz tłumaczył graczowi, dlaczego nagle „ktoś wszedł na mój nick i rozwalił bazę”.
W skrócie: AuthMe Reloaded wymusza hasło na serwerze non-premium, gdzie nie ma weryfikacji Mojanga i każdy może wejść na cudzy nick. Po dołączeniu gracz musi użyć /register hasło hasło, a przy kolejnych wejściach /login hasło. Na jeden serwer wystarczy domyślne SQLite; przy sieci serwerów za proxy przejdź na MySQL, żeby konta były wspólne. W config.yml ustawiasz sesje, limit prób logowania, captcha i algorytm hashowania, gdzie dla nowego serwera wybierz BCRYPT, nie SHA256. AuthMe to standardowy element każdego sensownego serwera offline.
Po co AuthMe na serwerze non-premium
Na serwerze premium (online-mode) tożsamość gracza potwierdzają serwery Mojang. Zanim ktokolwiek wejdzie pod danym nickiem, musi zalogować się na prawdziwe konto Minecrafta, więc nick i konto są ze sobą sztywno powiązane. Na serwerze non-premium, czyli w trybie offline (online-mode=false), tej weryfikacji po prostu nie ma. Serwer przyjmuje każdy nick, jaki gracz wpisze w kliencie, i nie sprawdza, czy ten ktoś rzeczywiście jest jego właścicielem.
To rodzi konkretny problem: dowolna osoba może wpisać cudzy nick i wejść na konto z całym dorobkiem, uprawnieniami i przedmiotami. Jeśli na serwerze ten nick ma rangę administratora, intruz dostaje uprawnienia administratora. To nie jest teoretyczne zagrożenie, na otwartych serwerach offline to jedna z pierwszych rzeczy, które się dzieje.
AuthMe rozwiązuje to, dokładając własną warstwę logowania. Gdy gracz dołącza, serwer zamraża go do czasu uwierzytelnienia. Nowa osoba zakłada konto komendą /register, ustalając hasło, a przy każdym kolejnym wejściu loguje się komendą /login. Dopóki gracz się nie zaloguje, nie może się ruszać, pisać na czacie ani używać komend. W ten sposób AuthMe zastępuje brakującą weryfikację Mojanga własnym hasłem i to dlatego jest praktycznie obowiązkowym elementem każdego serwera Minecraft non-premium.
Dla jasności: AuthMe nie ma nic wspólnego z piractwem ani z obchodzeniem zabezpieczeń. To zwykły plugin do uwierzytelniania, którego sens jest czysto techniczny, czyli ochrona kont na serwerze działającym w trybie offline. Tryb offline ma legalne zastosowania, choćby sieci serwerów za własnym proxy, gdzie weryfikacją zajmuje się warstwa nadrzędna.
Instalacja
AuthMe Reloaded działa na serwerach opartych o Bukkit, czyli w praktyce Spigot i Paper (zalecany Paper). Instalacja na pojedynczym serwerze jest prosta:
- Pobierz aktualny plik
.jarAuthMe ze strony projektu lub z SpigotMC. - Wrzuć go do katalogu
pluginsi zrestartuj serwer. - Przy pierwszym starcie AuthMe wygeneruje katalog
plugins/AuthMez plikiemconfig.ymloraz domyślną bazą SQLite. - Upewnij się, że w
server.propertiesfaktycznie maszonline-mode=false. Na serwerze premium AuthMe nie jest potrzebny i tylko przeszkadza.
Po starcie zatrzymaj serwer, przejrzyj config.yml, ustaw to, co opisuję niżej, i dopiero wtedy wpuść graczy. Konfiguracja na żywo, gdy ludzie już się rejestrują, kończy się zwykle bałaganem w bazie.
Jeśli budujesz sieć serwerów za proxy (BungeeCord, Velocity), schemat jest inny i wrócę do niego w sekcji o integracji. Najważniejsza decyzja na starcie to wybór bazy danych, bo od niej zależy, czy konta będą lokalne dla jednego serwera, czy wspólne dla całej sieci.
SQLite czy MySQL
AuthMe domyślnie zapisuje konta w lokalnym pliku SQLite i to ustawienie jest w zupełności wystarczające dla pojedynczego serwera. Nie wymaga żadnej konfiguracji, działa od razu i jest łatwe do przeniesienia, bo to po prostu jeden plik.
MySQL albo MariaDB wybierasz wtedy, gdy masz sieć serwerów za proxy i chcesz, żeby gracz rejestrował się raz, a logował tym samym hasłem na każdej instancji. Wszystkie backendy muszą wtedy celować w tę samą bazę, którą ustawia się w sekcji DataSource pliku config.yml (backend: mysql plus dane dostępowe). Bez wspólnej bazy każdy serwer ma własny, oddzielny zestaw kont, co przy sieci serwerów prawie nigdy nie jest tym, czego chcesz.
Konfiguracja: config.yml
Większość pracy z AuthMe to ustawienie kilku sekcji w config.yml tak, żeby pasowały do charakteru serwera. Oto te, które realnie mają znaczenie.
Rejestracja i sesje
Sekcja registration decyduje, jak wygląda zakładanie konta. Domyślnie gracz potwierdza hasło dwukrotnie (/register hasło hasło), co warto zostawić, bo łapie literówki. Możesz też ustawić limit kont na jeden adres IP, żeby ograniczyć masowe zakładanie nicków z jednego komputera.
Sekcja sessions to rzecz, o którą gracze pytają najczęściej. Po włączeniu (sessions.enabled: true) AuthMe zapamiętuje zalogowanego gracza po adresie IP przez zadany czas. Dzięki temu po krótkim wyrzuceniu z serwera albo restarcie gracz nie musi logować się od nowa. Sesja jest powiązana z IP, więc po jego zmianie wygasa, co jest świadomym kompromisem między wygodą a bezpieczeństwem.
Captcha i limity prób
Żeby utrudnić zgadywanie haseł, AuthMe potrafi po kilku nieudanych logowaniach wymusić captchę, czyli kod do przepisania. Włączasz to w sekcji captcha, ustawiając próg liczby nieudanych prób. W parze z tym idzie limit błędnych logowań, po którym gracz zostaje na chwilę wyrzucony. Na otwartym serwerze offline to istotna ochrona przed atakiem słownikowym na konta administracji.
Hashowanie haseł: SHA256 vs BCRYPT
AuthMe nie trzyma haseł jawnie, tylko ich skróty (hash). Algorytm ustawiasz opcją passwordHash w sekcji security i to jest decyzja, której nie warto bagatelizować:
- SHA256 jest szybki, ale właśnie ta szybkość gra na korzyść atakującego. Jeśli baza kiedyś wycieknie, masowe łamanie skrótów SHA256 jest stosunkowo tanie.
- BCRYPT jest celowo wolny i ma wbudowaną sól oraz koszt obliczeniowy. To samo łamanie staje się o rzędy wielkości droższe, więc nawet po wycieku hasła są dużo lepiej chronione.
Dla nowego serwera wybierz BCRYPT (lub nowszy algorytm dostępny w Twojej wersji AuthMe). Dobra wiadomość: AuthMe potrafi przy kolejnym logowaniu w locie przekonwertować stary skrót na nowy algorytm, więc zmiana passwordHash nie unieważnia istniejących kont. Gracze po prostu przy następnym /login dostaną hasło zapisane w nowym formacie.
Z doświadczenia: zanim wpuścisz graczy, ustaw passwordHash na BCRYPT od razu. Migracja działa, ale dopóki gracz się nie zaloguje, jego hasło zostaje w starym, słabszym formacie. Na świeżym serwerze nie ma żadnego powodu zaczynać od SHA256 i potem to nadrabiać.
Najważniejsze komendy i opcje
W codziennej obsłudze wystarczy garstka komend gracza i kilka administracyjnych. Komendy administracyjne wymagają odpowiedniego uprawnienia (np. authme.admin.*), które najwygodniej nadać przez plugin uprawnień.
| Komenda / opcja | Co robi |
|---|---|
/register <hasło> <hasło> | Zakłada konto i ustawia hasło (gracz, przy pierwszym wejściu). |
/login <hasło> | Loguje gracza na istniejące konto. |
/changepassword <stare> <nowe> | Zmienia hasło zalogowanego gracza. |
/logout | Wylogowuje gracza, wymuszając ponowne /login. |
authme register <gracz> <hasło> | Administrator zakłada konto za gracza. |
authme password <gracz> <nowe> | Administrator resetuje hasło gracza (po zapomnieniu hasła). |
authme unregister <gracz> | Kasuje konto gracza, pozwalając zarejestrować nick od nowa. |
authme reload | Przeładowuje konfigurację bez restartu serwera. |
passwordHash (config) | Algorytm hashowania haseł, zalecane BCRYPT. |
sessions.enabled (config) | Włącza zapamiętywanie zalogowania po IP. |
registration.maxRegPerIp (config) | Limit kont na jeden adres IP. |
DataSource.backend (config) | Wybór bazy: sqlite lub mysql. |
Integracja: proxy i LuckPerms
AuthMe rzadko stoi sam. Na poważniejszym serwerze spotyka się z proxy i z systemem uprawnień, więc warto wiedzieć, jak się z nimi dogaduje.
BungeeCord i Velocity
Przy sieci serwerów za proxy AuthMe instaluje się na każdym backendzie (lobby, survival, minigry), a nie na samym proxy. Żeby gracz rejestrował się raz i był uznany za zalogowanego na wszystkich serwerach, wszystkie instancje AuthMe muszą korzystać ze wspólnej bazy MySQL i mieć włączoną komunikację między serwerami. AuthMe ma do tego osobną sekcję ustawień (między innymi opcje typu bungeecord oraz spójną konfigurację sesji), dzięki której przejście z lobby na survival nie wymaga ponownego logowania.
Ważna sprawa techniczna: za proxy serwer widzi adres IP proxy, a nie gracza, chyba że włączysz przekazywanie prawdziwego IP. To istotne, bo sesje AuthMe są wiązane z IP. Jeśli nie skonfigurujesz przekazywania adresu, wszyscy gracze będą dla AuthMe wyglądać jak jeden adres, co psuje zarówno sesje, jak i limit kont na IP. W praktyce na proxy włącza się odpowiedni tryb przekazywania IP, a backendy ustawia się tak, żeby mu ufały.
LuckPerms i ochrona ruchu przed zalogowaniem
Uprawnienia AuthMe (kto może użyć /register, /login czy komend administracyjnych) najwygodniej nadać przez LuckPerms, czyli standardowy dziś system uprawnień. Domyślnie grupa default powinna mieć prawo do rejestracji i logowania, a komendy typu authme.admin.* zostają zarezerwowane dla ekipy.
Druga rzecz to ograniczenie tego, co niezalogowany gracz w ogóle może zrobić. AuthMe blokuje ruch, czat i komendy do czasu logowania, ale warto dopilnować, żeby przed /login nie przechodziły żadne wrażliwe komendy innych pluginów. Sprawdź w konfiguracji AuthMe listę dozwolonych komend dla niezalogowanych i trzymaj ją możliwie krótką. Zasada jest prosta: dopóki gracz nie udowodnił, kim jest, ma móc zrobić wyłącznie to, co konieczne do zalogowania.
Bezpieczeństwo
Skoro AuthMe pilnuje kont na serwerze bez weryfikacji Mojanga, jego ustawienia bezpieczeństwa to nie kosmetyka. Kilka rekomendacji, które warto wdrożyć od pierwszego dnia:
- BCRYPT jako algorytm hashowania. Patrz wyżej. Dla nowego serwera nie ma powodu zaczynać od SHA256.
- Limit prób logowania plus captcha. Razem chronią konta administracji przed zgadywaniem hasła. Konto z uprawnieniami administratora to najcenniejszy cel na serwerze offline.
- Krótka lista komend dla niezalogowanych. Im mniej niezalogowany gracz może zrobić, tym mniejsze pole do nadużyć.
- Wymuszanie sensownej długości hasła. W sekcji
securityustaw minimalną długość, żeby ludzie nie zakładali kont z hasłem na trzy znaki. - Osobne, mocne hasła dla ekipy. Konta z uprawnieniami administracyjnymi powinny mieć wyraźnie lepsze hasła niż przypadkowy gracz, bo to one są celem ataku.
Pamiętaj też o czymś prostym: AuthMe chroni przed wejściem na cudzy nick, ale nie zastąpi kopii zapasowych świata i bazy kont. Jeśli komuś jednak uda się przejąć konto administratora, backup jest tym, co uratuje serwer.
Typowe problemy
- Gracz nie może się zarejestrować. Najpierw sprawdź, czy nie przekroczył limitu kont na IP (
maxRegPerIp) i czy ma uprawnienie do rejestracji. Za proxy bez przekazywania prawdziwego IP wszyscy dzielą jeden adres, więc limit wyczerpuje się błyskawicznie. - Komunikat „already registered”. Na ten nick istnieje już konto. Resetuj hasło komendą
authme password gracz noweHaslo, a jeśli konto ma trafić do innej osoby, skasuj je przezauthme unregister graczi pozwól zarejestrować od nowa. - Gracz loguje się przy każdym wejściu mimo sesji. Sprawdź, czy
sessions.enabled: true, czy czas sesji nie jest za krótki i czy przed AuthMe nie stoi proxy zmieniające widoczne IP. Sesje są wiązane z adresem, więc bez stabilnego IP nie zadziałają. - Konflikt na proxy (rejestracja działa tylko na jednym serwerze). Backendy nie współdzielą bazy. Przełącz wszystkie instancje AuthMe na wspólny MySQL i włącz komunikację między serwerami, inaczej każdy backend ma własny zestaw kont.
- Utracone hasło. Gracze nie odzyskają hasła samodzielnie (AuthMe trzyma tylko skrót, nie da się go odwrócić). Reset robi administrator komendą
authme password. Dobrze mieć opisaną procedurę resetu, najlepiej z dodatkowym potwierdzeniem tożsamości na Discordzie serwera. - Po zmianie nicku gracz traci konto. AuthMe wiąże konto z nazwą gracza. Przy zmianie nicku trzeba albo założyć nowe konto, albo administracyjnie przenieść dane, w zależności od wersji i konfiguracji.
Jeśli prowadzisz serwer offline i nie chcesz samodzielnie pilnować Javy, wersji pluginów i bazy danych, gotowy zarządzany hosting Minecrafta (Java) z obsługą pluginów pozwala wgrać AuthMe przez panel i menedżer plików, a do tego ustawić tryb offline i bazę MySQL bez grzebania w konfiguracji serwera od zera.
Najczęstsze pytania
Czy AuthMe jest potrzebny na serwerze premium (online-mode)?
Nie. W trybie online tożsamość gracza weryfikują serwery Mojang, więc nikt nie wejdzie na cudzy nick. AuthMe ma sens dopiero w trybie offline (online-mode=false), gdzie tej weryfikacji nie ma i trzeba wymusić własne hasło przez /register i /login.
SQLite czy MySQL: którą bazę wybrać?
SQLite wystarczy dla pojedynczego serwera i nie wymaga konfiguracji. MySQL/MariaDB wybierasz przy sieci serwerów za proxy, żeby konta były wspólne. Wszystkie backendy muszą wtedy celować w tę samą bazę w sekcji DataSource.
Gracz widzi „already registered”. Co robić?
Na ten nick istnieje już konto. Resetuj hasło przez authme password gracz noweHaslo albo skasuj konto komendą authme unregister gracz i pozwól zarejestrować od nowa.
Czym różni się SHA256 od BCRYPT?
SHA256 jest szybki, co ułatwia łamanie po wycieku bazy. BCRYPT jest celowo wolny, z solą i kosztem obliczeniowym, więc lepiej chroni hasła. Dla nowego serwera wybierz BCRYPT; AuthMe przekonwertuje stare skróty przy kolejnym logowaniu.
Dlaczego gracz musi się logować przy każdym wejściu?
Sprawdź sekcję sessions w config.yml. Po włączeniu i ustawieniu czasu wygaśnięcia AuthMe zapamiętuje gracza po IP. Jeśli sesje nie działają, najczęściej wina leży po stronie zbyt krótkiego czasu albo proxy zmieniającego widoczne IP.