I have a password protected PostgreSQL database (running on windows) which has been accessed by an unauthorized person several times using this simple trick as described here:
Stopping PostgreSQL Windows service
Changing md5 to trust in pg_hba.conf file
Starting Windows service
Accessing database via pgAdmin without a need of password
Is there any way to block this mechanism? I've been thinking about multiple windows users (there's only one administrator account on the machine right now) with limited file change privileges, but I am worried about database functionality and I would prefer a little bit more straight-forward solution.
UPDATE
Thank you all for your responses, they were all very helpful.
It's obvious to me now the user accounts are the way - probably the only right way at all.
Indeed the way to solve the problem is not by looking into PostgreSQL, but by looking into your Windows security. Once someone gains administrator privileges, there is nothing which stops the person from changing anything - this includes your PostgreSQL settings. Even if you set a database password and set proper permissions for the pg_hba.conf file, the unauthorized person can still change the permissions back, or start the database in single user mode (no password required) and modify the passwords.
Create separate Windows user accounts, protect the Admin with a password, and stop using the Admin account for day-to-day work.
Perhaps change all your users to limited. Create a user called postgres thats also limited and set it so that that its the only user that can read/write its own files. You will have your administrator account, that still can do whatever you want to do. Now run the postgres service as the user postgres and youre done.
... and stop giving people your admin password -- you should be fine ;)
Related
I have been trying to access liferay using my Active Directory account but i am not able to sign in, knowing that the users are imported successfully but it seems that liferay doesn't import the passwords. How can I solve this issue?
AD Environment: Windows Server 2012
Liferay 6.2
With LDAP you typically don't want to distribute your passwords all over - password management is on one side, e.g. on LDAP, and the password policy that applies there should carry on everywhere. When you change your password on LDAP, would you want to be able to log in to your portal with the old password? One positive aspect on having passwords in a separate system (like LDAP) is that they can't get loose should there be any security issue in your front end application (like Liferay, but by far not limited to it).
In fact, I prefer to add an SSO system, so that Liferay never even sees any password. Further, passwords are hopefully stored in a salted&hashed way, so that you can't "just get" them out of any system. Granted, during login without SSO, Liferay knows the password, but I'm actually happy when that's not written to the local database.
If you rely on your Liferay database to have your correct passwords, you should be changing your architecture. To me your description sounds like "yay, works as expected".
i wonder why postgres allows trust Authentication method as it allow any role to connect without providing a password!!
if any role change the pg_hba.conf to trust then the server will be unsecure and will open to any role with any password
i would like to prevent any connection to the server without providing the right password , so how can we prevent this ?
is their any best practices follow in order to secure postgres server ?
As described in the manual, the postgresql daemon should be run as a separate user account which is not used for other purposes. The data directory and all the files in it should be owned by this user and permissions set so that only this user has access to it.
The initdb command which is used to initialise the database cluster will set it up like this.
If set up correctly, only the postgres user, or root, can edit pg_hba.conf.
The basic assumption behind the trust method is that the user is pre-authenticated by the environment. For example, if the database is not configured to listen on any external interface, and you are sure only authorised users can log into the server.
Section 19.3.1 describes in more detail the circumstances under which you might want to use the 'trust' method.
Check 19.3. Authentication Methods
I'm thinking of using application roles in SQL Server I've read the following on the Microsoft MSDN site:
http://msdn.microsoft.com/en-us/library/ms190998.aspx
Connecting with an Application Role
The following steps make up the process by which an application role switches security contexts:
A user executes a client application.
The client application connects to an instance of SQL Server as the user.
The application then executes the sp_setapprole stored procedure with a password known only to the application.
If the application role name and password are valid, the application role is enabled.
At this point the connection loses the permissions of the user and assumes the permissions of the application role.
I'm wondering, if the application must know the password, how best to achieve this. I would assume storing the password in source code is a security risk. Is there another secure way to deploy the password with the application (note this is a windows client application that will be deployed to user machines).
There is actually another way to deploy the password with the application.
You can store the password as a secret in the database itself.
For instance, use a stored procedure or a scalar function which returns this "secret". This is an additional step in the logic you describe, to be executed just after the connection is made by the application with the user credentials.
This is possible because the users will have access to the database using Windows Authentication anyway.
The permissions need to be setup so that users are granted access to connect to the database and to the programmable object only.
To "obfuscate" (NOT secure) the password, you can store an encrypted version in the database and use a simple encryption / decryption (like this one).
This approach has the following advantages:
The password is not stored in clear text anywhere (please note though that it will travel in clear text on the network if you do not use SSL Encryption)
Users of the application are not required to provide any input
The application source code does not include the password
The application deployment does not include the password
The password can be reset very easily, for instance on a schedule
There is no way to deploy a password on a user workstation w/o a local administrator being able to discover it. You can only raise the bar so high, but if the price is worth it they will find it.
You should rely on the user providing the password, which ultimately boils down to using Windows authentication instead, if possible. You should always assume that whatever privileges the application has, the user has them as well and he/she can exercise them using an alternative access API (ie. any query tool). If you cannot trust the user with certain privileges, then you must not deploy the application on his/her computer. For example use a multi-tier solution that isolates the database from the user and add any necessary validation in this intermediate tier (most ASP.Net and/or WCF apps would qualify as such multi-tier when done properly).
I've been searching hard to get my head around security related issues in a SQL Server.
We're developing a .NET application that targets SQL Server 2008 and we want to use FileStream.
Now I've found out that SQL Server only allows FileStream through the Win32 API if you use Integrated Security. The problem is that we have around 80% of our application finished, but it is entirely based on SQL Authentication. So we are doing INSERT's straight form our application and are not using Stored Procedures for every CRUD operation.
This is relatively safe because I can store the the SQL username and password in an encrypted form. I know the password is transported in Clear Text, but I'm willing to accept that.
We want end-users to be able to connect to the databse through tools such as Crystal Reports and for that we have an extra SQL login that has only SELECT-rights granted.
Now, if we change to Integrated Security we would have to give individual users (via AD groups, etc.) rights to do the things the application can do. Otherwise the application would not be able to do it's work. But then the end-user would also have these rights when he connects straight to the DB.
I see people saying that you should use Stored Procedures for every CRUD operation and grant the EXEC-rights only to the AD-group, but how would I do this? I do not see how a user would have different authorizations when he connects directly or through the application... Can anybody enlighten me on this.
An extra question for bonus-points: Intergrated Security will not work on a Workgroup as far as I understand. How do people get FileStream to work in a Workgroup then? Or is this considered an impossibility?
Integrated security WILL work in a workgroup, using the legacy mechanism, where you have a matching username and password on the two machines. Also, a domain user can use the legacy mechanism to log into a non-domain server if the server has a matching user account.
Integrated security can even work with non-matching usernames and passwords. This may help you in your scenario.
Try this:
NET USE \\DBSERVER /USER:DOMAIN\USERNAME
You will be prompted for your password. This establishes a NetBIOS session with the database server. You should be able to see the shared folders and shared printers on the database server once you have done that.
Once a netbios session has been established between the client computer and the database server, you will THEN be able to use integrated security without being prompted for a password.
You may have to specify "named pipes" as the network protocol to usem, if it doesn't work with TCP (but I think it will). Named Pipes inherits your existing NetBIOS session, so provided you can list the shares you are probably good to go.
You can also establish the logon session using the windows API function NetUseAdd with USE_INFO_2 (level 2) information which incorporates the password.
I guess the short answer then is that you can have a special Windows logon for your application and have the users log in using that. However note that they cannot also be connected to the same server using their own username and password.
Typical ISP setup. One server is the web server, another is the DB SQL server. There is a local administrator account, let's say XYZ, created on both machines. So when I log in remotely, I am either WebServer\XYZ or DBServer\XYZ, depending where I log in.
Now, when I login to SQL Server SSMS on DBServer using Windows Authentication, and execute "SELECT SUSER_NAME()", I get DBServer\XYZ. That makes sense since it's picking up the fact that I logged in with those credentials.
Now, move over to the WebServer. I remotely login as WebServer\XYZ. I've installed the SQL client components there. When I launch SSMS, choose the DBServer, login with Windows Authentication, and execute "SELECT SUSER_NAME()", I somehow get DBSERVER\XYZ, instead of what I would assume should be WebServer\XYZ.
Somehow, the XYZ from the WebServer becomes the XYZ from the DBServer. Why is that? How does that happen? Surely, it can't just be because the names happen to be the same?
I've heard of trusted domains, but neither machine is a Domain Controller, so I don't have access to that info. How can I tell if it's trusted or not, without the GUI tools?
The reason I ask the question is because, I'm trying to implement the same thing on my XP laptop (using Virtual PC), so I can imitate the production environment, but I'm not having any luck.
The NTLM challenge between machines is a little more complex #Quassnoi indicates but it is similar. The machines may well be in the same domain or trusted domains, but the accounts you are using are local machine accounts, scoped only to the local machine's security access management.
Local SAM accounts patterned as machinename\userid are non-propagatable. You'd experience a series of negotiated fallbacks when you tried to authenticate against external resources using that account as follows:
Pass current domain/username/password hash token - it'll fail, the account is untrusted
Fallback - revert passing hash of UserID + Password
Fallback - revert to connecting as anonymous credentials.
The fallbacks can also be disabled through configuration, it is very common for anonymous authentication to be prevented.
As #Quassnoi indicates in this instance you managed to login using the #2 fallback.
To enable account credentials to propagate, you'd need the following to be true:
machines would need to be members of domains with at least one-way trust between each other (they don't necessarily have to be members of the same domain).
use domain accounts - not local machine accounts - would look something like domainname\userid. A special case is the Network Service account which has a proxy account in the domain scenario - domainname\machinename$.
How do you tell if your machine is a member of the domain? It's pretty easy if you've got interactive login to the machines. There are a few strategies
interactively the System control panel will show workgroup or domain membership. (Right-click properties on Computer in the start menu)
at the command-line, IPCONFIG /ALL will also show the default DNS prefix which is typically the same as your domain name.
I suspect your ISP would create a domain just to make it easy to manage and monitor their machines. Whether they'd let you create domain accounts is a different question.
You XYZ accounts seem to have same passwords on both machines, and they are not a part of a domain.
WebServer sends just XYZ as a username and answers all password challenges successfuly, as the passwords do match.
DbServer, of course, thinks of you as of DbServer/XYZ, as it knows of no others.
Exactly same thing happens when you try to access one standalone machine from another one over SMB. If your usernames and password match, you succeed.