3

I searched through the Documentation for Spring 5 Security but I could not find a reference to the BCrypt $2y$ version prefix anywhere.

When looking through the source code, though, I found one reference in the Javadoc of the PasswordEncoder:

can optionally supply a "version" ($2a, $2b, $2y)

Can anyone give me some consensus? Is it possible to use the $2y$ bcrypt version prefix when using Spring 5 Security?

Titulum
  • 9,928
  • 11
  • 41
  • 79
  • 2
    Have you tried it? The link you've provided is for spring-security (which you're asking for) so I can't think of a reason why it wouldn't work. – Mark Jan 29 '19 at 07:51
  • I can try, but if this works then why is it nowhere included in the Spring documentation? This is a big improvement, as the $2y$ version prefix has been a major hassle in the past. – Titulum Jan 29 '19 at 08:20

1 Answers1

6

It depends on what version you're using, the commit in which this feature introduced was on Oct 18, 2018. It has the tag 5.2.0.M1 which means that's the release this commit will be introduced in, the official docs of that version now specify this feature exists:

Implementation of PasswordEncoder that uses the BCrypt strong hashing function. Clients can optionally supply a "version" ($2a, $2b, $2y) and a "strength" (a.k.a. log rounds in BCrypt) and a SecureRandom instance. The larger the strength parameter the more work will have to be done (exponentially) to hash the passwords. The default value is 10.

Before version 5.2.0.M1 this feature did not exist, there's no official release yet of this version, only snapshots (5.2.0.M1 was released on Jan 16, 2019).

This version (or newer) is what you'll have to use if you want to use this feature, until an official release is made.

Mark
  • 5,089
  • 2
  • 20
  • 31