Slime Login

Migrating from nLogin#

One command. Passwords keep working — players do not have to reset anything.

/slimeadmin import nlogin

Before you start#

  1. Stop the old plugin (or the whole server) so nothing is writing to its database.

  2. Take a copy of nLogin's database. Import from the copy if you want to be careful:

    cp plugins/nLogin/nlogin.db /tmp/nlogin-copy.db

  3. Run the import on whichever install owns the accounts — the proxy on a network, or the single server otherwise.

Running it#

/slimeadmin import nlogin
/slimeadmin import nlogin plugins/nLogin/nlogin.db

With no path it searches plugins/ (and the folder above it) for database files and opens each one to see which actually holds accounts — the filename does not matter. If it finds nothing it tells you where it looked.

/slimeadmin import nlogin jdbc:mysql://localhost:3306/nLogin root secret

Needs a MySQL JDBC driver on the server. If there is none, the command says so — copying nLogin's SQLite file over and importing that always works.

/slimeadmin import nlogin plugins/nLogin/nlogin.db overwrite

By default an account that already exists here is left alone. overwrite replaces it.

/slimeadmin import nlogin report

Reads the database and tells you how many accounts it found and which password formats they use, without writing anything. Worth doing before the real import on a live server.

Found 88 account(s) in table nlogin.
Password formats: BCrypt (2a) x49, Argon2id x39.

The result:

[Slime] Import complete: 1284 account(s) added, 3 already existed. (table: nlogin)

If any account used a format that cannot be carried over, a second line says so and counts them:

[Slime] 2 account(s) used a hash that cannot be verified (PBKDF2).
        Those players have to register again.
\"Could not find a database with accounts in it\"

The command searched and came up empty. Usually one of:

  • nLogin ran on MySQL — there is no file to find. Use the jdbc: form above.
  • The database is on another server. On a network, nLogin's accounts live wherever its auth-servers were, not necessarily on the proxy. Copy the file across and pass its path.

  • It is somewhere unusual. Find it and pass the path:

    find . -name "*.db" -o -name "*.sqlite"

The error message lists the files it did open, which usually points straight at the answer.

Do passwords survive?#

Almost always, yes.

nLogin algorithm Result
BCRYPT2A (nLogin's default) ✓ works immediately
BCRYPT2Y ✓ works — the revision tag is normalised
MD5, SHA256, SHA512 ✓ works, including salted forms
ARGON2ID / ARGON2I / ARGON2D ✓ works — the hash carries its own parameters
PBKDF2 ✗ cannot be verified — those players must register again

The command reports exactly how many accounts fall into the last group, so you know the size of the problem before anybody complains.

Hashes upgrade themselves

An imported account keeps nLogin's hash until its owner logs in. The first time the password is verified, it is quietly re-hashed with your own bcrypt-rounds setting and saved. Nobody is asked to do anything, and the migration finishes itself one player at a time.

What is imported#

From nLogin Becomes
last_name Username
mojang_id / premium Premium flag, and the account's UUID when premium
password Password hash (converted if needed)
last_ip Last known IP
creation_date First join
last_seen Last login

Trusted IPs, emails, Discord links and 2FA settings are not imported — Slime Login has no equivalent for them. Players keep their accounts; they just log in with a password until a session or trusted IP builds up again.

The UUID trap#

nLogin's unique-id-type can be REAL, RANDOM or OFFLINE. If it was RANDOM, a cracked player's stored id is one that neither this plugin nor the server will ever see again — importing it as-is would leave every cracked player looking unregistered.

So cracked accounts are re-keyed to the offline UUID derived from their name, which is what they actually join with. Premium accounts keep their real Mojang UUID from mojang_id.

Which table it reads#

nLogin's account table is nlogin, with columns last_name, unique_id, mojang_id, password, premium, last_ip, last_seen, creation_date. The importer finds it by shape as well as by name — any table with a name column and a password column qualifies — so a renamed table, an older nLogin version, and AuthMe-shaped databases all work too.

After importing#

  1. Check a few accounts: /slimeadmin info SomePlayer
  2. Test a real login with a known password.
  3. Remove nLogin from every server it was installed on. Never run two auth plugins at once.
  4. On a network, put the Slime Login jar on the backends so unauthenticated players cannot move — see Bridge mode.

The + suffix

If the old install used nLogin's username-appender, offline players' names may be stored with a suffix such as Notch+. Those come across as written. Check a few names after importing; if your server used that feature, ask on Discord before rolling the import out.