Repository navigation
Change BCRYPT rounds to actual value #2356
Description
Activity
What is the motivation behind it? Everyone can set it higher too. Is there a specific reason to change the default?
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 consoleAnd it results on my i5-4590
Here addition calculations
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.bCryptLog2Roundin theconfig.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
50msper 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.
- added 2 commits that reference this issue
on Jun 19, 2021 - added a commit that references this issue
on May 2, 2026
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