[asterisk-users] How to stop intruder from registering sip?

[Dave Platt]

> That would only be true if you used random characters in your 17-character
> passphrase.  In fact, English text has somewhere between 0.6 and 1.5 bits of
> randomness per letter, whereas an SHA1sum has no more than 4 bits of
> randomness per letter.  Let's assume the higher number of randomness for
> your English text, which gives us 1.5 * 17, which is 25.5 bits of randomness.
> Note that the prefix 3 characters have ZERO randomness per character, as they
> are deterministic from the extension.  That gives an even less 21 bits of
> randomness.  SHA1 cryptographic sums have no more than 160 bits of randomness.
> 
> I say "no more than", because, given knowledge of the algorithm used to
> determine passwords, the sum is reduced to the number of bits of randomness in
> the source material.  You cannot generate randomness by applying a
> deterministic algorithm.  However, given that the source material for the hash
> sum is of a smaller bit strength than the comparative strength of the hash
> algorithm, your difficulty of guessing the password is not reduced any by
> using the hash algorithm for generative purposes.

Agreed, on all points.

Any deterministic method of this sort (e.g. hashing together the
extension name with a constant-per-site salt) is vulnerable to a
brute-force guessing attack against the salt.  If the person who
set it up used a ordinary, easily-remembered phrase as the salt,
then the security of *all* of the secrets is tied to the guessability
of this phrase.  Brute-force dictionary attacks against plain-language
words and phrases have been quite successful in the past... I've heard
it said that on any multi-user system having more than a handful of
users, the odds of one of those users having a guessable password
are often 50% or better.

I'm not in favor of using this sort of deterministic scheme
(e.g. HASH(salt + public info)) for determining per-station
secrets, no matter which hash algorithm is used.  Instead, I
recommend the scheme I originally proposed - use a random-
number generator (or a cryptographically-string pseudorandom
generator, fed with some entropy from an external unpredictable
source) to generate individual secrets.  I make three arguments:

-  The resulting secrets (i.e. strings of hexadecimal digits)
   are equally hard, or equally easy, for the end-users to deal with
   (assuming that we're talking about equal numbers of digits).  Neither
   scheme has an advantage here.

-  Once set up, both systems are equally easy to use and administer...
   press a button and generate a secret.

-  The random- or pseudo-random method produces secrets which don't
   depend at all on the extension numbers (or user names, or other
   public information), are independent from one another, and are
   essentially immune to dictionary and other guessing attacks.  The
   only way to break them is via a full brute-force search... and
   successfully finding one extension's secret by brute-force search
   doesn't help you at all in finding any other extension's.  Assuming
   a good random-number generator, the amount of entropy (randomness)
   in the secrets is essentially equal to (2 ^ number-of-bits).

   None of these things is true of a deterministic-hashing scheme...
   if the salt can be guessed or determined, *every* extension's secret
   has been broken, and you have to immediately change *every* configuration
   in order to secure your system.  Salts based on dictionary words and
   phrases have far less randomness in them than their length would
   imply, and that means that the resulting secrets are less random...
   generating longer "secret" strings doesn't fix this, and can simply
   give a false sense of security.




-