[16625] in Kerberos-V5-bugs
Re: [krbdev.mit.edu #8949] Provide Means to Prevent a User Changing
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Thu Sep 17 07:53:37 2020
From: "=?UTF-8?B?w5DClMOQwrjDkMK7w5HCj8OQwr0gw5DCn8OQwrDDkMK7w5DCsMORwoPDkMK3?=
=?UTF-8?B?w5DCvsOQwrI=?= via RT" <rt@krbdev.mit.edu>
In-Reply-To: <51ea1f29e3fcafbbf4853cc11e58eb8e19da2c3d.camel@aegee.org>
Message-ID: <rt-4.4.4-99654-1600343608-584.8949-5-0@mit.edu>
To: "AdminCc of krbdev.mit.edu Ticket #8949":;
Date: Thu, 17 Sep 2020 07:53:28 -0400
MIME-Version: 1.0
Reply-To: rt@krbdev.mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krb5-bugs-bounces@mit.edu
Content-Transfer-Encoding: 8bit
<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.
>
>
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
