I am just starting out with identity server and am going through the quickstarts now (apologies for the noob question in advance!).
My query comes from the fact that in all the quickstarts on the documentation site, the client secret appears in clear text in the code, even the sample where both EF and asp.net identity are being used to store config and user creds.
My immediate reaction is that storing a secret in code is a no-no, but I can see mitigating circumstances depending on what client type we are talking about e.g. if the client is a hosted mvc webapp then the code is theoretically well protected on the hosting server, but if it is a desktop client then it is more vulnerable to for example decompilation.
I have looked through all the quickstarts and also done some googling, but I cannot find any definitive answers of the kind that are similar to asp.net identity users creds (i.e. store hashed in a db). I have also searched through the identity server docs to find any guidance on this and have not found any (even the secrets sub-topic has the secret in code).
So am i worrying over nothing and should just stick the secret in the config file in clear-text code or is there a better in-built mechanism (like asp.net identity's hashing and storing in a db or similar)?
Thanks :)
PS this question applies to the secret storage in the identity server code as well as in the client
Unless you are just starting up on Identity you should store all of your Client Secrets in your database. Most startups use the Config.cs file to store all of these because its just local testing. But once you have IS4 working you should move it to your database and store a hashed version of the password to insure that if your database was exposed they would still be secure. As for you identity server code, I store the secret in the appSettings which you can keep private depending on your deployment.
Related
There is already a question there on this topic but there is no answer to it hence a new question to #gilm0079 for his views in case if has overcome this problem
Tips for running IdentityServer4 in a web farm
I know its a quite old post but wondering how you managed to get this working or and also what the issue was. And if so you could share your experience would be great help
On top of persisting the keys in redis, do you need load balancer to use sticky sessions?
And any other consideration?
You can run IdentityServer4 in load balanced and auto-scaled environment. Requirements here are :
To have the same signing certificate across all instances of IdentityServer. You can create a X.509 certificate and store that in shared secret storage (e.g. vault) and let instances refer the same.
To have persistent shared storage for keys. There are different storage options like redis, database or you can implement your custom key provider. See here:
https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/implementation/key-storage-providers?view=aspnetcore-5.0&tabs=visual-studio
I have a static React site that I am using to upload an image to s3 using an identity-pool in cognito. I did this more out of curiosity than anything.
i understand that one way to do this would be to upload my image to my server which could then upload it to s3.
but I want to know if there are any best practices for doing this from the client side directly without a server.
One of my concern in my current approach is that the identity pool id is public. Any feedback is helpful.
This resource Serverless Stack will guide you through exactly what you want to do, it has helped me configure similar "serverless" deployments.
The pattern to do what you are describing is as follows:
Users authenticate with the identity pool, this returns a JWT
Federated Identities returns AWS IAM credentials for valid JWT (note: the Federated Identity must have a Policy that allows the AWS IAM credentials to access S3)
Using AWS IAM credentials, user client can upload image to S3
In regards to the identity pool, your identity pool-id is infact a public resource, just like your web app. Your identity pool is secured by the fact that users must exist in the identity pool and must have the correct password for that user.
If you don't want to expose your id in your client codebase (you shouldn't), what I usually do is set the id as an environment variable in a .env file then use a package called dotenv to expose it to the .js file that needs the id. Then of course include the .env file in your .gitignore to avoid it being tracked in version control.
More info here: https://github.com/motdotla/dotenv
Maybe you can consider similar design as described here: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc_cognito.html
A common pattern is to have your server authenticate the user request and return a pre-signed URL. This can then be used to do an upload directly to S3 using standard HTTP methods. See Uploading Objects Using Pre-Signed URLs.
Seems like your question about public identity pool is actually a different question. I'll keep my answer to the bulk of your question, as secure authentication is a whole other topic you should probably research first on your own.
I have already
1. Searched on google
2. Here on stackoverflow
3. Some recommendations for me on my posts, that not to use direct connections free text statements from App to SQL Server, rather than to use mostly recommended REST API services.
Overview
I find SQL Server connection very smooth in Xamarin Forms development. My major projects are web based asp.net c# and desktop based vb.net which use same Hosted MS SQL Server 2012 Express (Virtual Private Server and not shared server) Database.
In Desktop we have option such encrypting the app.Config file where we can store the database connection secure credentials.
In Web-based we have web.config file where we say its secured way to put credentials there.
(If wrong please correct me)
Frankly I tried at initial stage REST API Services including Microsoft Azure but it looks very complex or some or other limitations for me in approach or pay strucure. (Or say may be I totally am now flexible in c# regular statements).
As I am having own Hosting Server I don't want to choose again any other.
Finally to my query
Now I store in Xamarin Forms Class folder in .cs all secure credentials.
/------------------------------------------
//Connection String
//------------------------------------------
public static string appNutri_connection_string = #"data source=<IP ADDRESS>;initial catalog=<Database_Name>;user id=<user_name>;password=<pass_word>;Connect Timeout=600"
And I use this appNutri_connection_string throughout project for connections.
Also when we compile the Package we are opted first to enter password before distribution.
Not only that before we upload it on Google Play, it rechecks Hash Key credentials respective package name, then only it publish the apk.
So please let me know how is not safe for APK to store credentials in .cs file. Secondly , most important is there any other solution to encrypt the credentials file? So that I do not need to break my so smooth trend going on all platforms.
This is a very crucial stage for me to go further as still I am in very initial stage of product live implementation. So do not want to go further with any loop holes or wrong perception. Data (Client's especially) Security and Privacy is my major Task. Cannot compromise on that anytime. So please suggest me best way to achieve this task.
(Once again may be a possible duplicate question but frankly I did not found a detailed explanation or information nor here nor on any google search)
As you are in very initial stage of your product lifetime, PLEASE CHANGE YOUR ARCHITECTURE!
Never, nerver connect directly to a sensitive database from outside - put at least a front-end layer (eg. API) between public clients and your database.
I've been thinking about this quite a while and it's bugging my head off, lets say we have a website a mobile app and a database.
Usually when we develop our websites we pretend to store our database credentials in a configuration file and connect the website directly to the database without using a multi-tier architecture, but when it comes to a mobile application such Android or iOS this applications can be engineer reversed meaning that there's a risk of exposing your database credentials.
So I started thinking about this multi-tier architecture and kind of thinking about how Facebook and other social network do their job, they usually make an API and use a lot of HTTP Requests.
Usually social networks APIs have a app_id and a secret_key, this secret key would be used to increase the safety of the application but I'm thinking about how could I store these keys inside my application since I would go back to the begining of my discussion, if I was to use Java I could use the Java Preference Class but that isn't safe either has I saw in this question, plus I would need to make sure my HTTP Requests are CSRF safe.
So, how could I store these keys inside my app? What's the best way to do it, since hard-codding it's out of the question.
You should always require users to log in - never store credentials or private keys in an app you'll be distributing. At the very least, don't store them unless they're specific to the user who has chosen to store them after being validated.
The basic idea is that the user should have to be authenticated in some manner, and how you do that is really too broad to cover in a SO answer. The basic structure should be:
User asks to authenticate at your service and is presented with a challenge
User responds to that challenge (by giving a password or an authentication token from a trusted identity provider).
Service has credentials to access the database, and only allows authenticated users to do so.
There are entire services out there built around providing this kind of thing, particularly for mobile apps.
You might store the users own credentials on the device, and if so it should be encrypted (but you're right, a malicious app could potentially pick them up).
Bottom line: never distribute hard coded access to a database directly.
What would be the least expensive and PaaS-agnostic ways to protect and separate sensitive data in a multi tenant application which is using a shared database?
Some background info and more specific questions:
We are a small startup company. We have successfully launched an intranet web application project for a customer, and now we feel ready to offer a cloud solution for similar kinds of customers.
As we are on Microsoft BizSpark program, we are investigating Azure App Services. We might migrate later to Cloud Services, but for now it seems that App Services will be enough. Still, we don't want to tie ourselves to Azure too much in case we would want to move to other SaaS provider later.
Our application will store some sensitive information which should be protected. Separate encrypted (Azure provides transparent encryption) databases for each tenant would offer the most security, but we have no budget for such solution and it would be hard to manage automatically.
Currently our plan is that we will offer our customers to register a subdomain under our wildcard domain and then internally we map the subdomain to tenant ID which will be used in each table.
This seems to be the most cost-effective solution for a startup company because there are no additional management for every additional tenant, and registration can be fully automatic. I understand that we'll have to be super careful to enforce the use of tenant ID in every SQL request (using SQL views and stored procs with built-in tenant ID query will help), but that's obviously is not enough. We need some mechanism to protect each tenant's sensitive data with some encryption key.
And then some questions come:
should we use a single encryption key for all the sensitive data for all tenants? or should we have a separate key for each tenant?
if we go for separate keys (generated randomly at the moment of registration, so the key won't be known even for us), then who and how should store and protect the tenant encryption key? Should we give the key to the tenant and then ask his employees to provide the key in addition to each employee's login name and password every time they log in through web browser?
what approach would work best considering that we might later need sharding or "elastic" database scaling as some PaaS providers call it, and that we might move from Azure and Microsoft SQL Server to something else?
If someone has experience with multi-tenancy & database protection, I'd really appreciate some advice, some do's and dont's and possible caveats. I have read some articles about the topic but they often are too specific to PaaS platforms or do not explain possible consequences and difficulties, but that knowledge comes only from day-to-day experience and trials&errors.
Adding some answers for completeness sake (2yrs later):
should we use a single encryption key for all the sensitive data for all tenants? or should we have a separate key for each tenant?
You should have a separate key for each tenant. Not sure how Azure does it but AWS has KMS for this usecase
if we go for separate keys (generated randomly at the moment of registration, so the key won't be known even for us), then who and how should store and protect the tenant encryption key? Should we give the key to the tenant and then ask his employees to provide the key in addition to each employee's login name and password every time they log in through web browser?
Use KMS (or something similar on other clouds, homegrown solution like Square's keywhiz). You don't need to give the key to tenant. All you care about is - if the user has authenticated using their password (or SSO), based on their permissions, they have access to some resources.
what approach would work best considering that we might later need sharding or "elastic" database scaling as some PaaS providers call it, and that we might move from Azure and Microsoft SQL Server to something else?
You need a tenantId which will help with data isolation. Now the actual data linked to tenantId can be encrypted based on a key stored in KMS.