We are developing a couple of web applications and web services for our intranet. To access resources like databases or other data sources we use technical domain users and store their credentials in the config file of the web apps. Passwords must be encrypted before written to the file. (The application then have to decrypts it to access the resources.)
We do this for quite a while but now a discussion came up. Our server operations team suddenly considers it unsecure to store the passwords in config files because an attacker might successfully decrypt it, maybe by analyzing the little tool used for encryption. (It's written in .Net so indeed it's not really hard to analyse the used algorithm by using Reflector & Co.)
As an alternative they proposed to use the technical user account as app pool security context. But I'm not sure if this doesn't mean to replace one possible security hole by an actual one: If the app pool runs under the context of the domain user, the attacker dont't have to know the password anymore. He simply can use security holes in the application or try to run his own code under this app pool somehow.
What do you mean? Is there a best practice to deal with passwords in web applications?
Thanks,
Rocko
Its a very common practice for a domain user to run the app. Just ensure that account has a really small footprint - only what is needed.
Related
As with many applications, my service's authentication logic lives in the application code. Now however, I need to expand my authentication to incorporate 3rd party identity providers for single sign on.
I want to retain the old authentication behavior (database lookup) but also want to add support for 3rd party identity providers.
With this increase in complexity, does it make sense to separate the authentication logic to its own service? In this model the application server will redirect unauthenticated users to the authentication server. After authentication is successful, the authentication server will redirect back to the application server.
Is this approach sound?
If you have available servers and infrastructure budget, let your web application perform the authentication, using a community maintained library.
Generally its no recommended to build one by yourself.
Store your users in a database table.
Authentication using other sites problems:
Your visitor may not want to have an account with 3rd party site.
It results in giving too much information to the 3rd party site (who share much of it with other sites which use their authentication mechanism).
It is generally a good idea to separate your authentication logic and have a different service perform that task. This is also true for other 'cross cutting' concerns such as authorization and SSL offloading. It gives you a simpler development environment and in general an app that is easier to reason about (for example, you don't have to worry about authentication while in development mode and you can develop the services independently which goes a long way in terms of productivity and velocity).
In order to compose the authentication service with your application, it is better to have a third component that orchestrates and routes the calls accordingly (as opposed to having autentication related code in your application).
Currently I'm developing a Node.js webserver-app that I then want to make available for download and use. This app should feature accounts, so that you can log in with your account on the website created by the server.
Since that would require a password, I also have to think about security obviously. But now, I don't really know how I should protect the password while sending and receiving it.
For storage, I was about to simply create a hash of the password and store that hash somewhere, but what about the transfer?
I was thinking about SSL/https, but this would require a SSL certificate, and even if I got it for free somewhere, I couldn't share it in an open-source app(?).
I could also somehow hash the password in the website, and then just send the hash to the server, but I think this wouldn't be the highest standard of security as well, would it? Considering that no SSL would cause more disadvantages than just worse/none encryption.
Any ideas?
I was thinking about SSL/https, but this would require a SSL certificate, and even if I got it for free somewhere, I couldn't share it in an open-source app(?).
Use SSL/TLS. Even if it's an open source app, it doesn't mean that you need to share your private key too. This would undermine the whole concept.
Open source means that you share the code with some license. What the licensor does with it is not your consern as long as they conform to the license. If they want to use their own instance of your software under their own domain, they will have to create their own certificate (under their domain).
I could also somehow hash the password in the website, and then just send the hash to the server, but I think this wouldn't be the highest standard of security as well, would it? Considering that no SSL would cause more disadvantages than just worse/none encryption.
This is no solution, because you now changed the thing you want to protect to something else. The model doesn't change just because you hash it on the client. Now you need to protect the hash on the transport channel which is actually the same problem as you would have had before with sending a password.
Currently I'm developing a Node.js webserver-app that I then want to make available for download and use. This app should feature accounts, so that you can log in with your account on the website created by the server.
Federated accounts
If you want federated accounts across multiple instances of your app which are hosted by different parties.
You could look into OpenID as an identity provider for all instances of your app. You would then either require that users use a known OpenID provider or you setup your own default provider. You could release the code for your provider as open source, but it wouldn't be necessary for the app to function.
If the OpenID interface is not enough, there is always a way to establish a pairing between instances of your app. You would have to build an interface where different instances may share data.
Unconnected instances
If this is only about securing the communication without SSL/TLS, then I must say, this is impossible in the general sense.
You could however let every student register in person and use that password on client and server to derive a shared secret key (i.e. for AES). Then you could use CryptoJS to encrypt everything with AES and send it using AJAX. The problems are of course that (1) there must be a person that handles the registration and (2) this is vulnerable to man-in-the-middle attacks, because JavaScript crypto is bad.
Good thing is that Let’s Encrypt will be online soon. It will enable a semi-automated way to request free certificates for your domain. It will be so easy that you can do this as part of the normal NPM install workflow.
http://letsencrypt.org works great for this and is now available (I understand I am a little late to this one.)
You can check out https://github.com/DylanPiercey/auto-sni for automated Letsencrypt certificates.
I've setup a Windows Azure database with the data accessible via oData. I'm trying to work out how to secure the connection between a WP7 device and the database. By secure I mean I only want users of the app to be able to access the data from within the app.
I've considered SSL but it's quite expensive for me - is there another way of securing this connection?
Thanks!
There are multiple definitions of "secure". You will need authentication, so Azure only lets the correct users access the data. This is usually handled by a user name and password supplied by the WP7 app.
The WP7 app needs to ensure it is talking to the correct server. SSL handles this using a digital certificate. There are other mechanisms but using something based on a public/private key pair is best because you can validate you are connecting to the correct server without being able to impersonate that server. However, the RSA algorithm used in most cases is computationally expensive.
The data sent between the WP7 app and Azure also needs to be confidential, including the user's password. This is normally handled by encryption. You an choose computationally less expensive algorithm or only encrypt certain data.
The data sent between the WP7 app and Azure also needs some form of tamper detection. Otherwise someone could corrupt the data sent or received. Maybe this is something you can accept for the app but it needs to be a way that an attack cannot easily reproduce. As Shanin's Maxim says, the attacker knows the system.
The problem is that SSL gives you all of these. Yes, it can be expensive but it is one of the best general purpose solutions available. You can change the cipher suites offered by Azure using using Group Policy, code or PowerShell.
If you do not want to use SSL, you need to know what you can sacrifice. In general I would not recommend doing your own encryption mechanism or protocol because us mere humans tend to screw it up.
Hi and thanks in advance,
I am looking for industry best practice or a ready made app to store and share passwords for for network resources.
My current situation is that I have a number of people that need to access applications as a specific superuser in order to access some features of these applications. The applications are third party build and cannot be changes to grant access to the required features for anyone but the superuser account. Normal admin accounts have elevated rights but things like creating accounts have to be done via the superuser account.
For security reasons I would like to periodically change the superuser accounts' password. Because of the number of people that need to be able to log in as superuser changing the password would be problematic and a logistical nightmare.
I'm looking to purchase or create an application that would:
Track who is looking up the password and to what resource
Allow me to specify what passwords a user can retrieve
The data should be stored and transmitted ultra securely
Preferable this would be an on-line application (I have Mac and Windows clients)
Keypass is great for this kind of thing. It provides a strong encrypted database of passwords and secure information. This can be accessed share via svn/dropbox/fileshare implementations using a master password.
This is more for a master database of secure data you can set up additional databases, maybe per user, but it starts to get a little away from what it's deigned for.
I would do a C# app that checks with a web service if the user can run the app and with what permissions, it would then be sent the encrypted credentials for a 1 time run, the service would log the request. This would all have to be done securely, so the service would use SSL and preferably certs between the systems. You have a good bit of research here to figure this all out, and you might have to use Java if you want mac... but I dont know how well that can launch apps as other users.
Solution #2 would be to use KeePass. You will have to be creative.
I've developed a CodeIgniter project tracking app for a client which lives at a public URL but is used privately. It includes a simple REST API, used exclusively for a Dashboard widget and Cocoa menu bar app though it will grow later.
Originally designed for a small team, the app is going to be used more broadly within the (large) company. My plan to grow and secure it...
Evaluate traffic needs, project resource usage, and scale hosting accordingly.
Rely exclusively on HTTPS and purchase a decent SSL certificate.
Require authentication for the REST API.
Actively monitor for abuse and have a blacklist (or several) in place.
Are there any obvious issues that need to be addressed or best practices to follow for a private/public app such as this?
It's a rather broad question. There are several complicated facets.
SSL is good; think about enabling CI's CSFR protection
Lock down your server. Close ports like email and ftp if you don't need them. Google for tutorials or ask specific questions based on your OS.
A great guide of form-based auth stuff: The definitive guide to form-based website authentication
Make sure your permissions are how you want them. e.g. keep private things private. Design a policy for granting and revoking access.