If you want to subscribe to this forum, use your Facebook account, or send us an email to forum - at - multiotp - dot - net and we will send you back an invitation.

Is need to change default encryption hash & server secret values ?

edited August 26 in General
Dear Forum, I want to know, what if we not change the default encryption_hash & server_secret values in multiotp.ini file for client/server architecture, we are running huge setup & its difficult to maintain both values, as we notice normal user on windows/linux system may able to read C:\Program Files (x86)\multiOTP\config\multiotp.ini file and see both values easily. However we have protected multiotp server to allow only certain ips of servers and no else directly access the server. But the issue is that clients systems running different applications and some web applications vulerable to read data from file. I have wireshark dump and see encrypted values changes automatically like (server challenge & server password). So i have a question if some knows the secret & encryption hash, either they able to hack the users tokens ? or they able to query the user information and get their secret seed/token, and now using them they able to access/login to client machine ? as per dump i see values changes so there is a confusion. If you know additional details i will provide. Thanks

Comments

  • Hello Muzammel, The first question is : do you need to authenticate offline or not from the client ? The seed of a user is encrypted and sent back from the server to the client only if the cumulative requirements are met: - the cache option is activated on the client (server_cache_level=1) - the cache option is activated on the server (server_cache_level=1) - the shared secret is the same for tjhe client and the server - the OTP (prefix + token value) of the user is valid for this server It's not possible to forge an XML request of the seed of a user's token if we don't provide the correct OTP (prefix + token value). The encryption_hash is *only* a hash of the encryption key which is used to encrypt some data stored on the local drive. This encryption key has a default value, but you can change it (in the PHP code) for every instance of multiOTP, as it is not shared when doing client/server communication. Be careful that if you change the encryption key, you will have to recreate the users (or you can do a backup before, and a restore after). The server_secret is used to encrypt the transfer between the client and the server. It's also recommended to install an SSL certificate on the server. Don't hesitate to contact us if you need more information. Best regards, Andre
  • First of all i would like to thankyou for your prompt response :) Here below the answers of your questions. No we are not using caching mode (server/client), as we afraid that in caching mode user seed (user.db) file sync from server to client and local users are able read data in user.db file and using default encryption hash they can easily be decrypt/decode the seed with the help of php programmer. As per your above comments "encryption key only use for to encrypt some data stored on local drive" so question is please/kindly clear it is the encrypted seed present in user.db file has no affiliation with encryption_hash or user seed is not encrypted via encryption_hash ?. We are using SSL. Secondly my question is that as per you explained above and as per wiki "server_secret is used to encrypt data transfer between the client and the server" , so if some know the server_secret value or we using the default one, then there is any security risk ? like some send or pass query string directly to server url by using server_secret to get the user details or seed value and then using default encryption_hash they will easily decrypt/decode it & gain access to login. Security is our major requirement. Thankyou once again for your valuable assistance. Regards, Muzammel
  • edited August 26
    Hello Muzammel, As long as the cache mode is desactivated, the users data cache are not stored on the client side. The seed is NOT encrypted with encryption_hash. It is encrypted with an encryption key, and the encryption_hash is a non-reversible hash of the encryption key and is here to be able to verify that we have the correct encryption_key by recalculating its hash and by comparing it with the encryption_has. It is NOT possible to get user details from the server if the server_secret is not recognized. Furthermore, the server_cache must be enabled to allow to cache data on the client side. If you want to share more specific security concerns with us without exposing them on the Internet, I send you an email and we can also talk directly. Finally, thanks a lot for your interest in our library. If you want to support our work with a small donation, have a look at the Wiki homepage, we provide a link to our Paypal account. Regards, Andre
  • edited August 25
    Thankyou so much for prompt response and guidance, i have noticed via tcpdump/wireshark for each user seed authentication process based on 4 POST requests and in each request client send the and server in response sent the . Can you please guide is server challenge is (prefix + OTP value) ? which client is sending and in response server sent the server password , what is that ? and at final request client send , & in addition with what these values means ? . Also notice that both & values changed for every request, what are these values and how it can be generate ? Below are the complete handshake process for successful token authentication for user = testrdp Client = 192.168.25.104 Server = 10.10.28.85 Client request 1 192.168.25.104 10.10.28.85 HTTP 563 POST / HTTP/1.0 (application/x-www-form-urlencoded)Continuation data=<?xml+version="1.0"+encoding="UTF-8"+standalone="yes"+?> XUZIWzM0JDRxIz0kCDJiQGY1BT99QjJwWj0uKzByMjYiPTkw ++testrdp Server response against request 1 10.10.28.85 192.168.25.104 HTTP/XML 54 HTTP/1.1 200 OK CheckUserExists 7c550f8b0c055185d78e8d5e82d95239 22 ERROR: User already exists Client request 2 192.168.25.104 10.10.28.85 HTTP 557 POST / HTTP/1.0 (application/x-www-form-urlencoded)Continuation data=<?xml+version="1.0"+encoding="UTF-8"+standalone="yes"+?> XUZIW25ncjkrKTlxDmY0GGFiBzx5EDd0BmomfTomY2MpMzRg ++testrdp Server response against request 2 10.10.28.85 192.168.25.104 HTTP/XML 54 HTTP/1.1 200 OK ReadUserData 620a22f8c6367c056b351eeece7e2935 19 INFO: Requested operation successfully done [truncated]algorithm:=Vm96eg==\nattributed_tokens:=\nautolock_time:=Eg==\nchallenge:=\nchallenge_validity:=EA==\ndelta_time:=Cjo1\ndesactivated:=Fw==\ndescription:=\ndialin_ip_address:=\ndialin_ip_mask:=\nemail:=\nerror_counter:=Fw==\ngro Client request 3 192.168.25.104 10.10.28.85 HTTP 559 POST / HTTP/1.0 (application/x-www-form-urlencoded)Continuation data=<?xml+version="1.0"+encoding="UTF-8"+standalone="yes"+?> XUZIWzg0cj8qf2wnDGcyEjgyBjwtQzckXj4iKDInMDckZzVl ++testrdp Server response against request 3 10.10.28.85 192.168.25.104 HTTP/XML 54 HTTP/1.1 200 OK ReadUserData 327aea6e550b6daaa85508b81ff1e82f 19 INFO: Requested operation successfully done [truncated]algorithm:=Vm96eg==\nattributed_tokens:=\nautolock_time:=Eg==\nchallenge:=\nchallenge_validity:=EA==\ndelta_time:=Cjo1\ndesactivated:=Fw==\ndescription:=\ndialin_ip_address:=\ndialin_ip_mask:=\nemail:=\nerror_counter:=Fw==\ngro Client request 4 192.168.25.104 10.10.28.85 HTTP 895 POST / HTTP/1.0 (application/x-www-form-urlencoded)Continuation data=<?xml+version="1.0"+encoding="UTF-8"+standalone="yes"+?> XUZIWzI3cW93LTlzWTs1RzQwAGx9EDUmC2h1IWMlYzFyPDA1 ++testrdp ++ ++++++fd ++++++adffaabd4ef0cf50b8cb2ca0f33eddf8 ++++++2e15a98e96b45617b1879799900d61e8 ++++++Fz4eDSgYemkTMg== ++ ++0 Server response against request 4 10.10.28.85 192.168.25.104 HTTP/XML 54 HTTP/1.1 200 OK CheckUserToken db11cbfe7a0b3655911623c51ceda691 0 OK: Token accepted Regards, Muzammel
  • edited August 26
    Hello Muzammel, Thanks for your detailled questions. As I understand, the client of the open source edition is sometimes installed on a non-trusted machine. To answer to your needs, we have provided a new 5.3.0.3 version. Now in client/server mode, only unencrypted user attributes are sent back to a successful client request.
    https://github.com/multiOTP/multiOTPCredentialProvider/releases/tag/5.3.0.3
    https://github.com/multiOTP/multiotp/releases/tag/5.3.0.3

    Please check it on your side and close this issue if it is resolved.
    The server-side algorithm is implemented in the XmlServer() method
    The client-side algorithm is implemented in the CheckUserTokenOnServer() method
    Thanks a lot for your feedback. If you want to continue to support our work with a small donation, have a look at the Wiki homepage, we provide a link to our Paypal account.
    Regards,
    Andre
  • edited August 30
    Thankyou Andre, for your prompt response & guidance. Yes definitely i will discuss with my management for small donation :smile: . Also as above your version change , which user attributes sent unencrypted ? its usertoken ? . As i do the tcpdump again & not observed any special change. I hope this not effect the security. Just for suggestion, any changes in client version need to upgrade on every client and its tough job to up-grade many clients like 500+ to take effect of new features, else server upgrade is easily, so client version must be design in such a way to fetch new features automatically from server instead of up-grade client on every node :smile: . Regards, Muzammel
  • edited August 31
    Hello Muzammel,

    In order to have the new behavior concerning the call of the CheckUserTokenOnServer() method, you only need to upgrade the server to version 5.3.0.3, clients don't have to be upgraded for that (security parameters have always higher priority on the server than on the client).

    The information exchanged between the client and the server are encrypted with the server_secret. Furthermore, some specific attributes are stored encrypted in the server backend. These encrypted specific_attributes for a user are only transferred to the client if :
    1) The cache is enabled on the server side
    2) The cache is enabled on the client side
    3) The prefix+OTP of the user is correct

    By default, the encrypted attributes defined on the server are : admin_password_hash, challenge, device_secret, ldap_hash_cache, ldap_server_password, scratch_passwords, seed_password, server_secret, sms_api_id, sms_otp, sms_password, sms_userkey, smtp_password , sql_password, token_seed, user_pin.
    Let's just describe us clearly your current configuration (you can send us an email if you prefer (info -at- multiotp.net) :
    a) Do you need cache (offline) authentication on the clients or not ? NO/YES
    b) What is the value of the server_cache_level on the server ? 0/1
    c) Which OS/distribution are you using for the server side ? Windows / Linux / VM provided by us / other
    d) What is the multiOTP version on the server ? 5.x.x.x
    e) What are you analysing with tcpdump ? Successful authentication / Refused authentication / other ?
    f) What is the url of the server you have configured ? https://xxxx / http://xxxx

    Best regards,

    Andre
  • edited August 31
    Dear Andre,

    Thankyou once again for clarification, highly appreciated. Below are the answers of your questions. Also i saw the ChapChallenge, ChapPassword and ChapHash values encrypted on server.

    a) Do you need cache (offline) authentication on the clients or not ? NO/YES
    Ans: NO

    b) What is the value of the server_cache_level on the server ? 0/1
    Ans: 0

    c) Which OS/distribution are you using for the server side ? Windows / Linux / VM provided by us / other ?
    Ans: Linux

    d) What is the multiOTP version on the server ? 5.x.x.x
    Ans: 5.3.0.3

    e) What are you analysing with tcpdump ? Successful authentication / Refused authentication / other ?
    Ans: Successful authentication.

    f) What is the url of the server you have configured ? https://xxxx / http://xxxx
    Ans: https://x.x.x.x

    Regards,
    Muzammel
  • The follow-up of this specific discussion is done by email between muzammel and the multiOTP team directly.
This discussion has been closed.