How to recover an account with a lost password on your MU Online server
Set up and run a secure password recovery process for your MU Online server's players, including identity verification, web panel reset, and direct database reset when needed.
Losing a password is one of the most common support tickets on any MU Online server, and how you handle it shapes the perceived security and professionalism of your project. A sloppy process — resetting a password just because someone asked on Discord — opens the door to account theft and damages th
Losing a password is one of the most common support tickets on any MU Online server, and how you handle it shapes the perceived security and professionalism of your project. A sloppy process — resetting a password just because someone asked on Discord — opens the door to account theft and damages the community. This tutorial covers the full flow: identity verification, web panel recovery, manual database reset, and the security best practices needed to avoid turning support into a vulnerability.
Why the recovery process needs to be strict
Account theft is one of the most frequent complaints in private MU communities, and it often starts exactly with a flaw in the recovery process: a scammer impersonates the owner, requests a reset in a private message to the admin, and gets access to someone else's account. Treating password recovery as a security procedure, not a quick courtesy, is what separates trustworthy servers from those that suffer recurring fraud.
Where passwords are stored
In the most common emulators (MuEmu, IGCN, GMU), accounts live in the MEMB_INFO table (or an equivalent name) in the MySQL/MSSQL database, with the password stored as a hash. Before starting any recovery process, confirm which hashing algorithm your server uses — this determines how you'll generate the new password during a manual reset.
SELECT memb___id, mail_addr, bloc_code, appl_date
FROM MEMB_INFO
WHERE memb___id = 'nomedaconta';Automated flow via web panel
The ideal path is a self-service recovery panel, where the player enters their email or username, receives a reset link by email, and sets a new password themselves. A typical flow:
- The player clicks "Forgot my password" on the panel.
- The system generates a unique token with an expiration (15-30 min) and sends it to the registered email.
- The player clicks the link and lands on a new password form.
- The system validates the token, updates the hash in the database, and invalidates the used token.
- An email confirms the change was made, so the player notices if it wasn't them.
Identity verification when there's no automated panel
When support has to be manual (via Discord, ticket, or direct email), identity verification is the step you can't skip. Ask for at least two of the following before any reset:
| Verification item | Why it works |
|---|---|
| Email registered at signup | Only the original owner would have access |
| Character names on the account | A detail a scammer rarely knows by heart |
| Recurring login IP (compared to the ticket) | Indicates a history of legitimate access |
| Recent items in inventory or vault | Hard to guess without prior access |
| Approximate account creation date | Reduces risk of error on accounts with the same name |
Manual database reset
Once identity is confirmed and no automated system is available, a direct MySQL reset is the solution. Generate the new password's hash using the same algorithm the emulator uses (often plain MD5 or SHA-256, depending on the version) and update the corresponding column:
UPDATE MEMB_INFO
SET memb__pwd = SHA2('novaSenhaTemporaria123', 256)
WHERE memb___id = 'nomedaconta';Always provide a strong temporary password and instruct the player to change it immediately after logging in, so they don't keep reusing the temporary one set by support.
Logging the support case
Every manual reset should be logged — date, who requested it, who handled it, what data was used for verification. This protects the administrator in case of a future dispute ("I never asked for that reset") and creates a history to spot patterns of repeated fraud attempts against the same account.
| Log field | Example |
|---|---|
| Date/time | 2026-03-14 20:12 |
| Affected account | player123 |
| Handled by | GM_Bruno |
| Verification method | Email + character names |
| Action taken | Manual reset via SQL |
Prevention: reducing recovery requests
Encourage valid email registration at signup (blocking obviously fake emails), offer optional two-factor authentication for accounts with valuable items, and publish a visible FAQ on the site explaining the recovery process — this reduces the volume of repetitive manual tickets and exposure to fraud.
Differences between emulators in password storage
| Emulator | Typical table | Common algorithm |
|---|---|---|
| MuEmu | MEMB_INFO | MD5 or plain text (older versions) |
| IGCN | MEMB_INFO | SHA-256 (recent versions) |
| GMU / OpenMU | Account | BCrypt (more secure) |
| X-Team | MEMB_INFO | Varies, check config |
If your server still uses plain text or unsalted MD5, migrating to a stronger algorithm (BCrypt, salted SHA-256) should be a security priority, regardless of how urgent other tickets seem.
Automating with a Discord support bot
Many servers use bots (custom-built or based on frameworks like discord.js) to automate part of the verification: the bot asks for the data, cross-checks it against the database via an internal API, and only enables the reset button for a human moderator after the automated validation passes. This reduces human error and speeds up support without sacrificing security.
Common errors and fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Account stolen after password reset | Insufficient identity verification | Require at least two cross-checked verification items |
| Recovery email never arrives | Incorrect SMTP configuration on the panel | Review SMTP credentials and test manual sending |
| New password's hash doesn't match at login | Algorithm used in the UPDATE differs from expected | Confirm the emulator's exact algorithm before running the SQL |
| Player complains about a reset they didn't request | Lack of a support log | Implement mandatory logging for every reset |
| Scammer impersonates support | No clear official channel | Widely publicize the single valid support channel |
| Too many repeated manual tickets | No self-service recovery available | Implement an automated email-based flow on the panel |
Secure password recovery checklist
- Self-service email recovery flow working on the panel.
- Minimum identity verification criteria documented and followed.
- Password hash algorithm identified and updated if needed.
- Manual support log implemented.
- Single official support channel published on site/Discord.
- Public FAQ about password recovery available.
- Strong temporary password generated on every manual reset.
With a well-defined password recovery process, it's worth reviewing the server's overall security to reduce other attack vectors — see the MU Online server setup tutorial to check the fundamentals of secure configuration from the start.
Frequently asked questions
Is it safe to reset a password directly in the database?
Yes, as long as you're certain of the player's identity before doing so. A direct MySQL reset is the most reliable method when the email recovery panel fails or the player no longer has access to their registered email.
How do I confirm the player is really the account owner?
Ask for at least two pieces of information only the owner would know: registration email, recent inventory items, character names, a recurring login IP, or the answer to a security question set at registration. Never reset a password based solely on a username mentioned in chat.
What if the player doesn't even remember the registered email?
Look up the account by character name in the database and check indirect data, such as login IP or account creation date, cross-referencing it with whatever the player can recall from memory, like rare items or the guild they were in.
How are passwords stored in the MU database?
Most emulators use a hash (MD5 or SHA, depending on the version) in the accounts table, usually MEMB_INFO or an equivalent. Storing passwords in plain text is never recommended; if your server does this, migrating to a hash should be a security priority before any other fix.
Should I automate password recovery via email?
Yes, it's ideal for reducing manual support load and avoiding human error. An email-based recovery system with a confirmation link and a 15-30 minute expiration handles most cases without needing direct database intervention.