[krbdev.mit.edu #8949] Provide Means to Prevent a User Changing its Password

Дилян Палаузов via RT rt at krbdev.mit.edu
Thu Sep 17 07:53:28 EDT 2020


<URL: https://krbdev.mit.edu/rt/Ticket/Display.html?id=8949 >

Hello,

thanks for your answer.  Eventually I changed
the kadm5_chpass_principal_3() function as shown below.

The disadvantage of the SPAKE preauthentication for realms exposed over
internet is, that for some accounts there are constants experiments to
guess the password from around the globe.  Eventually, the accounts get
locked, if the guesses failed.

Instead I tunnel everything over TLS and enforce password change every
three months.

Regards
  Dilyan

--- src/lib/kadm5/srv/svr_principal.c.orig	2020-09-16
23:51:48.892495992 +0300
+++ src/lib/kadm5/srv/svr_principal.c	2020-09-17 00:02:56.700937586
+0300
@@ -1347,6 +1347,7 @@
     krb5_kvno                   act_kvno, hist_kvno;
     int                         new_n_ks_tuple = 0;
     krb5_key_salt_tuple         *new_ks_tuple = NULL;
+    char                        *principal_str;
 
     CHECK_HANDLE(server_handle);
 
@@ -1361,6 +1362,13 @@
                                 principal, hist_princ)) == TRUE)
         return KADM5_PROTECT_PRINCIPAL;
 
+    krb5_unparse_name(handle->context, principal, &principal_str);
+    if (strncmp(principal_str, "aaa@", 4) == 0) {
+        krb5_free_unparsed_name(handle->context, principal_str);
+        return KADM5_PROTECT_PRINCIPAL;
+    }
+    krb5_free_unparsed_name(handle->context, principal_str);
+
     if ((ret = kdb_get_entry(handle, principal, &kdb, &adb)))
         return(ret);
 

В 18:37 -0400 на 16.09.2020 (ср), Greg Hudson via RT написа:
> Note that every user of the demo account will be able to decrypt
> every other
> users' communications, unless SPAKE preauth is used (and even then an
> MITM
> attack is likely possible).
> 
> I believe this use case is currently possible in three suboptimal
> ways, the
> first of which is probably easiest:
> 
> 1. Set a long min_life on the principal.
> 
> 2. Provide a password quality plugin module which always fails the
> quality
> check for this principal.
> 
> 3. Disable the "self" kadm5_auth module, and instead provide a new
> module which
> enables self-service for every principal but this one.
> 
> 




More information about the krb5-bugs mailing list