Does pre-authentication help against "insider" attacks?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Does pre-authentication help against "insider" attacks?

Adam Lewenberg
I am trying to understand the security benefits of requiring
pre-authentication.

Consider this scenario: an attacker is trying to learn the password for
a service account, e.g., the principal used by the ssh service on some
server. The attacker already has the credentials for a user's account
(but not, of course, the service account he is attacking). The attacker
requests a service ticket for the account he is attacking. The attacker
then uses brute force (offline) to derive the service account's password.

In the context where the attacker *already* has an account, requiring
pre-authentication does not help mitigate against this sort of attack.In
other words, pre-authentication helps against attacks from "outsiders"
but not from existing users.

Is this correct?

Thanks, Adam Lewenberg


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Does pre-authentication help against "insider" attacks?

Jeffrey Altman-2
On 5/26/2017 11:08 AM, Adam Lewenberg wrote:

> I am trying to understand the security benefits of requiring
> pre-authentication.
>
> Consider this scenario: an attacker is trying to learn the password for
> a service account, e.g., the principal used by the ssh service on some
> server. The attacker already has the credentials for a user's account
> (but not, of course, the service account he is attacking). The attacker
> requests a service ticket for the account he is attacking. The attacker
> then uses brute force (offline) to derive the service account's password.
>
> In the context where the attacker *already* has an account, requiring
> pre-authentication does not help mitigate against this sort of attack.In
> other words, pre-authentication helps against attacks from "outsiders"
> but not from existing users.
>
> Is this correct?
>
> Thanks, Adam Lewenberg
Pre-authentication reduces the risk of brute force attacks against user
principals by requiring proof that the requester knows the long term
secret before issuing a response encrypted by that long term secret.
Pre-authentication plays no role in preventing brute force attacks
against encrypted service tickets.

Once an authenticated user has obtained a service ticket from the KDC
they are free to do with it what they will including attempts at
brute-forcing the service's key.  That is why it is so important to
cease using weak encryption types for service keys including cross-realm
services.

Jeffrey Altman



smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Does pre-authentication help against "insider" attacks?

Russ Allbery-2
In reply to this post by Adam Lewenberg
Adam Lewenberg <[hidden email]> writes:

> I am trying to understand the security benefits of requiring
> pre-authentication.

> Consider this scenario: an attacker is trying to learn the password for
> a service account, e.g., the principal used by the ssh service on some
> server. The attacker already has the credentials for a user's account
> (but not, of course, the service account he is attacking). The attacker
> requests a service ticket for the account he is attacking. The attacker
> then uses brute force (offline) to derive the service account's
> password.

> In the context where the attacker *already* has an account, requiring
> pre-authentication does not help mitigate against this sort of attack.In
> other words, pre-authentication helps against attacks from "outsiders"
> but not from existing users.

Assuming the attack is on a principal for which one can obtain service
tickets, I believe this is correct.  (This is one of the reasons why you
should disable service tickets for user accounts unless you have a
specific need for user-to-user authentication.)

The primary defense against this attack for service accounts is that
service accounts should always have a randomly-generated key, not a
password, so brute force attacks on a service ticket to recover that key
are infeasible (they're equivalent to a brute-force search of the entire
key space, which should be large enough to make this impractical).

Pre-authentication is primarily there to protect weak keys, such as any
keys derived from a password.

--
Russ Allbery ([hidden email])              <http://www.eyrie.org/~eagle/>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Does pre-authentication help against "insider" attacks?

Viktor Dukhovni-2
In reply to this post by Jeffrey Altman-2

> On May 26, 2017, at 11:35 AM, Jeffrey Altman <[hidden email]> wrote:
>
> Pre-authentication reduces the risk of brute force attacks against user
> principals by requiring proof that the requester knows the long term
> secret before issuing a response encrypted by that long term secret.
> Pre-authentication plays no role in preventing brute force attacks
> against encrypted service tickets.
>
> Once an authenticated user has obtained a service ticket from the KDC
> they are free to do with it what they will including attempts at
> brute-forcing the service's key.  That is why it is so important to
> cease using weak encryption types for service keys including cross-realm
> services.

And in particular, "service accounts" (service principals) generally have
random keys generated by cryptographically strong PRNG.  They are typically
(on Unix systems) not and should not be "password based".

Now it is true that in Active Directory various services (SPNs)
require domain a password for their domain account (there are
no "keytab" files on Windows).  It is up to the domain administrator
to configure strong random passwords for such accounts.

--
        Viktor.



--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Does pre-authentication help against "insider" attacks?

Henry B (Hank) Hotz, CISSP-2

> On May 26, 2017, at 11:44 AM, Viktor Dukhovni <[hidden email]> wrote:
>
> And in particular, "service accounts" (service principals) generally have
> random keys generated by cryptographically strong PRNG.  They are typically
> (on Unix systems) not and should not be "password based".
>
> Now it is true that in Active Directory various services (SPNs)
> require domain a password for their domain account (there are
> no "keytab" files on Windows).  It is up to the domain administrator
> to configure strong random passwords for such accounts.
>
> --
> Viktor.

In Heimdal that’s kadmin add —random-key . . .  Don’t use kadmin add —random-password unless the (small) number of characters is OK for your application.

In MIT it’s kadmin addprinc -randkey.

Now for my question: In Windows it looks like you should be able to do something similar with “ktpass /pass +rndpass . . .”, but I’ve never been able to get that command accepted. Under what conditions does that option work?


Personal email.  [hidden email]



Loading...