Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. The Lounge
  3. Hiding the key

Hiding the key

Scheduled Pinned Locked Moved The Lounge
questioncsharpasp-netdatabasevisual-studio
21 Posts 11 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M MSBassSinger

    Hi all, I have a question based on the below hypothetical scenario. I have an Azure based system comprised of: Web app (Blazor) Multiple Azure functions A set of C# library NuGets written to support shared code Azure SQL Internal-only APIM External APIM (for mobile apps and third Party subscriptions) Azure Front Door Various Azure services, like Key Vault, Azure Storage, etc. ADO DevOps (incl. ADO Git repos, not GitHub, pipelines, artifacts, testing, etc.) ADO Boards for case management Developers use VS 2022 with access Secure information that apps use like keys, usernames/passwords, etc. are stored in a key vault. Now, for the question. What process do you recommend for the apps (not directly publicly accessible other than port 80 HTTP for the web UI) to access the key vault without leaving any keys in config files that could be compromised? I know what I think, but if I knew everything 100% correctly, I probably wouldn’t be here. 🙂 Thanks in advance.

    B Offline
    B Offline
    BernardIE5317
    wrote on last edited by
    #8

    this is what chatGBT has to say :

    Quote:

    To securely access the Key Vault from your applications without exposing the secrets in config files, you can leverage Azure Managed Service Identity (MSI) feature. Managed Service Identity (MSI) is a feature of Azure Active Directory that provides Azure services with an automatically managed identity in Azure AD. With MSI, Azure services can authenticate with other Azure services that support Azure AD authentication, without requiring you to manage any secrets or credentials. The process for accessing the Key Vault using MSI can be summarized in the following steps: Enable the MSI feature for your Azure App Service/Web App: Enable the system assigned identity for your Web App by turning it on in the Identity blade of your Web App. Add access policy to Key Vault: Once MSI is enabled, navigate to your Key Vault, select the Access policies blade, and add the necessary permissions to allow your Web App to access the Key Vault. Modify your code to use MSI to authenticate with the Key Vault: In your code, you can use the Azure.Identity NuGet package to authenticate with the Key Vault using the MSI endpoint. Here's some sample code that demonstrates how to access a secret in a Key Vault using MSI:

    var credential = new DefaultAzureCredential();
    var client = new SecretClient(new Uri("https://{keyvault-name}.vault.azure.net/"), credential);
    KeyVaultSecret secret = await client.GetSecretAsync("secret-name");
    string secretValue = secret.Value;

    M T 2 Replies Last reply
    0
    • M MSBassSinger

      Hi all, I have a question based on the below hypothetical scenario. I have an Azure based system comprised of: Web app (Blazor) Multiple Azure functions A set of C# library NuGets written to support shared code Azure SQL Internal-only APIM External APIM (for mobile apps and third Party subscriptions) Azure Front Door Various Azure services, like Key Vault, Azure Storage, etc. ADO DevOps (incl. ADO Git repos, not GitHub, pipelines, artifacts, testing, etc.) ADO Boards for case management Developers use VS 2022 with access Secure information that apps use like keys, usernames/passwords, etc. are stored in a key vault. Now, for the question. What process do you recommend for the apps (not directly publicly accessible other than port 80 HTTP for the web UI) to access the key vault without leaving any keys in config files that could be compromised? I know what I think, but if I knew everything 100% correctly, I probably wouldn’t be here. 🙂 Thanks in advance.

      K Offline
      K Offline
      kmoorevs
      wrote on last edited by
      #9

      Maybe you shouldn't hide the key, just encrypt it. The apps should know where the keys are and how to decrypt them. As a real-world example, I need the ability for hundreds of customer desktop apps to be able to utilize one or more FTP resources, and also need the ability to change the credentials for those resources 'on the fly'. Those credentials are actually stored on a publicly accessible website in an XML file with very unassuming names/tags and, of course, encrypted. My 2 cents. :)

      "Go forth into the source" - Neal Morse "Hope is contagious"

      M 1 Reply Last reply
      0
      • K kmoorevs

        Maybe you shouldn't hide the key, just encrypt it. The apps should know where the keys are and how to decrypt them. As a real-world example, I need the ability for hundreds of customer desktop apps to be able to utilize one or more FTP resources, and also need the ability to change the credentials for those resources 'on the fly'. Those credentials are actually stored on a publicly accessible website in an XML file with very unassuming names/tags and, of course, encrypted. My 2 cents. :)

        "Go forth into the source" - Neal Morse "Hope is contagious"

        M Offline
        M Offline
        MSBassSinger
        wrote on last edited by
        #10

        I have done that before, but the issue still remains that the decryption key for that still has to be accesible to the app. And thus, accessible by another person.

        1 Reply Last reply
        0
        • B BernardIE5317

          this is what chatGBT has to say :

          Quote:

          To securely access the Key Vault from your applications without exposing the secrets in config files, you can leverage Azure Managed Service Identity (MSI) feature. Managed Service Identity (MSI) is a feature of Azure Active Directory that provides Azure services with an automatically managed identity in Azure AD. With MSI, Azure services can authenticate with other Azure services that support Azure AD authentication, without requiring you to manage any secrets or credentials. The process for accessing the Key Vault using MSI can be summarized in the following steps: Enable the MSI feature for your Azure App Service/Web App: Enable the system assigned identity for your Web App by turning it on in the Identity blade of your Web App. Add access policy to Key Vault: Once MSI is enabled, navigate to your Key Vault, select the Access policies blade, and add the necessary permissions to allow your Web App to access the Key Vault. Modify your code to use MSI to authenticate with the Key Vault: In your code, you can use the Azure.Identity NuGet package to authenticate with the Key Vault using the MSI endpoint. Here's some sample code that demonstrates how to access a secret in a Key Vault using MSI:

          var credential = new DefaultAzureCredential();
          var client = new SecretClient(new Uri("https://{keyvault-name}.vault.azure.net/"), credential);
          KeyVaultSecret secret = await client.GetSecretAsync("secret-name");
          string secretValue = secret.Value;

          M Offline
          M Offline
          MSBassSinger
          wrote on last edited by
          #11

          Someone trained the AI bot well. That is what I do when I design the system. I find that "in the wild", a lot of shops don't.

          1 Reply Last reply
          0
          • P PIEBALDconsult

            The domain performs authentication for the user. The user provides the username and password to the domain.

            M Offline
            M Offline
            MSBassSinger
            wrote on last edited by
            #12

            And the user can share their password, have it hacked, etc. Still not secure.

            P B 2 Replies Last reply
            0
            • M MSBassSinger

              And the user can share their password, have it hacked, etc. Still not secure.

              P Offline
              P Offline
              PIEBALDconsult
              wrote on last edited by
              #13

              As has always been the case. The user has to know his/her password and might write it on a sticky note or something. That can never be fully secure. Consider a building with many doors and the janitor has copies of all the keys, locked in a box. But the key for that box can't be in the box, it has to be somewhere else, usually in the janitor's pocket. If that one key gets stolen, the thief has access to all of the other keys. The janitor can lock the lockbox key in another box, but then the key to that box might get stolen. It's never-ending. There will always be some nth item which might get stolen and may then provide access to all of the other items like dominos. I have no idea how someone can possibly think that anything can be fully 100% secure. The concept is a fallacy.

              M 1 Reply Last reply
              0
              • P PIEBALDconsult

                As has always been the case. The user has to know his/her password and might write it on a sticky note or something. That can never be fully secure. Consider a building with many doors and the janitor has copies of all the keys, locked in a box. But the key for that box can't be in the box, it has to be somewhere else, usually in the janitor's pocket. If that one key gets stolen, the thief has access to all of the other keys. The janitor can lock the lockbox key in another box, but then the key to that box might get stolen. It's never-ending. There will always be some nth item which might get stolen and may then provide access to all of the other items like dominos. I have no idea how someone can possibly think that anything can be fully 100% secure. The concept is a fallacy.

                M Offline
                M Offline
                MSBassSinger
                wrote on last edited by
                #14

                Not 100%. Just reasonably secure. That is why Azure (and I am sure AWS and others) have the kind of authentication that doesn't require an app storing the means of authentication.

                1 Reply Last reply
                0
                • M MSBassSinger

                  Hi all, I have a question based on the below hypothetical scenario. I have an Azure based system comprised of: Web app (Blazor) Multiple Azure functions A set of C# library NuGets written to support shared code Azure SQL Internal-only APIM External APIM (for mobile apps and third Party subscriptions) Azure Front Door Various Azure services, like Key Vault, Azure Storage, etc. ADO DevOps (incl. ADO Git repos, not GitHub, pipelines, artifacts, testing, etc.) ADO Boards for case management Developers use VS 2022 with access Secure information that apps use like keys, usernames/passwords, etc. are stored in a key vault. Now, for the question. What process do you recommend for the apps (not directly publicly accessible other than port 80 HTTP for the web UI) to access the key vault without leaving any keys in config files that could be compromised? I know what I think, but if I knew everything 100% correctly, I probably wouldn’t be here. 🙂 Thanks in advance.

                  M Offline
                  M Offline
                  MikeCO10
                  wrote on last edited by
                  #15

                  I'm not sure that's a concern, in the big picture. If a bad actor has access to any well designed key strategy, you have bigger problems than worrying about the key, no? They would probably have enough access to dis-own you of your system.

                  1 Reply Last reply
                  0
                  • M MSBassSinger

                    Hi all, I have a question based on the below hypothetical scenario. I have an Azure based system comprised of: Web app (Blazor) Multiple Azure functions A set of C# library NuGets written to support shared code Azure SQL Internal-only APIM External APIM (for mobile apps and third Party subscriptions) Azure Front Door Various Azure services, like Key Vault, Azure Storage, etc. ADO DevOps (incl. ADO Git repos, not GitHub, pipelines, artifacts, testing, etc.) ADO Boards for case management Developers use VS 2022 with access Secure information that apps use like keys, usernames/passwords, etc. are stored in a key vault. Now, for the question. What process do you recommend for the apps (not directly publicly accessible other than port 80 HTTP for the web UI) to access the key vault without leaving any keys in config files that could be compromised? I know what I think, but if I knew everything 100% correctly, I probably wouldn’t be here. 🙂 Thanks in advance.

                    B Offline
                    B Offline
                    Bruce Patin
                    wrote on last edited by
                    #16

                    As per generally accepted usage, I put the key content on a yellow sticky note where my computer webcam can see it and route it up to the app. ;)

                    B 1 Reply Last reply
                    0
                    • M MSBassSinger

                      Hi all, I have a question based on the below hypothetical scenario. I have an Azure based system comprised of: Web app (Blazor) Multiple Azure functions A set of C# library NuGets written to support shared code Azure SQL Internal-only APIM External APIM (for mobile apps and third Party subscriptions) Azure Front Door Various Azure services, like Key Vault, Azure Storage, etc. ADO DevOps (incl. ADO Git repos, not GitHub, pipelines, artifacts, testing, etc.) ADO Boards for case management Developers use VS 2022 with access Secure information that apps use like keys, usernames/passwords, etc. are stored in a key vault. Now, for the question. What process do you recommend for the apps (not directly publicly accessible other than port 80 HTTP for the web UI) to access the key vault without leaving any keys in config files that could be compromised? I know what I think, but if I knew everything 100% correctly, I probably wouldn’t be here. 🙂 Thanks in advance.

                      S Offline
                      S Offline
                      Slow Eddie
                      wrote on last edited by
                      #17

                      I may be missing something, but why wouldn't 2 factor authentication work?

                      Just call me obtuse...

                      1 Reply Last reply
                      0
                      • B BernardIE5317

                        this is what chatGBT has to say :

                        Quote:

                        To securely access the Key Vault from your applications without exposing the secrets in config files, you can leverage Azure Managed Service Identity (MSI) feature. Managed Service Identity (MSI) is a feature of Azure Active Directory that provides Azure services with an automatically managed identity in Azure AD. With MSI, Azure services can authenticate with other Azure services that support Azure AD authentication, without requiring you to manage any secrets or credentials. The process for accessing the Key Vault using MSI can be summarized in the following steps: Enable the MSI feature for your Azure App Service/Web App: Enable the system assigned identity for your Web App by turning it on in the Identity blade of your Web App. Add access policy to Key Vault: Once MSI is enabled, navigate to your Key Vault, select the Access policies blade, and add the necessary permissions to allow your Web App to access the Key Vault. Modify your code to use MSI to authenticate with the Key Vault: In your code, you can use the Azure.Identity NuGet package to authenticate with the Key Vault using the MSI endpoint. Here's some sample code that demonstrates how to access a secret in a Key Vault using MSI:

                        var credential = new DefaultAzureCredential();
                        var client = new SecretClient(new Uri("https://{keyvault-name}.vault.azure.net/"), credential);
                        KeyVaultSecret secret = await client.GetSecretAsync("secret-name");
                        string secretValue = secret.Value;

                        T Offline
                        T Offline
                        TNCaver
                        wrote on last edited by
                        #18

                        BernardIE5317 wrote:

                        leverage Azure Managed Service Identity (MSI) feature

                        This is the proper way to use KeyVault.

                        There are no solutions, only trade-offs.
                           - Thomas Sowell

                        A day can really slip by when you're deliberately avoiding what you're supposed to do.
                           - Calvin (Bill Watterson, Calvin & Hobbes)

                        1 Reply Last reply
                        0
                        • M MSBassSinger

                          And by what is the app validated to the KV, and where is that stored outside the KV where the app can access it?

                          A Offline
                          A Offline
                          Andreas Mertens
                          wrote on last edited by
                          #19

                          You would probably use Active Directory, with the app running under an account (you can have the system generate one), then providing read access to the Key Vault for that account.

                          1 Reply Last reply
                          0
                          • M MSBassSinger

                            And the user can share their password, have it hacked, etc. Still not secure.

                            B Offline
                            B Offline
                            bryanren
                            wrote on last edited by
                            #20

                            That is where MFA comes in. MS Authenticator or other. Differing levels of engagement there: -Are you trying to log in?, (yes that's me) - logging in, after userid and pwd validate, Authenticator chirps with yes or no -What number is on the screen, (42) - login shows a number, type it into the app -Which number is on the screen, (11, 34, 78) - login show a number, app shows choices, pick the right one -Enter the code on Authenticator app (010 767) - app gens a number, enter it into login dialog I am sure there are other options and there are other products. How you set it up - IDK - victim not perp. b

                            1 Reply Last reply
                            0
                            • B Bruce Patin

                              As per generally accepted usage, I put the key content on a yellow sticky note where my computer webcam can see it and route it up to the app. ;)

                              B Offline
                              B Offline
                              Br Bill
                              wrote on last edited by
                              #21

                              Oh man, but then you gotta add an OCR library to the application, and maybe some Google photo captchas. :laugh:

                              1 Reply Last reply
                              0
                              Reply
                              • Reply as topic
                              Log in to reply
                              • Oldest to Newest
                              • Newest to Oldest
                              • Most Votes


                              • Login

                              • Don't have an account? Register

                              • Login or register to search.
                              • First post
                                Last post
                              0
                              • Categories
                              • Recent
                              • Tags
                              • Popular
                              • World
                              • Users
                              • Groups