I am using Microsoft Access 2010 with unbound forms. No linked tables allowed, otherwise the connections string is stored in the table definitions. So it follows that we will use a query definition with no name to access SQL SERVER. This is recommended by Microsoft. We need to get the connection string from somewhere though. So it is recommended to return it from a method with a obfuscated name. It is recommended not to embed the connection string in plain text in the application source. So we use encryption.
A good way of doing this is to require the applications administrator to define the connection string at the first run of the application and according to this msdn article
...encrypt its value via DPAPI with a user-specific key of the account under which the application runs, and save the encrypted value in the Windows registry.
The accde launches from the logged on windows user account, after which the apps admin can login and setup the connection to the database, following the recommendations above.
The weakest link i now seem to have is the windows user account. It seems that anyone logged in to that account could decrypt the connectionstring if they knew the implementation of the security scheme. Which means that the system still is not secure enough.
I could create a new windows user, but that would mean that the password for that user must be kept safe, which means we are back at square 1, securing the password that is used to access some secret information.
There must be an easier way, any ideas?
Is there a reason you need to persist the connection string from session to session? Could you instead build a log-in form in your application where you accept the user's credentials, server instance and database name that they will be connecting to and keep this information in memory while the application is running?
This might provide more flexibility in that the administrator could decide to move the database to a new server and wouldn't have to worry about decrypting the connection string to change it and re-encrypt it. It would also allow for multiple databases to be defined - I'm thinking of a situation where you would have a QA server defined for testing changes before rolling out to the production server.
Related
Apologies in advance for sounding naive but I am new to this and stuck since days to no good.
I have set up LDAP on apache web server using below link and it is working good.
https://httpd.apache.org/docs/2.4/mod/mod_ldap.html
I am able to login to the application using a valid account in the directory. Now I want to create a non-ldap user (common user for API access) that can be allowed access through the web server? Is it possible? How?
I would strongly advise to create API accounts in your Active Directory. (in the company I work for, we use that and call them service accounts)
Centralizing access is the best practice, if you start mixing authentication methods in your application/website it can quickly become a nightmare of spaghetti code to maintain.
Centralizing access also improves security by allowing you to manage access in a single place.
If you do not want to go this way, you have the possibility to create a secondary authentication method through local users that would be stored in a database.
If you go this way, please do not store passwords in a non-encrypted way. Look for the following functions: password_hash and password_verify. When using SQL to transact with your database, make sure you do not end up with SQL injection, it can be disastrous to have SQL Injection in your login script.
Background
I've been out of the web app development realm for a few years and I've recently come back into it. There are a few questions I have about best security practices for performing the following tasks.
I'm developing an electron (node.js) application that will authenticate user credentials using my remote application server. On my server I have a MySQL database which will store the usual assortment of user account and application data. Additionally, the electron application will have a local sqlite database that I will periodically be updated to keep things in sync with the remote MySQL server. The Sqlite database is there to allow the application to continue to function should the electron app be used in an offline environment or in case the remote server goes down. I intend the application to be online first with an offline fallback.
Once the user authenticates in the electron app, the application will allow the user to do their work, and when the user is done, their work will be submitted to a 3rd party by posting that work to the 3rd party's API. The first time a user logs in, they will be asked to authenticate with the 3rd party API using OAuth2 and an api access token will be given by the 3rd party upon successful completion of this authentication procedure. This token will be stored in the remote MySQL database as well as the local sqlite database.
Here's the kicker. There will be multiple machines running this electron application so keeping everything in sync between all of these installations is a necessity as the same user may be using any one of these machines on a given day.
The Questions
With the background information out of the way, here are my questions:
If I hash and salt user passwords prior to storing them in the database: is SHA-512 still a secure hash, or is there another algorithm that is better?
The 3rd party API token is essentially the user's password to accessing the 3rd party API. I intend to treat it as such and give it the same treatment as I would a password. Since hashing is one-way and therefore not an option, how could I best encrypt the API token for storage in the database? My current thought is to use AES with a long randomly generated string that is stored in my server application's configuration file as the secret key. In this case, if the database is breached, the secret key would not be included with the data. To acquire the secret key the server itself would have to be broken into. Is this the best way of going about this?
Upon application startup or when manually triggered, the local electron app will query my remote server to determine if there has been any changes to the database since the local sqlite database was last updated. If there are changes and a local update is needed, the remote server will send back a response with all the things that have changed (probably in a JSON format) since the last update. The connection between the local application and the remote server will be encrypted using TLS (https). Is this sufficient to protect the data exchange (which contains password hashes and the like) between the local application and the remote server or should the JSON object be further encrypted? Is this even a good way to go about syncing data?
I appreciate any and all help. I'm a bit out of touch with some of the current best practices, and this is my first actual production application in a long while, so I want to make sure things are done properly.
I would like to use PouchDB in a web app desktop client. I work in an environment where the computer user is generic and different persons use the same computer account. However, using my app they must log in with individual user names granting them their corresponding privileges. The system works offline, with period replication to the server.
Browsing through the documentation of PouchDB and searching the Internet I come to understand that there is no access restriction to a local PouchDB. Anyone who has access to the client/browser has in principle access to the cached data. Also implementing any sort of user access control in my web app seems to be kind of pointless. The code could simply be altered to allow access.
I came to the following possible solution and would like to know if that could work:
First contact with the central server
App sends user credentials to the server. The server encrypts a special databaseKey with the user credentials and sends this encryptedDatabaseKey back to the client app. The client app stores this encryptedDatabaseKey in localStorage, decrypts the contained databaseKey, creates and encrypts the local PouchDB using this databaseKey (e. g. crypto-pouch).
Offline usage
User logs into the app, his credentials are used to decrypt the encryptedDatabaseKey in localStorage, only then has he access to the stored data. If someone alters the code of the app he still cannot gain access to the encrypted PouchDB.
I see the following advantages:
- Without correct credentials there is no access to the local data
- Multiple users can have access to same local PouchDB since the databaseKey is identical.
- The databaseKey could even be changed regularly (app compares during a connection to the server the local encryptedDatabaseKey and the one received from the server, if they differ the app decrypts the database using the old key and encrypts it with the new)
Does this seem like a viable solution? Are there any other/better methods of securing a local PouchDB?
crypto-pouch is indeed the best method to encrypt a local PouchDB. However, I think where you say
Offline usage User logs into the app, his credentials are used to decrypt the encryptedDatabaseKey in localStorage, only then has he access to the stored data
I think it's pointless to decrypt the key and use that to decrypt the database; you might as well just as the user to create and memorize a password? Then you can use that as the key to the crypto-pouch.
When I use the appcmd list appool <ApplicationPoolName> /text:* command, it shows me the application pool identity passwords in clear text. I am able to view the passwords in clear text using Get-WMIObject in PowerShell as well. This can be a serious security threat as a user with correct access credentials can easily view the passwords.
The Application Pool in IIS (v7.5) is configured using domain user account/password. In the applicationHost.config file, the password is encrypted using IISWASOnlyAesProvider encryption provider. Still, the password is shown in clear-text when I use any of the above two methods.
Is there any way to encrypt passwords in such a way that they are not shown in clear-text when I use the above two methods?
Unless something has changed, the answer is no. The principal is best stated by Raymond Chen:
'It's like saying that somebody's home windows are insecure because a burglar could get into the house by merely unlocking and opening the windows from the inside. (But if the burglar has to get inside in order to unlock the windows...)'.
The point in summary, is that anyone that can get to your IIS server or can execute a WMI command remotely against your server, or can execute a powershell command against your server has access.
They are assumed to be admins, and are assumed to be trusted, as occassionally admins would need to pull passwords for recovery purposes, or adding nodes to a shared pool if proper notes or password management wasn't done [mainly needed when doing basic authentication on a domain cluster needing shared passwords].
The passwords are only decrypted if you run appcmd as Administrator. If you run as a normal account, you get back the encrypted string.
This will be something like [enc:IISSomethingProvider:…:enc], just as you find it in applicationHost.config.
I have a Silverlight 3 app which connects to a server to perform various actions. My users log in using Forms Authentication but the actions they request are run on the server using the AppPool account so when they go in the audit logs they're recorded against the AppPool account. PCI DSS regulations now require that the user's own ID is in the audit logs which means the action must be taken using the user's creds. Now, I can save the user's creds when they log on and submit them with each request and the actions being taken by the server can use those creds. But the PCI regs say that if creds are saved they must be encrypted (to avoid someone taking a memory dump of the PC and getting the password).
The only way I can see of doing this is to get a public key from the server and encrypt the password with it, then submit the encrypted password and decrypt it on the server using the private key. But Silverlight doesn't have asymmetric cryptography.
I guess I'm too close to the problem and there must be another solution but I can't see what it is. Can anyone help?
CLARIFICATIONS
It's an internal application. Up until now, I've been using IIS Forms AuthN over SSL to Active Directory - I'm not worried about protecting the password in transit, just whilst it's held in memory on the client. As I understand it, because I'm using Forms Authentication, impersonation is not possible on the server unless I use LogonUser, which means I need the password on the server, so I need to transmit it each time, so I need to hold it in the client, in memory, until the app closes.
Are you saying you need to store the password for re-use in the silverlight app? If you are concerned about the password appearing in memory un-encrypted then Silverlight then I think you're in trouble.
The .NET framework does have a SecureString class for exact purpose you outline.
Unfortunately the Silverlight version of the framework does not have this class. Hence even if you were to keep the logical storage of the password encrypted at some point your code would need to decrypt it before using it. At the point there is memory allocated containing the string in unencrypted form.
I don't know much about Forms authentication but if you can map the User principle to a domain user (which you seem to indicate you need) then you will want to use impersonation when running your code on the server.
Alternatively stop using Forms authentication and use Windows integrated authentication where you definitely can use impersonation server-side.
Encryption should never be used for passwords. When you encrypt something then it follows there should be a way to decrypt it. One way hashes should always be used for passwords. md5 and sha1 have been proven to be far too weak for any secuirty system.
Sha256 should be used, and in silverlight this library will take care of it:
http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha256%28VS.95%29.aspx
In fact storing passwords using "encryption" is recognized by the vulnerability family CWE-257. The use of a message digest is the ONLY way to safely store passwords. I didn't just make this up, this is coming from NIST. There are many other vulnerabilities that come up when storing passwords. Here is THE LIST that NIST has put together: