As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Is it okay to give Network Service access to the site's SSL certificates private key from a security point of view?
EDIT: adding some context to the question
In this link, under section "Encrypt cookies using RSA" step 4, the code uses the "serviceCertificate" to encrypt and sign the cookie. Access to the cert's private key is required here.
If you mean services like apache... you would have no choice. The alternative would be to enter the passwort on every startup - but even then the software has access to the key.
Well, if somebody manages to hack your web script (via SQL injection or whatever) such that copy of private key is downloaded by evil hacker, then that hacker will be able to establish fake SSL server that impersionifies yours. However, to be really successful, hacker also needs to inject bogus DNS records such that bogus server has matching host name.
Having said that, it is difficult to not open access to private key to web server itself - otherwise you will have to type private key password every time you restart web server.
It's safest not to have any access beyond that which is strictly necessary. Access to secret and private keys is very important in key management. To make sure you are not introducing vulnerabilities, it is also pretty important not to use private keys outside their use case (e.g. authentication in SSL is different from signing data).
Security is about layers. The more and better secured layers you can introduce, the safer you are. Limiting access is a very high good. So if it can be avoided, don't mix your transport layer and application layer.
At our company we always create separate certificates for different uses. We try to keep the SSL handling and application handling on different servers. The application server only gets fed the authentication details.
That said, I'm employed at a company that focuses on security. You can obviously use less stringent security, but it's a good thing if you make some well thought out security policy around it. If you're not sure, hire a consultant.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I know this may be not a good question.
I was asked a question: do we really need authentication among microservices. And I have no idea the answer. I did read some tutorials on SOA, microservices, and how to add authentication among the services. But I did not have too many ideas why we need authentication/authorization between microservices? Any use cases where they are required? Any use cases where they are not required? Any potential risk without authentication/authorization?
Any comments welcomed. It is better to give some practical examples. Thanks
Whether a microservice that you design and develop requires authentication is up to your functional requirements and the way you design it.
A common technique used is to not have authentication on each individual microservice but to group them together behind a common fascade (such as an API Manager). You can then apply authentication and other policies at one place - the policy enforcement point/API Manager - for "external" consumers while "internally", behind your common security boundary, your microservices remain lightweight and can call each other without authentication (if that makes sense for your usecase/requirements/architecture etc. etc.)
To sum up - it's a design decision that involves multiple tradeoffs.
Clearly, if you have a critical business service fetching or updating sensitive data, you might want only authorised callers to access it. But you might not want many internal callers (could be other microservices) running within your organisation's "trusted" network to be burdened with unnecessary policy enforcement.
But then, there might be situations where even internal callers need to authenticate properly (e.g. if it is a payment service)
Authentication/authorization in most cases is needed for microservices that provide public API, as they are available/visible for the World.
Why? Cause when someone from the World calls the API method, we (in most cases) want to know who the client is (do Authentication) and decide what client is allowed to do (do Authorization).
On the other hand, for internal microservices (in most cases) the client's are well-known as they are other internal microservices. So until you don't need to provide different restrictions of use for different internal microservices there is no need for authorization. Note that I assume that internal components only available within the organization.
If your organization is considered with internal threats (and why wouldn't they be?), then yes all microservices need to be protected from malicious use.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am currently building a SignalR application (using ASP.Net MVC4, on IIS7 with SQL Server 2008 R2 Express), where users enter a lobby and are placed into groups and then interact on different pages.
Html5 LocalStorage is a requirement for any participant, so I can store group information on the client side.
I have two questions about the application design related to SignalR group memberships:
What is the best way to store group membership on the server? a singleton variable, a database with group and connection IDs or something different? Would a database be a problem with SQL Server Express and about 100-200 users?
What will change and fire during page changes? Do I have to renew group memberships manually, do the disconnect/reconnect fire and if yes can I distinguish this type of disconnect from users leaving for good?
I use msopentech.redis for that. A very fast cache that also persists your data. (lots of info found on google) You could use booksleeve (signalr team also uses that) or servicestack.redis to access it. This way you won't have to put it in static vars or slow database calls.
With every page changes on the same site you'll receive a disconnect and a connect. The connectionID will be different, so you should map connectionid's to the logged in user with some mechanism and persist that. That is if you want to be able to send individual messages instead of broadcasting.
(1) If you intend to persist the group information only for a session, you should consider using static variables in the Hub/Persistent Connection class to store information about the groups (memory requirements permitting). For instance, a dictionary/map between connection ids and groups. It's important to note that statics will not be persisted in cases such as when the app domain restarts or in web farms.
To avoid this, you can simply store the group information in a database and not be concerned about losing it during app domain restarts.
You should also see the Chat sample in the SignalR solution - it uses static variables to keep information about which chat rooms different users are in.
(2) If you establish a new connection from another page in the same app, then the connection id will be different. When you refresh a page, the disconnect event will fire and you will be connected again with a different id. In these cases, you will need to manually use the session management mechanism in your app to map the new connection ids to users.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Soon I will be releasing my first e-commerce site. I'm a bit paranoid about what data to encrypt or not to store at all.
I plan to use BrainTree payments and their Transparent Redirect solution which means I'm not even a proxy for the credit card payment but simply keeping the token of payment processing o the server.
In addition, I keep user shipping/billing address also basic contact info such as full name, phone and email.
My question is, beside the password (default by Django to encrypt), is it necessary/needed to encrypt the user information such as their addreses?
Well this is a question you have to answer by yourself, are you willing to pay the additional cost of encryption and decryption when you want to access any of this information while storing or retrieving respectively? Is it worth the performance penalty?
The reason that you are even considering encryption is cos you are worried about your application being hacked, may be it is useful for you to spend time covering that base than worrying about what will happen once your application is hacked.
Also for encryption/decryption you need to use a key, well what guarantee that your key wont be hacked once your app has been and there on you cannot do anything as it is. Note that hashing is different from encryption and you dont get back the hashed data using the hashkey.
Some more things to be considered, do you really need to store this information or rely on an external service to provide you this if there is such an option and the user is registered with it.
Also you might want to read up on this: https://web.archive.org/web/20211029043614/https://www.4guysfromrolla.com/articles/081705-1.aspx
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'm about to build a new web application and I'm getting stuck on which authentication system(s) to support.
Back in the day it used to be a simple matter of creating a registration page and having everything tied to your own custom authentication provider. These days there's OpenID, Facebook Connect, Twitter and now I'm reading about OpenID Connect - a wrapper around OAuth.
So faced with the prospect of having to accommodate an ever-increasing array of authentication protocols, I'm wondering which ones (i.e. the "Open-X" variety) are the "must-haves" and which are just the "gravy".
Also, is it still considered good practice to have a Roll-Your-Own registration form or is it acceptable now to expect users to sign in using Google, Facebook or some other variation thereof?
This question is asking a similar question with the expectation of choosing one mechanism only. I'm not convinced that this is the most inclusive approach, but supporting everything surely has to be impractical.
I'm a qualified fan of OpenId - it's good for techs, but not so for the mroe general user. So much of what you're asking can only be answered when we know your audience. If your users are also likely to be on Facebook that indicates a less technical audience so that's probably the way to go by default with OpenId as secondary mechanism. IMHO if you're on Twitter then OpenId shouldn't hold any fears and three mechanisms is at least one two many.
As for your rolling your own login page - why do you need it? It's just another page to code if you're going to let others handle the login why bother creating your own.
I think for a developer type website SO made the best choice in picking openid. technically inclined people can pick up on openid almost instantly. IMO, if you have a general site where people that are not technically inclined are visiting they may not get it right off and may choose to go to a different site. I say, make the users choose between your own registration system and openid - this way you won't scare the non-geeks. I have a general website and have seen that people usually choose openid to login. Hope that helps
This depends on what your requirements are - your reason for authenticating users, and what you can expect your users to understand and be willing to use.
In general, though, go with what's popular, because you'll benefit from more robust libraries, eyes looking at the security implications, and available service providers. Assuming you want single-sign-on, this currently seems to be either OpenID+OAuth, or OAuth WRAP. This can be subject to opinion; I recommend looking for identity-centric tech blogs and lists to see what's being discussed.
Whether to support Facebook Connect depends on your timeframe as well as your expected users. Facebook and FriendFeed are backing OAuth WRAP, so supporting Facebook Connect might not be necessary in the future.
The StackOverflow "featured" provider list isn't really relevant unless you care about what providers your users will use to authenticate. Otherwise, listing them is just a convenience for users. Frameworks such as JanRain's RPX might provide this UI for you.
Unless you want to integrate with another site that uses a specific login mechanism, I would suggest just writing your own. It makes like simple for users and yourself. True, you will need to ensure passwords are stored securely and you should use SSL to post the login info, but this isn't that big of a deal.
If the Internet was to be re-invented today, I'm sure there would be a universal Internet login that was part of the HTTP standard and handled by DNS servers (ok, I don't know how it would work :), but unfortunately there isn't and I don't think Open ID is the answer (nor any of the other login providers).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
For my asp.net web applications against sql server(at least the ones that require a logon to access) I generally implement security as follows:
I generally roll my own user signup, user login pages and keep a userid and an encrypted password in an sql server and validate the login against that table - I also provide for forgotten passwords, 'send me my password', email verification to activate accounts etc all thru custom code.
Once the user has been validated by the app (and lets assume that all users have the same privileges), I generally use a utility logonid to let asp.net talk to sql server, so in other words I only need to create a single logon id per application, and since 100% of all data access is done thru stored procedures, I need only grant access to a single user to execute stored procedures, and no other work is required on sql server. Each application has its own database, and the logon for that app can only access that database.
All this works perfectly well for me, the only negative of this is that it would be nice to be able to setup a trace in sql server and see the userid and the procs that are being called, but since all users are 'talking' to the database thru a single database logon, this can't happen.
So, two part question:
1) Are there security models are you folks using that I should consider? Its easy to always do the same thing over and over, - especially since it works - but are there other models that would work better or that I should consider? Is it recommended practice that all database access from an asp.net app would all share a single database login? or is this considered bad practice? and if so, why?
2) Assuming I stick with my model, is there a way to allow for the application login id to be seen in the sql trace window? It would be nice to see the sp's being called and the user id of the person logged into the system (not the database login).
Is it recommended practice that all
database access from an asp.net app
would all share a single database
login?
Yes, primarily for connection pooling.
In regards to 2), I normally do that by logging at the ASP.NET side.
1) It is recommended that your web application use a single login to the database typically. If you don't you are going to be forced to impersonate your caller, which is typcially not recommended, and it doesn't scale very well. You should not use a different connection string for each user. For example using SQL Authentication for each user is a bad idea. It will make connection polling ineffective.
2) You could do this by modifying the connection string but that would make connection pollign ineffective.
From a .NET best practices point of view, you may want to consider taking a look at Microsoft Enterprise Library. It contains a set of practices, patterns, and features that assist with issues such as Security and Data Access.
1)As long as you are using stored procedures for access one login may be fine. Some peolple like to use one for admin as well.
2)You could modify your stored procedures to accept a user id as a parameter.
I would generally share a single user for connection pooling.
In the case where you may need to trace a particular user. I write in admin functionality where you can make the application use a second database login. You can then enable this for a specific user and trace that user individually.
It just means you get the ability to trace as a one off, yet keeping the single user connection pooling for the rest of the application.
I've been using the same approach as well. More recently, I wonder if this is affecting the application's scaleability. My DB servers have multi-core processors and are quite capable of parallel operations, but I think SQL Server serialized queries running with the same userID. I think this means that stored procedures from different actual users are beeing queued up because SQL Server sees them all as coming from the same the same userID.
If this is the case, I'd think it would be severely limiting the scaleability of my app, no?