-
Notifications
You must be signed in to change notification settings - Fork 151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mechanism table update (for now, doc only proposal) #602
base: master
Are you sure you want to change the base?
Conversation
- It's not about encryption anymore in SASL - Barely any mechanisms actually provide encryption
- Set to 10 for all that only depend on password quality - Set to 50 for SCRAM, which imposes a lot of work on brute force - Perhaps need to distinguish salting, rainbow tables in a column? - Much of this is subjective and could lead to long discussion - The old values had many flaws associated with them - The idea is mostly to get *closer* to the reality of today
This may lead to some discussion, once the storm settles let me know and I can dive into the code to update SSF there too. |
Please update your commit(s) to be signed off on in accordance with our DCO. Thanks! |
I'm not sure what you are asking, or what "our DCO" means. |
Developer Certificate of Origin: https://developercertificate.org/ Generally, you need to add a "signed off" field to your commit (git commit -s --amend is generally sufficient) and then re-push your commit. |
Reminder that this still needs sign off in accordance with the dco to be considered. |
In a few steps, I've revised the table of authentication mechanisms. This table was long overdue for such an update, I think.
I added columns for Post Quantum protection (which is not an issue for authentication until Quantum Computers actually arrive, unlike for encryption, but systems change slowly so this is a useful aspect to document).
I added a column for the current state according to the IANA registry of SASL mechanism names.
I could not find anything on G2, and am wondering if it might be a misspelled GS2 name?
I have removed the remark about encryption from MAX SSF, as this is not considered of value in SASL anymore; it is mostly about authentication not encryption. I updated the description to reference brute-force search space instead, and added a value for low password quality and many-rounds effort on low password quality. The term MAX SSF might suggest that the password quality can be 128 bit, however, which is one of many ways in which the whole MAX SSF notion is confusing and perhaps disinformation.
I edited the MAX SSF column, and am well aware that it is subjective. Still, it did not reflect reality at all -- Kerberos5 has long deprecated DES, EXTERNAL is usually based on strong crypto, and so on.
I tried to make separately rejectable/acceptable commits out of this. Please use that when you (dis)agree with (parts of) this proposal. Any of these updates would improve the table, IMHO.