Is it possible to retrieve (if the user has sa rights) the password of a user in SQL Server 2008 R2?
The scenario is this: I need to automatically store in a document the list of all usernames and passwords, but without changing the password, just reading the actual password.
Is this possible or not?
Yes you can for SQL logins.
You read the hashed passwords sys.sql_logins (maybe only via the DAC) and use a tool like NGS SQLCrack.
However, there is almost no requirement ever to keep these in a document.
For Windows based logins, no. The password is in AD.
And read this: "What are the arguments for and against a network policy where the sys admin knows users passwords?"
Related
Is there a way to view the password of non-sysadmin accounts on SQL Server 2016?
I'm a database admin. I can simply change the password for the user, but I'd love to know if there is a way I can retrieve the password without resetting it.
In SQL Server user and login passwords are never stored; they are hashed. When a user logs in by presenting a password, that password is hashed and compared to the stored hash.
I have a user that has changed their last name. They access many different SQL databases across dozens of servers with Windows Authentication.
What is the best way to update their last name other than creating a new AD account and migrating them over to the new AD account?
Thank you johannes krackowizer for your valuable suggestion. Posting your suggestion as an answer to help other community members
Even if you changed user last name, it won't affect SQL Server.
While setting up login in SQL Server, you have to enter username and domain of the account.
After that, it will go to Windows and grabs the Security Identifier(SID) of the account
It stores both in the SQL Server
So, when you change user's last name in Windows, the SID will remain same.
When the user is logging to SQL Server, the SID will be passed from client to server that verifies against the database.
To know more about SIDs, find the link below:
SQL Server Logins, Users and Security Identifiers (SIDs) (sqlshack.com) by Simon Liew
My vba code in an MS Access database (which has access to a SQL Server) has - for reasons I have no control over - to control a ftpUser. So there is the need to use the ftpUsername and the corresponding password. For this I have to create a string like this: "ftp://do-main\thFtpUser:thesecretPwd/some/path/" and pass it to a internal web service.
How to store the password, so the person who works with the MS Access file (aka the user) has no access to the password of the ftp user? At least it should be as difficult as possible for the user to get the password.
The solution used here: MS access Encrypt Users Passwords Stored in User Table (SQL) is just a step more to obscure the password. But everyone who has access to the VBA code and the SQL Server can get the password in plain text.
Other solutions like storing just the hash and comparing the input will not work because I have to construct the string to pass it to another program.
I already figured out that the password should at least be in the SQL Server database so not everyone who got to the MS Access file with the code can get the password.
You can make an MS Access executable file (accde) and distribute. That way your VBA code incl. ftp credentials will be (reasonably) hidden from (general) users.
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?
WARNING - HORRIFIC PRACTICE
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.
Recovering the current sa password
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.
Moving the sa password
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.
I have a contained database with users authenticated in the database only (i.e. SQL user with password). What I am looking to do is the "uncontain" the database. Before I can change alter the database to containment 'NONE', I must remove all contained users. What I really want to do is create a SQL login for the user retaining the same password.
With a server login, I can use LOGINPROPERTY('myusername', 'PasswordHash') to get the password hash. For a SQL user with password (a contained user), this returns null. Where can I get the password hash for a contained user?
This article has the answer http://sqlblog.com/blogs/argenis_fernandez/archive/2014/07/28/scripting-out-contained-database-users.aspx
The article states that for contained database users, there is (currently) no method of obtaining SID or password hashes without connecting to the DAC (Dedicated Administrator Connection). Once you establish a DAC connection, the following query will give you the password hash:
SELECT password FROM sys.sysowners WHERE name = 'ContainedUser'
For information on how to connect get a DAC with SSMS, see https://technet.microsoft.com/en-us/library/ms178068(v=sql.105).aspx
Have you tried the sp_help_revlogin stored procedure?