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

[Henry B (Hank) Hotz, CISSP]

> On May 26, 2017, at 11:44 AM, Viktor Dukhovni  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.  hbh...@oxy.edu

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

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

[Viktor Dukhovni]

> On May 26, 2017, at 11:35 AM, Jeffrey Altman  
> 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.

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

[Russ Allbery]

Adam Lewenberg  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 (ea...@eyrie.org)  

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

[Jeffrey Altman]

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
Description: S/MIME Cryptographic Signature