New for Sugar 6.5 – Stronger password storage encryption

sugarcrmdevelopers —  May 16, 2012 — 19 Comments

Sugar uses MD5 encryption for storing password data in the backend database. This works fairly well, as MD5 is a well understood algorithm and is implemented in just about every programming language, as well as on the database side as well. There’s just one issue, MD5 isn’t the most secure algorithm out there.

So starting with Sugar 6.5, we are using PHP crypt on top of this to store each password as a hashed string. This provides greater security for the passwords stored in the database. It also brings up some questions on administration, so here’s the most common ones and the answers to them…

How do I move over from MD5 password storage to the new crypted storage?

This will happen transparently when you a user’s password is changed, and is not done during the upgrade process. If you want to move over all of your passwords to the new crypt storage, the best bet is to use the password management feature to expire everyone’s password after a period of time, which will force them to change their password and move to the new crypt storage

Can I still use MD5 passwords? I’m used to that and can easily administer passwords in the database using just MD5.

Sugar will still recognize passwords stored in MD5 format, but anytime a password is changed it will convert to the newer format. Unless very old PHP build (5.2) used in a system where better
crypt() is not available, new password will use salted hashing algorithm.

How will I know a user has converted over to the new crypted passwords?

Crypted passwords will be stored in the database prefixed by a dollar sign ($)

Can I update the passwords to store them in a new format outside of Sugar?

Yes, you can use the same method we do for this:


crypt(md5("newpassword"))

There are similar libraries available for other languages as well, such as passlib for Python, which should work as well.

19 responses to New for Sugar 6.5 – Stronger password storage encryption

  1. 
    Markus Ziegler May 16, 2012 at 7:36 am

    Do I have to change my programs that call the webservice API of sugar to use the crypt function instead of sending the md5 password hash?

  2. 

    Like Markus we are keen to know if you will gracefully handle web service calls using the md5sum until such time as the main SugarCRM application forces crypt.

    It will be a royal PITA if we have to send 2 logins every time.

    If crypt is enforced in say 6.6, at least we’d know to send the correct password string by first doing the get_server_info call.

    Thanks,

    Jon

  3. 

    For sending a password to Sugar for the purposes of Web Services authentication, nothing will change.

  4. 

    My plugin grabs the user_hash directly from the database and then uses this hash when logging in via SOAP api.  This used to work since it was hashed in md5.  As of 6.5, I get incorrect username and password errors.

    Anyway to make the SOAP Login method accept the crypt hash from database?

    I’m still using the legacy soap.php

    • 

      Without hacking core files, there isn’t a way. Just out of curosity, why do you do this?

      • 

        I have a background task which runs that maintains a constant socket connection with Asterisk to receive events (unfortunately can’t get asterisk to post events to us… we have to maintain a socket to get events).

        The way that task communicates with Sugar is through SOAP.  It basically just needs to create Call Records.  
        Since I’m on the same box though, rather then make the user provide a Sugar Username + Password.  We just make them provide the Username and we pull the password hash out of the database.  Overall there is less to maintain that way.

        • 

          In Sugar 6.6 there will be oAuth in order to do this, which will be much cleaner. In the meantime, you will unfortunately need to have the user re-enter their password.

      • 

        John,  would it be that hard for them to check if incoming password has a $ at the beginning and if so not add the crypt the md5 hash they get in through the services?  

        I thought about adding the password field to my configuration but then it’ll end up getting displayed in plaintext in the config.ini and worse in the administration panel inside sugar.

  5. 

    There is no salt?
    crypt(md5(“newpassword”))
    Where can we set the salt manually?

  6. 

    i have try this query with success to check if mypassword is valid.
    select user_name,user_hash from users

    where user_name=’myname’

    and sugar_login=1

    and encrypt(lower(md5(‘mypassword’)),user_hash)=user_hash

    and substr(user_hash,1,1)=’$’;

  7. 

    We upgraded from SugarCRM Enterprise 6.4.1 to 6.5.10 and discovered that newly entered or reset passwords did not work. After much head-scratching we realized that the new crypt() passwords exceed the old MD5 32-character length and were being truncated by the database. Changing the users.user_hash column from varchar(32) to varchar(64) fixed it.

  8. 
    gdanielrobinson May 9, 2017 at 7:21 pm

    I have been rebuilding a system the uses sugarcrm to log users in to wordpress, this has kept the passwords outside of wordpress, but I need them within wordpress for other reasons now, is there a way to do this? Assuming user_hash is the correct field,,Some start with a $ and some do not.

Trackbacks and Pingbacks:

  1. What is the hashing salt for Sugar? - December 23, 2013

    […] having trouble matching user inputted password and the hashed password in the database. This post: New for Sugar 6.5 said that sugar is using the crypt () function in php. But it doesn't mention anything about […]

  2. Single Sign-On Between SugarCRM and Request Tracker | Blog of Leonid Mamchenkov - December 12, 2016

    […] maybe.  Especially after SugarCRM 6.5 introduced stronger password hashes.  But maybe we still shouldn’t send those all over.  Let’s encrypt the hash once over […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s