Change this value from 10 to 12 please.
https://github.com/AuthMe/AuthMeReloaded/blob/master/src/main/java/fr/xephi/authme/settings/properties/HooksSettings.java#L47

What is the motivation behind it? Everyone can set it higher too. Is there a specific reason to change the default?

Here addition calculations

I make small python scrypt for show why 12 best value for bcrypt rounds, remember that bcrypt maked for do slower bruteforse attacks on database, and database of small server is usual have 1000+ users. Also for change this parametr you need to find class what you need, decompilate this class, change value, compilate class and finaly past it in .jar file.

Scrypt

import bcrypt
import time

timesToRepeat = int(input("How many times you want repeate hashing: ")) # Saving in memory, how many times need to repeate hashing
def code(rounds): # Make function for better time checker
    password = b"123123123" # Password to encode
    times = 0 # Starting point of the report
    while times < timesToRepeat: # Cycle
        hashed = bcrypt.hashpw(password, bcrypt.gensalt(int(rounds))) # Hashing password
        times = times + 1 # Add one for not infinity scrypt

start_time = time.time() # Starts timer
code(input("Rounds for generate: ")) # Asking how many rounds we need
print(f"%s seconds" % (time.time() - start_time)) # Print result in console

And it results on my i5-4590

Also for change this parametr you need to find class what you need, decompilate this class, change value, compilate class and finaly past it in .jar file.

No you don't need that. It's a configuration setting at the location the annotation specifies. It's at ExternalBoardOptions.bCryptLog2Round in the config.yml. That's what I mean it's only a default value. Everyone can change it. However, we should pick reasonable defaults.

I make small python scrypt for show why 12 best value for bcrypt rounds, remember that bcrypt maked for do slower bruteforse attacks on database, and database of small server is usual have 1000+ users.

Calculating the cost factor is always a compromise between security and performance. You don't want to impact the server performance too much, but also don't want to give out the clear password too easily. Considering your benchmark numbers, the configuration would be quite secure against bruteforce. The issue with bruteforce attacks is that you don't just guess the correct one. You need many tries. Naive ideas (i.e. [a, aa, aaa]) would mean already huge combinations (alphanumeric with up to 8 in length: 58^8+58^7+58^6+...) and you need hash it for each password stored in the database, because of the unique salt.

I measured it myself. Considering a cost of 50ms per hash would mean we would finish (complete run) the very big rockyou wordlist (from Kali Linux) without any additional bruteforce modifications in around 99 hours for a single password stored. With the additional usage of ASIC and GPU in case of BCrypt it would be even faster. Considering its original design to use 250ms each would mean your cost factor of 12 or even higher.

But how important is this performance compromise for a Minecraft server? 250ms would mean 4 passwords a second, which opens the target for DOS attacks based registration or login attempts. My opinion is that we could raise the default value. Other websites also use 12 as cost factor nowadays. Attacks should be prevented with other means.

I think you right, but default config as usual stay on small servers, they can afford some slower speed for this. Online is small, you know. And big servers (I mean from ~100 players) know what they doing. So i think we can do it some slower for those who dont see any difference, and do it more safety in few times.

I think you right, but default config as usual stay on small servers, they can afford some slower speed for this.

Well they might also have weaker hardware available. More often we would see shared hardware (e.g. virtualization) in this case. I'll open up a PR for discussion. In my opinion, if you care about this issue you shouldn't be using BCrypt. BCrypt has low memory requirements. This means GPUs can programmed to hash it. They can compute it in a massively parallel way (e.g. multiple password tries at once). They are commonly available in general computers (not like ASICs or FPGAs). Other algorithms like SCrypt could be better in this way.