Bcrypt hashes Spring Security will accept
Set to the $2a$ prefix and cost 10 that Spring Security expects. Change either one if your project has been configured differently. Nothing you type here leaves the browser.
Everything below this line runs locally
0/72 bytes · 1,024 iterations · 0 network requests
PHP counts only $2y$ as bcrypt, so Laravel Hash::check() rejects this hash with "This password does not use the Bcrypt algorithm" before it compares anything. Pick $2y$ for PHP, Laravel or Symfony. Why the prefix matters
BCryptPasswordEncoder defaults to strength 10 and writes $2a$. If you store hashes through DelegatingPasswordEncoder they carry a {bcrypt} prefix in front of the hash itself.
The same thing in Spring Security
Hashing in Spring Security
var encoder = new BCryptPasswordEncoder(12);
String hash = encoder.encode("correct horse battery staple");Checking a password
if (encoder.matches(rawPassword, storedHash)) {
// the password matched
}From a terminal
mvn -q exec:java -Dexec.mainClass=HashOnceCheck a hash from your database
Paste a stored hash and a candidate password to confirm they match, which is a quick way to rule the hash out when a login is failing for reasons you cannot see.
Verification also runs locally
Other stacks
- Laravel Bcrypt hashes with the $2y$ prefix and Laravel defaults.
- PHP Hashes that PHP password_verify accepts, with the $2y$ prefix.
- Node.js Hashes for the bcrypt and bcryptjs packages, $2b$ prefix.
- Python Hashes for the Python bcrypt package and passlib, $2b$ prefix.
- Java Hashes for jBCrypt and Spring Security, $2a$ prefix.
- Go Hashes for golang.org/x/crypto/bcrypt, $2a$ prefix.
Questions people ask
- Which prefix does Spring Security write?
- $2a$. The tool on this page is set to that by default. For any password under 72 bytes the digest is identical across $2a, $2b and $2y, so the prefix is a label rather than a different algorithm, and most libraries verify all three regardless of which one they produce. PHP is the exception: password_verify accepts all three, but password_get_info reports bcrypt only for $2y, and Laravel Hash::check asks that question before it compares, so a $2a or $2b hash is refused there with "This password does not use the Bcrypt algorithm".
- What cost does Spring Security use by default?
- BCryptPasswordEncoder defaults to strength 10 and writes $2a$. If you store hashes through DelegatingPasswordEncoder they carry a {bcrypt} prefix in front of the hash itself.
- Can I paste this hash straight into my database?
- Yes. A bcrypt hash is 60 characters and carries its own version, cost and salt, so the column needs no companion fields. Check the column is at least 60 characters wide, because a narrower one will truncate and lock the account out.
- Is it safe to generate a production password here?
- The hashing runs in your browser and this page makes no network request when you press the button. For a seed account or a test fixture that is fine. For a real user credential, the better habit is to let your own application hash it.
- Why does my Spring Security login reject a hash that looks correct?
- Usually one of four things: a prefix the framework will not accept, which on PHP and Laravel means anything other than $2y$, a trailing newline picked up during copy and paste, a column too narrow to hold all 60 characters, or a password longer than 72 bytes where the two sides truncated it differently.