The thing i would add to this is that in most cases, you need to manually provide config values to the install.
This sounds okay in principle, but I far too often end up needing to look through the template files (what helm deploys) to understand what a config option actually does since documentation is hit or miss.
Exactly why we use it. Our java devs have been able to pickup and start writing kotlin. None of them have regretted it that I've seen.
It's extremely close to Java in terms of most concepts. That makes it an easy language to switch into and out of. It's java with a nicer syntax and more sugar.
Actually it can be trivial as long as you can require the user to re-type the current password when entering a new password; check hash first, then check edit distance with the entered "current password" (and, of course, promptly throw it away once you know the edit distance.)
It does more than that, it keeps a hashed password history (which used to be in the user attr ntPasswdHistory, but is now "somewhere secret" afaik) according to the value of ms-DS-Password-History-Length attribute. OpenLDAP keeps these (ppolicy overlay) in the user object.
So, it can hash any proposed password and compare the history to make it's not been seen $recently (as an exact match, since it's comparing hashes).
It could also perform some minor permutations of any new password, and do the same history check to make sure you're not just changing the first or last character or digit. I don't know if it does this, but it could.
You don't really need to convince people who implement it. You need to convince people creating certification/law, so PCI/SOC2/whatever. I'm still posting every time something like "for the record, I know we have to legally do this, but it's pointless and actually makes us less secure" for a few things.
If the analogy is a personal asistant, a good assistant will know when to notify you and when not to.
reply