RestComm / Restcomm-Connect

The Open Source Cloud Communications Platform
http://www.restcomm.com/
GNU Affero General Public License v3.0
245 stars 215 forks source link

Save encrypted/encoded client security code #1372

Open maria-farooq opened 8 years ago

maria-farooq commented 8 years ago

Save client security code in encrypted/encoded form

deruelle commented 8 years ago

Check also for accounts password. We shouldn't be using MD5 either but at least SHA 512 or better something encrypted. SHA-512 isn't designed to be hard to brute-force. Better hashing algorithms like BCrypt, PBKDF2 or SCrypt should be used

otsakir commented 8 years ago

@deruelle , @maria-farooq , agreed for strong hashing. We could also introduce some sort of salting (include a client fixed property in the the hash generation) so that it's not easy to reach any conclusions by comparing two clients with the same (hashed) password.

Also, i'm wondering whether it makes sense to return the client password when retrieving the Client and it seems to me it doesn't. If the knowledge of the hash doesn't really provide access, there is not much to do with it.

On the contrary, if the hashed value can be used as it is to directly access the platform, it seems this is no more secure than dumping this hashing thing altogether and using plaintext both in storage and credentials data.

The idea of storing password in hashed version aims to minimize the breach if the stored passwords are revealed. If they were stored in plaintext, a hacker that could somehow get access to them could then use them to access the platform.

Thoughts ?

deruelle commented 8 years ago

@otsakir

  1. No the hashed value for the password shouldn't give access directly to the platform.
  2. We need to experiment with salting and various hash generation mechanisms, especially we need to test if this won't break the connection with restcomm SDKs which may be using MD5 hashing as per SIP Spec RFC3261 recommendations. So if we use something different than MD5 we need to investigate the impact on integration with SDKs and SIP Clients (jitsi, linphone, zoiper, ...) while registering.
gvagenas commented 8 years ago
  1. Deny challenge register when algorithm is null - https://github.com/RestComm/Restcomm-Connect/blob/1f5637cb21dfba9d324188dfab4ba5482fd36c08/restcomm/restcomm.commons/src/main/java/org/restcomm/connect/commons/util/DigestAuthentication.java#L38-L38
  2. Store in the DB the MD5 hash of (user + ":" + realm + ":" + password) . Ream is the RestcommConfiguration.getInstance().getMain().getHostname() (restcomm.xml)
  3. Modify A1 method https://github.com/RestComm/Restcomm-Connect/blob/1f5637cb21dfba9d324188dfab4ba5482fd36c08/restcomm/restcomm.commons/src/main/java/org/restcomm/connect/commons/util/DigestAuthentication.java#L44-L44 to use the stored hashed key instead of generate it again

This way we avoid storing clear text