Bcrypt algorithm support

[seremenko-wish]

Is your feature request related to a problem? Please describe.

1. Currently, Kratos only supports the Argon2id algorithm for password hashing. This algorithm is configured by 4 settings (parallelism, memory cost, number of iterations, and hash length), and there are no official recommendations about safe settings for this specific version of the algorithm.

2. The fact that Argon2 has to be calibrated for a specific environment, makes it cumbersome to use.

3. Missing support of the bcrypt algorithm blocks the importing user credentials feature described here Add ability to import user credentials #605.

Describe the solution you'd like

Bcrypt is a secure and well-established algorithm for password hashing, and it requires only one cost setting.

Wiki: https://en.wikipedia.org/wiki/Bcrypt

Additional context

The recommended minimum cost value is 10, but for the better tradeoff between security and user experience, that value can be increased to 12.

[leovanhaaren]

Would be nice if Bcrypt was supported yes, for us this is also a must-have and its a common algorithm.

[aeneasr]

BCrypt is not memory hard and thus not something we prefer supporting, Argon2id is the official recommendation of the PHC for password hashing.

We have since added tools that help you decide what your parameters should be, they are pending release 0.6. We'll also be giving out recommendations (the defaults included will follow those recommendations).

We will support importing of passwords, but as soon as the import is done they will be converted to Argon2id.

[leovanhaaren]

@aeneasr alright thanks for the answer, we are currently evaluating ory/kratos, so If I understand it correctly then this should land soon? (the importing of bcrypt passwords and auto converting them)

The above would also be enough for us, we just dont want every user having to manually to reset their password.

[aeneasr]

While I understand that a date of delivery is helpful when planning, we stopped giving out due dates for features or milestones. It puts maintainers in an unfair spot as

1. there are many things going on in the community which need time (reviewing PRs, addressing issues, answering questions) and demand is no not easily foreseeable;
2. maintainers do a lot of things in their free time and can not commit to deliver something;
3. internal priorization can shift at any point in time

When we do give out due dates, we often encounter people who are pissed off because something was promised and not delivered "on time" (as free software ;) ). Unfortunately that is the sad truth of many interactions in this context which is why we stopped doing it altogether.

Having said that, you are in the privileged position of being part in a global open source community! If you think that you can contribute towards the particular feature, maintainers will do their best to give you the right pointers and review PRs.

If that's not an option, you can consider to become a Ory Sponsor on Open Collective or Patreon. This helps us to employ more maintainers and technical staff - increasing velocity in development, community, interaction, and other areas! All collected money goes directly into this.

[seremenko-wish]

PHC is the Password Hashing Competition, which ran from 2013 to 2015 according to https://www.password-hashing.net/#phc. Why do you only consider the recommendation of this contest but not recommendations of The Open Web Application Security Project® (OWASP) which has credibility as opposed to PHC?

Check this out - https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

[aeneasr]

Hello, I did a lot of research yesterday. So Argon2id is superior to BCrypt if the amount of memory is enough so that a GPU (for example) can not use its memory cache. This means that Argon2id is suitable for scenarios where a login attempt can take over ~2 seconds. Below that threshold (e.g. 0.2s), BCrypt is better suited. Therefore, and for the reasons of simplicity (as stated in one of the comments) I think it makes sense to be a bit more flexbile here.

I could imagine that we support password upgrading (which we'll use for imported credentials too) which essentially boils down to being able to verify a hash with any given algorithm (e.g. scrypt,bcrypt,argon2,argon2id,php hash stuff) and since we then know the password, store it as the system preference (bcyrpt, argon2).

Here are my sources:

• https://twitter.com/Sc00bzT/status/1149950559258140673 (probably the most important one)
• https://twitter.com/TerahashCorp/status/1155129705034653698
• https://twitter.com/jmgosney/status/1360007668480507909
• https://twitter.com/Sc00bzT/status/1155284432737177601
• https://www.reddit.com/r/PHP/comments/gjhrg4/password_hashing_use_bcrypt_instead_of_argon2/

Generally, Argon2id is not a bad solution, it just tackles one of the problems (ASICS) with memory-hard but really we should focus on cache-hard. In any case, it still takes an almost infinite effort to crack (or rather find collisions) Argon2id hashes as it does cracking BCrypt.

@seremenko-wish would you be up for contributions towards this?

[zepatrik]

Ok so I think it is important to note that both Argon2id and bcrypt are suitable. Bcrypt seems better suited for a desired time <1s, and Argon2id above that. Therefore we should just support both, have this advise in the docs, and maybe also use the newly introduced hashing config options to help people which alg to choose.

[aeneasr]

👍

[seremenko-wish]

@seremenko-wish would you be up for contributions towards this?

Sure, I will work on it.

[seremenko-wish]

@aeneasr currently, hashers.argon2 option map holds the configuration for Argon2, and I am going to add hashers.bcrypt map with cost parameter. Also, I am going to add password.algorithm to switch between algorithms. Does it look ok?

[aeneasr]

Yes, that looks great!

[seremenko-wish]

@aeneasr is there a limit for a password length in Kratos? I am asking because bcrypt truncates input strings to 72 bytes if they are longer, so I wanted to clarify hasher behavior for the cases when passwords are longer (if it is allowed)

[aeneasr]

There is currently no upper limit on passwords. I think BSD simply truncates everything > 72 byte and so does reddit.

I've seen some SO answers which suggest hashing the password with SHA first which could make sense as passwords are usually ASCII sprinkled with a bit of UTF-8 so the entropy is never truly len(password) but lower. However, this feels like trying to outsmart something that isn't really broken so I'm not sure it's a good idea.