3

My SIP provider stores my SIP call time password as AES encrypted in stead of hashed. I understand that SIP authentication has the capability to NOT store the password, and in stead store a pre-calculated hash 'string1'. 

string HA1=MD5(username:realm:password)

and then during authentication calculate. 

HA2=MD5(method:digestURI)

response=MD5(HA1:nonce:HA2)

See Digest access authentication

The provider, however, says that some clients make it impossible to calculate string HA1 because the realm value changes.

  • Is it indeed common practice to store a SIP call time password encrypted?
  • I thought that the SIP server determines the realm. Are there indeed SIP-server setups that cannot predict/determine the realm for call time later on?
Dick99999
  • 525
  • 5
  • 8

1 Answers1

1

Usually you have a constant realm and in this case HA1=MD5(username:realm:password) could be stored instead of the password. But, if the password is only used for the SIP account, it actually does not matter if within a attack against the provider username and password get seized or HA1 instead, because the latter is all it needs to authenticate as the user. The storage method only matters if the account is used for other things or if the password is used for other accounts.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Aren't you mixing up client and server? HA1 is send by the SIP server, though hashed again. It does not authenticate the client, I thought. – Dick99999 Nov 22 '14 at 13:14
  • If you look at how the client constructs the response you will see that username and password are only used within `MD5(username:realm:password)`. Thus knowledge of this hash is enough to authenticate itself. Therefore it does not matter if an attacker captures username and password or instead `MD5(username:realm:password)` – Steffen Ullrich Nov 22 '14 at 13:44
  • Agree that HA1=MD5(username:realm:password) is being used/constructed by both the client and the server. However, that MD5 hash is is never transmitted over the Internet. Both client and server respond by an MD5 hash of a string that contains HA1 also. Your comment though, does proof that hacking the response might take one MD5 round less than one would expect after a brief inspection of the protocol. And I think my original questions still stand. – Dick99999 Nov 22 '14 at 17:54
  • 2
    Your problem is that the provider does encrypt the password instead of storing HA1. What I argue is that it does not matter if the attacker seizes username+password or HA1 when attacking the provider, because both data are sufficient to authenticate as the user. I did not mean attacks against the transport, but attacks against the provider. – Steffen Ullrich Nov 22 '14 at 18:20
  • Ah, yes, I misunderstood that you are comparing attacking the provider in stead of capturing SIP packets. Thinking along that line, I would argue that encrypting the password is the better approach for SIP, though it does introduce the question asked a few times on this forum: how do you store an encryption key securely that an application uses automatically. – Dick99999 Nov 22 '14 at 18:31