I've logged in to my sqlserver with a registred "sa" sql account and I want to print (not change) my current password. I can change it but I have an application using the current password.
I have done
select * from sys.sql_logins where name ='sa'
but it gives me a hashed password
If it is impossible, how to export my sa connection to another sql server instance?
Change your application to use a user OTHER THAN sa, and preferably without sysadmin permissions. Usually database level db_datareader, db_datawriter, and MAYBE db_ddladmin is enough, though it may need a GRANT EXECUTE on the database.
If you can't, then argue some more. In writing.
If you lose again, go change the sa password to a long, strong, cryptographically random password in concert with the application being updated with a new password.
And make sure that instance is used ONLY for that app, so the risk is limited to that one area.
First, you are a sysadmin, aren't you? You should already know the sa password! If you lost twice, just change the sa password on the other instance to that same one (or, better, change them both to something better), through ALTER LOGIN (below) or the GUI.
Second, realize that EVERY USER OF THAT APPLICATION CAN GET YOUR SA PASSWORD - they can almost certainly extract it right out of the application with a hex editor, looking for the string pwd or pass (either UCS-2 "Unicode" or ASCII).
You have the application, right? Consult your local security admins, and see if you're allowed to open it up in a hex editor and find the sa password yourself.
In general, if you want to move the same password around, you can use
ALTER LOGIN sa PASSWORD = 'hash string' HASHED
to change it.
Do not do this regularly - if someone gets hashes of all your passwords (just like you're getting them), it's better that each one have a unique salt, so the attacker has to spend more work testing against many salts before they start finding passwords.
Do not do this from lower protection to higher protection - SQL Server 2005, 2008, and 2008R2 all use the same algorithm. SQL Server 2012 and 2014 use the same. Don't move a 2005/8/8R2 hash to 2012/14; it's significantly weaker (and 2012/14 password hashing is pathetic to begin with).
Thus, you're better off changing the password to what you want in cleartext, so SQL Server generates a new salt. The password hash is incredibly weak, a single iteration of SHA-1 or SHA-512, so it needs all the help it can get.