[VOIPSEC] FWD - Hotel and Wfi Insecurity, including SIP

[Robert Moskowitz]

At 02:30 PM 11/21/2005, Jon Callas wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>On 21 Nov 2005, at 6:07 AM, Philip Walenta wrote:
>
> > I never meant to imply that the digest SIP uses was insecure,
> > merely that by
> > doing a little social engineering, it can be broken like many other
> > passwords due to user habits.
> >
> > Will there ever be something "totally unbreakable"?  Possibly, but
> > not in
> > our lifetimes IMHO.  As CPU speed increases, brute-force becomes
> > easier to
> > do.
> >
>
>Yes, but there are ways to deal with that. For example, you can salt
>the hash function, which makes dictionary searches harder. You can
>also iterate the hash function so that you slow down the search speed.
>
>Look at section 3.6 of <http://www.ietf.org/rfc/rfc2440.txt> and
>you'll see all of these things. In the "iterated and salted string-to-
>key specifier" you can specify along with your password how much to
>iterate. This means you can actually redo someone's password
>dynamically to compensate for increasing CPU speeds.

This is what is done for WPA-PSK.  I wrote the attack up back in 
10/03; as no supprise of my colleagues working with me on 802.11i.

Since then the attack has been added to a number of WiFi attack 
tools, yielding a number of PSK secrets.

Of course the seed is very important.  When the SSID is LINKSYS, the 
attacker has a headstart!  But don't think that 'hidding the SSID' 
helps as I have also written how to disclose 'hidden' SSIDs and this 
has been added to the tools.

ANY authentication method based on a challenge/response without a 
changing secret between the parties, is open to attack.  And users do 
not use good passwords.

We will never see technologies like SRP used, too many patents (SPEKE 
being the prevalent one).

Oh, one thing I forgot to mention about challenge/response with 
two-factor authentication.  Rarely do they authenticate the server to 
the client.  This allows for a MITM attack against that session (MITM 
lies that the authentication is good).  What good is this?  It 
varies, but it can be bad.

If you want secure authentication you go to a public key method where 
the public keys are authenticated to the parties (hey, did I just 
move the problem elsewhere :) ).

Long day....


Robert Moskowitz
Senior Technical Director
ICSA Labs, a division of Cybertrust, Inc.
W:      248-968-9809
F:      248-968-2824
VoIP:   248-291-0713
E:      rgm at icsalabs.com

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit