NIST SP 800-63-3B sets a recommendation to have password length upper bound limited in A.2:
https://pages.nist.gov/800-63-3/sp800-63b.html#appA
Users should be encouraged to make their passwords as lengthy as they
want, within reason. Since the size of a hashed password is independent
of its length, there is no reason not to permit the use of lengthy
passwords (or pass phrases) if the user wishes. Extremely long passwords
(perhaps megabytes in length) could conceivably require excessive
processing time to hash, so it is reasonable to have some limit.
FreeIPA already applied 256 characters limit for non-random passwords
set through ipa-getkeytab tool. The limit was not, however, enforced in
other places.
MIT Kerberos limits the length of the password to 1024 characters in its
tools. However, these tools (kpasswd and 'cpw' command of kadmin) do not
differentiate between a password larger than 1024 and a password of 1024
characters. As a result, longer passwords are silently cut off.
To prevent silent cut off for user passwords, use limit of 1000
characters.
Thus, this patch enforces common limit of 1000 characters everywhere:
- LDAP-based password changes
- LDAP password change control
- LDAP ADD and MOD operations on clear-text userPassword
- Keytab setting with ipa-getkeytab
- Kerberos password setting and changing
Fixes: https://pagure.io/freeipa/issue/8268
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-by: Simo Sorce <ssorce@redhat.com>
Reviewed-By: Simo Sorce <ssorce@redhat.com>
ber_scanf expects a pointer to a ber_tag_t to return the tag pointed at
by "t", if that is not provided the pointer will be store in whatever
memory location is pointed by the stack at that time causeing a crash.
Note that this is effectively unused code because in ipa-kdb the only
party that can write a key_data structure to be stored is te kdb_driver
itself and we never encode these s2kparam data.
But we need to handle this for future proofing.
Fixes#8071
Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Before krb5 1.13 the krb5_salttype_to_string() function was returning
incorrect names (display names of some kind instead of the names
used by the rest of the library to map saltname to the salt type
integer number).
This patch adds a function that checks at runtime if we have a working
function and uses a fallback map updated to the salt types known up
to 1.12, this allows us to use the library provided function in
following releases where new salt types may emerge.
Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-by: Milan Kubik <mkubik@redhat.com>
When kadmin tries to change a password it will get the allowed keysalts
from the password policy. Failure to provide them will result in kadmin
using the defaults specified in the kdc.conf file or hardcoded defaults
(the default salt is then of type NORMAL).
This patch provides the supported values that have been read out of the
appropriate LDAP attribute when we read the server configuration.
Then at actual password change, check if kadmin is handing us back the exact
list of supported encsalts we sent it, and in that case replace it with the
real default encsalts.
Fixes https://fedorahosted.org/freeipa/ticket/4914
Signed-off-by: Simo Sorce <simo@redhat.com>
Reviewed-by: Martin Babinsky <mbabinsk@redhat.com>
This new extended operation is tried by default and then the code falls
back to the old method if it fails. The new method allows for server
side password generation as well as retrieval of existing credentials
w/o causing regeneration of keys on the server.
Resolves:
https://fedorahosted.org/freeipa/ticket/3859
Reviewed-By: Nathaniel McCallum <npmccallum@redhat.com>
Make it available outside of the encoding.c file for use in a follow-up
patch. Add option to not pass a password and generate a random key
instead.
Related:
https://fedorahosted.org/freeipa/ticket/3859
Reviewed-By: Nathaniel McCallum <npmccallum@redhat.com>
This moves the decoding function that reads the keys from the ber format
into a structure in the common krb5 util code right below the function
that encodes the same data structure into a ber format.
This way the 2 functions are in the same place and can be both used by
all ia components.
Don't use KRB5_PRIVATE.
The patch implements and uses the following krb5 functions that are
otherwise private in recent MIT Kerberos releases:
* krb5_principal2salt_norealm
* krb5_free_ktypes
Signed-off-by: Simo Sorce <ssorce@redhat.com>
