Excellent explanation Doug. -vineet bhargava
Sent from BlackBerry® on Airtel -----Original Message----- From: "Mueller, Doug" <doug_muel...@bmc.com> Sender: "Action Request System discussion list(ARSList)" <arslist@ARSLIST.ORG> Date: Mon, 6 Jan 2014 12:14:50 To: <arslist@ARSLIST.ORG> Reply-To: arslist@ARSLIST.ORG Subject: Re: Decrypt AR User password Jean-Louis, To confirm the response from Fredrick - we export the hashed value and then import the hashed value. So, there is no decrypting of the value and there is never a time when we store the clear text password. Now, on minor clarification on LJ's comments. Sure, in general, an arx file is generated by the AR System, but it can be generated by anyone - it is a defined format. And, you could import users using a .csv or other format - or create them manually. If you are exporting from AR System, the password will always be the hashed value as that is all we have stored. But, if you create an import file from ANOTHER source or you create users manually in a file (with passwords which is terribly unsecure of course), you could have cleartext passwords in a file. NOTE that the Remedy environment would NEVER do this. But, you could do it outside our system.... How do we know it is the hashed value vs. a password??? Because of the length. All hashed values are the same length and are the max password length. Anything not that length is assumed to be the password itself. We would hash that password and that is what we would store. Of course we have the password for that transaction because you just sent it to us, but we store only a hashed value and NEVER the clear text. So, we do know the difference between a hashed and clear text value and will handle it appropriately. But to re-emphasize. We never store the clear text password anywhere - you will even see that we do not report that information in the logs so you cannot use logging to trap passwords. In addition, we even know the password field and do an encryption on the wire so that it is not cleartext on the wire between the client and the server either (this is independent of whether you have turned off full package encryption which is on by default). We can accept a clear text password to define a user or modify a user (all controlled by permissions of course) and we do know the difference between the value we receive about whether it is hashed or clear text. I hope this helps, Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Monday, January 06, 2014 7:58 AM To: arslist@ARSLIST.ORG Subject: Re: Decrypt AR User password ** if it's an arx file, that means that it was exported from Remedy. Remedy never stores un-encrypted passwords in the password file, so the value that was export must already be a hash...so the imported value from an arx file IS a hash. On Mon, Jan 6, 2014 at 8:56 AM, Jean-Louis Halleux <supp...@arsmarts.com<mailto:supp...@arsmarts.com>> wrote: Then another question: how does ARS know that the value you submit in an arx file containing users and passwords is the hash, and not the value in clear text ? Thanks Jean-Louis Halleux supp...@arsmarts.com<mailto:supp...@arsmarts.com> On 06 Jan 2014, at 15:52, "Grooms, Frederick W" <frederick.w.gro...@xo.com<mailto:frederick.w.gro...@xo.com>> wrote: > Export/Import works because both systems are ARS servers. You are not > decrypting/encrypting the password, just copying the encrypted value from one > server to another. It is just like having to restore a backup. > If you look at the export you will see it is the hashed value. > > Fred > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of > Jean-Louis Halleux > Sent: Monday, January 06, 2014 1:54 AM > To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> > Subject: Re: Decrypt AR User password > > Hello Doug, > > I have then a question if you cannot decrypt a password: how can you export > data from the user form (including the password field), and then import it to > another server (with the password field) ? I tried it a long time ago, and it > used to work: users had access to the new server. > > Best regards, > > Jean-Louis Halleux > supp...@arsmarts.com<mailto:supp...@arsmarts.com> > > > > On 02 Jan 2014, at 18:35, "Mueller, Doug" > <doug_muel...@bmc.com<mailto:doug_muel...@bmc.com>> wrote: > >> Several comments on this thread. >> >> First... >> >> There is no way to get a user's current password. PERIOD. It is not >> possible. We >> in fact do not ever store the user's password in our system. We store a >> one-way >> hashed copy of the password. >> >> When validating a user, we hash the password they give us and compare to the >> hashed >> password we have stored. We cannot take the hashed password and regenerate >> the >> original password. >> >> This is the most secure method for handling passwords in the system. And, >> no one, >> not even an Administrator, can ever get the password that a user has defined. >> >> This is important because users generally use the same password for many >> things so >> if you could reverse engineer their password you could gain access to other >> things >> that that user has access to. This is not possible with the strategy we use. >> >> Now, on to the question about wanting to verify a user..... >> >> If you are coming in from a client or from workflow and you are the user and >> you >> want the user to verify their own password, the Application-Confirm-Password >> operation will work. NOTE that this is verifying the password of the >> CURRENT user >> session. There is no ability for one user to use this command to verify the >> password of another user. >> >> If you are coming in from an API program, simply issue a call like >> ARVerifyUser >> and supply the user name and password (and authentication information if >> that is >> required) and validate the user. If you want to run the program as a >> different >> user than the user whose password you are changing, just use different >> control >> records for the program and the call to the ARVerifyUser (remember to >> terminate >> both sessions). This will validate the password for the user as you are >> logging >> them into the system. >> >> Note that if using external authentication, your password is not in the AR >> System >> at all so you likely should be changing it through another mechanism >> supplied by >> the external source. If you are using external authentication directly, you >> can >> still validate a users password using the above techniques. >> >> Now, if using SSO, there is another layer going on. The AR System NEVER >> sees the >> user's password at all. That is intercepted at the SSO level. So, there is >> no >> way to validate the user's password through the AR System if using SSO >> (unless of >> course you write a custom interface to wherever SSO is validating things and >> you >> pass through that custom logic. >> >> >> I hope this is helpful in solving your situation. >> >> Doug Mueller >> >> >> -----Original Message----- >> From: Action Request System discussion list(ARSList) >> [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of >> Kulkarni, Adhwari >> Sent: Thursday, January 02, 2014 1:06 AM >> To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> >> Subject: Re: Decrypt AR User password >> >> Hi James, >> If you want to validate a user and change its password using API, you can >> simply create an instance of ARServerUser (Changes as per C/Java code) and >> pass the username and password that the user has entered. >> By just trying to do a .login(), you should be able to check if it's a valid >> user or not. Also, you can use the setPassword() method to change the >> password. >> Also, you should not pass the passwords from field ID 102 to the APIs. The >> password passed through field 102 is hashed and not encrypted. If you need >> to confirm the password, pass it through field ID 123. >> >> Regards, >> Adhwari >> The opinions, statements, and/or suggested courses of action expressed in >> this E-mail do not necessarily reflect those of BMC Software, Inc. >> >> -----Original Message----- >> From: Action Request System discussion list(ARSList) >> [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of James >> Smith >> Sent: 01 January 2014 19:35 >> To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> >> Subject: Re: Decrypt AR User password >> >> Thanks LJ Longwing >> >> I tried executeSpecialCommand as well but its generating same exception. >> >> I saw a new method - ExecuteProcessForActiveLink but I need to pass the >> activelink name as an argument for this method. >> >> It seems there is no way to validate users password. >> >> Happy New Year. > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at > www.arslist.org<http://www.arslist.org> > "Where the Answers Are, and have been for 20 years" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> "Where the Answers Are, and have been for 20 years" _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
