Re: Avoiding Pre-Auth/Auth Principal State Disclosure
Robbie Harwood <[email protected]>
| Newsgroups | gmane.comp.encryption.kerberos.general |
|---|---|
| Message-ID | <[email protected]> |
Chris Hecker <[email protected]> writes: > On Tue, Jun 30, 2020 at 23:01 Eric Hattemer <[email protected]> wrote: > >> If you run a client like kinit and ask for a principal with >> REQUIRES_PRE_AUTH and a disabled/pw_expired/locked-out state, or >> request a principal that doesn't exist, you aren't asked for a >> password and get an immediate response with the status of the >> account. Is there a way to avoid this behavior? People have created >> hacking toolkits that try every possible username to download the >> list of usernames in the database and their state. >> >> I know pre-auth is a special case where you'd need to provide a >> plausible challenge for non-existent accounts. But is there maybe a >> setting to treat unknown principals as if they had pre-auth disabled, >> request a password, and just send back invalid password / encryption >> failed no matter what? >> >> We were trying to implement an authentication proxy module that uses >> Kerberos, and we wanted to only disclose an account was disabled if >> the user typed in the correct password. But the only case we could >> make work was if the account was expired (different from pw_expired). > > There are actually a bunch of places that leak information about valid > princs, I wonder if there’s a todo item to clean those up at some > point? I can’t remember the one or two I found since it was a while > ago but I posted it to the list as well. In my opinion, it's not generally a good idea to consider usernames private information. Typically they're predictable and should pale in comparison to password strength anyway. I'd additionally suggest turning on preauth for all user principals. Thanks, --Robbie ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
signature.asc
(application/pgp-signature, 832 B)
-----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAl781PQACgkQJTL5F2qV pEKi+xAAwk943legfZsDxlQ2qprW+rrcXnu78DgvfxSoIzLmRA1Is+GbqE3981fI qWOt1xn0tsFzsSi1el06n2E9ouvyRH6ueQlx6u/y4FCfKallAAQxRdZ2Pj1PhDHo OU3FtHrdqD6J94OXm+4EF0unakbEIQ7VLg/aITZobzPrd+ZanUILjmoLgmExGr2e pOsumnvRf2nLbIg0hs62pUij+deBZmZRwwizN7mjveF8LE3QijXBmK6L+n/em4aH AAZ957obz9iwb1WHyKnPpm0VBOyfnkrfPeGst4BVAK7ULdeBMveFNyFp0qdEke1/ XL2jlkEKZqvE+L6GxxRKwU4d1yWrQX+i7dYt1VYAj4bHwsrlC3+O3j5BdG5G7KAr DOU24QHUv4+7KRXMdGV6juG0Z0L3t5W/a3kGjTt/dnD+KKfB+tUJCA6KkXoObLwK /s4LQ78rZb/RwFynBFJW6g1ABZfurZCB2U4S59EFh4t//uWmejXinw5bkqEZLCnw KH6n/DFBypeysY7nDzf6tHlzXRHoVG0uzdphLVrI6IFtEMakCE+c+b1fmrfbgXtA sQ+U5PzcezIPbqpcdxRrNH7kopuHV6hXYf3c8takzNqRg9JFIbTlURDBBPvKrezm cRJOYzmocVuWdMBnS3/hCLwFZHHlo2OEUYa/qQvT0rc0z1EGr+g= =svdU -----END PGP SIGNATURE-----