On Wed, 2006-01-04 at 10:00 +0100, Olle E Johansson wrote: > Tomislav Parcina wrote: > > I have * server that has public IP. Some users with their softphones > > (and other with hardphones) need to connect to that * server and call > > out thrue Zap lines. As far as I know when someone tries to authenticate > > to * server using SIP protocol, he sends data in plain text format. > > Right? How can I protect * server from snifers? > > > > I would like to use SJphone softphone for above purpose. > > > > > > All SIp authentications are done with MD5 basic digest, not with plain > text auth. Plain text auth was remove from SIP a long time ago.
[long, contains dry math, boring addition follows] to add to this, given the state of MD5 and its 'security' or lack thereof, its a bit over simplistic to just say md5 without adding that its actually 3 md5 hashes... Precomputing is harder (but not impossible) because of the way its done. The nonce makes it a little harder - although the nonce is known even by an attacker ... basically its AUTH1 = md5(username:sip.proxy.com:password) AUTH2 = md5(REGISTER:$URI) final = md5($AUTH1:$NONCE:$AUTH2) AUTH2 is fairly easy to precompute, AUTH1 would change with each attempted password. MD5 has collissions more readily available than advertised. A collission is where two strings result in the same hash ie md5(string1) == md5(string2). this means that it is *possible* (but unlikely under normal circumstances) for someone to guess a 2nd password that would evaluate to the same AUTH1. It would be far more likely that someone would just try to brute force (rainbow tables are not likely to be helpful in this example) the password. MD5 is a fairly fast algorithm, however the fact that it would take effectivly 2 md5 hashes computed you have slowed them down. Zombie machines could be used to speed this up, and it is possible that using MD5 for sip auth it could be brute forced, the probative value of a single account is not likely to justify such an attack. A specific account might, it depends ... Choosing strong passwords helps in this regards (forces the brute force algorithm to be really brute force instead of just a dictionary attack). I would suggest longer passwords, every additional character adds to the overall strength, and basically makes it take longer to exhaust the keyspace. I would also suggest assigned passwords. With sip you set and forget, so users dont need to know what their password really is. If you have 96 characters valid for each position and the password is 8 characters that is 96 to the 8th power, if you goto 14 character passwords (assuming the auth system supports it) you have 96 to the 14th power. A much larger space to attempt to brute force. If you drop the valid chars down to [a-z][A-Z][0-9] omiting all the other common chars on a keyboard at 14 chars you would still be looking at 62^^14 a daunting number. A pc should be able to go through all of those combinations in approx 4,000,000,000,000 years. An exhaustive search of that would be impossible, even though statistically over time on multiple accounts you will do it on average in half that time. Even with a million node zombie network it would still take way longer than the account would be valid for. Now if users get to pick passwords that can be cut dramatically becuase a user sometime is going to use a dictionary based password. With a large enough dictionary and enough zombies an account could in theory be cracked every day. HOWEVER this implies that the attacker could *also* sniff the SIP data to the server. This may be easier than you think, there are a lot of colo facilities and NAPs where people colo systems that dont do good network security simply because it costs money (the routers, switches, etc cant process as much data because they are busy doing the extra compares - NAPs generally are worse about this than colo data centers but YMMV). So the fault in how the attacker is getting the data may not even be yours, but none-the-less they can sniff. If that happens *and* if they have a large enough zombie network *and* they care enough to do this *and* you have weak passwords on your system then there is a potential problem. I think it more likely they would attempt to break into the system that is doing this itself rather than via sniffing SIP auth messages. Side note: doesnt the IAX protocol allow an AUTH request to be sent with no username and will match against all accounts for the supplied password? And if no password is given as well it matches against any user with no password (giving weight to a user named 'guest')? That would seem a far more likely attack than sniffing SIP headers. -- Trixter http://www.0xdecafbad.com Bret McDanel UK +44 870 340 4605 Germany +49 801 777 555 3402 US +1 360 207 0479 or +1 516 687 5200 FreeWorldDialup: 635378 http://www.sacaug.org/ Sacramento Asterisk Users Group
signature.asc
Description: This is a digitally signed message part
_______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
