Skip Menu |
 

Date: Wed, 09 Sep 2020 11:00:15 +0300
From: "Дилян Палаузов" <dilyan.palauzov@aegee.org>
To: "krb5-bugs" <krb5-bugs@mit.edu>
Subject: Provide Means to Prevent a User Changing its Password
Hello,

I want to provide a service for many users, that can be used over
Kerberos. Users shall be able to change their passwords over the
kpasswd-protocol or using a website.

For demonstration purposes, I want to provide a user with public
password, where anybody can try the service, using that
username/password, before creating a private username/password. I do
not want, that the the public password can be changed over the kpasswd-
protocol.

Please add some means to achieve this, e.g. by a new attribute to the
principals.

Regards
Дилян
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.
 
From: "Дилян Палаузов" <dilyan.palauzov@aegee.org>
Subject: Re: [krbdev.mit.edu #8949] Provide Means to Prevent a User Changing its Password
Date: Thu, 17 Sep 2020 14:53:19 +0300
To: rt@krbdev.mit.edu
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 написа:
Show quoted text
> 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.
>
>