I am using Azure IoT Edge where I am using Azure SQL Edge module from the marketplace. I have another module written in Python which makes a connectivity with the SQL Server module on the IoT edge device. To make the connection, I have to hardcode the SQL password in the code.
I thought of storing SQL password on Azure KeyVault and pull it in Python module on edge while making SQL connectivity though this would defeat the purpose of edge. What if there is no internet connection for a while and my module will stop working.
Is there a safe way to store the SQL password on the IoT edge device or What is the recommended way to make the connection on edge? Please advice. Thanks.
I guess you are talking about Azure SQL Edge module. Just wanted to ask how is the device secured? Is it using the TPM, X.509 or Symmetric keys?
Also can you please let me know if the default password was already change to a strong password? Usually, when you change the default password for MSSQL_SA_PASSWORD to a strong password, it is more than enough as no one will have access to the device if it has been secured.
Refer to this document for more clarification -
https://learn.microsoft.com/en-us/azure/azure-sql-edge/deploy-portal#connect-to-azure-sql-edge
Related
I have a Ruby on Rails application with a database that stores sensitive user information (hashed with Devise). I now need to pass some of this sensitive information to another internal service on another server that needs it to make calls to third party APIs, so it needs a way to request that information from the RoR app.
What's the best approach to something like this? My first intuition was to grant an internal API key that would grant access to all sensitive information in the DB (via a private endpoint), the same way developer keys give access to a subset of API endpoints. Is this secure enough as long as I hash the API key? What's the best approach to passing sensitive information around through internal services?
Private APIs
My first intuition was to grant an internal API key that would grant access to all sensitive information in the DB (via a private endpoint), the same way developer keys give access to a subset of API endpoints
Well private endpoints or private APIs don't exist in the sense of only protecting them by using an API key. From a web app you only need to see the html source code to be able to find the API keys. In mobile devices you can see how easy is to reverse engineer API keys in this series of articles about Mobile API Security Techniques. While the articles are in the context of mobile devices, some of the techniques used are also valid in other type of APIs. I hope you can see now how someone could grab the API key and abuse from the API you are trying to secure.
Now even if you don't expose the API key in a mobile app or web app, the API is still discoverable, specially if the endpoint is served by the same API used for the other public endpoints. This is made even easier when you tell in robots.txt that bots should not access some of the endpoints, because this is the first place where hackers look into for trying to enumerate attack vectors into your APIs.
Possible Solutions
Private API Solution
What's the best approach to something like this? My first intuition was to grant an internal API key that would grant access to all sensitive information in the DB (via a private endpoint)
In order to have a private API the server hosting it needs to be protected by a firewall and locked to the other internal server consuming it with certificate pinning and maybe also by IP address. In order to be able to properly secure and lock down the internal server hosting the supposed private API it MUST not support any public requests.
Certificate Pinning:
Pinning effectively removes the "conference of trust". An application which pins a certificate or public key no longer needs to depend on others - such as DNS or CAs - when making security decisions relating to a peer's identity. For those familiar with SSH, you should realize that public key pinning is nearly identical to SSH's StrictHostKeyChecking option. SSH had it right the entire time, and the rest of the world is beginning to realize the virtues of directly identifying a host or service by its public key.
Database Direct Access Solution
What's the best approach to passing sensitive information around through internal services?
Personally I would prefer to access the database directly from the other server and have the database software itself configured to only accept requests from specific internal servers for specific users with the less privileges possible to perform the action they need. Additionally you would employ the firewall locking to and use certificate pinning between the internal servers.
Conclusion
No matter what solution you choose place your database with the sensitive data in server that only hosts that database and is very well lock-down to your internal network.
Anyone needing to access that sensitive data MUST have only read privileges for that specific database table.
I looking for a 2FA centralized solution, on Linux (Ubuntu) and Windows, who can use Data USB key as token, for example using UUID device for the token. (I read it's not that much secure but for start it will be fine for us).
The idea is to us it for a user authentication at OS login and after on other web application.
I install LinOTP for try but I don't found a way to do it. The best should be a Open Source solution.
Thank's for help
You could use the yubikey. It might be the most expensive solution, but it probably gets the job done, what you are looking for.
The yubikey 4 is a smartcard. You can simple create PGP keys on the yubikey and use this crypto to authenticate at your Linux login using pam_poldi. Simple and effective.
We also use the yubikey in HOTP mode and have initialized them with privacyIDEA. I wrote a blog article, how you could setup an enrollment stations.
This way you can use the same device for offline local login and for authentication at webinterfaces (using HOTP).
Note: You only need a backend like LinOTP or privacyIDEA for using the OTP part. If you want to use local authentication like PGP, neither LinOTP nor privacyIDEA does currently support this.
Disclaimer: Please note that I was involved with LinOTP and am the project founder of privacyIDEA.
I know that we can get access to Neo4j db remotely by adding IP addresses. I am wondering if Neo4j supports account verification like username and password to double increase the db security even though we log in at trusted IP.
In addition, can we set mulitple databases and switch them before we query some stuff? I know Neo4jCP can do it but it only supports windows. Is there any way else to do it and is it possible that Neo4j intergrates this feature?
Thank you!
Unfortunately out of the box Neo4j doesn't support multiple databases or user management or data level security.
You can add something like that in your application layer, or use a framework like http://structr.org which provides user-management and data level security.
I'd like to authenticate the caller of my SOAP webservice (deployed in Ruby 1.8.7/Rails 2.3.5using datanoise gem in Red Hat enterprise linux 5) using some encrypted tag in the XML requests. Normally the client is a windows program (maybe C#/.Net windows programs - not Java/Ruby) which should generate a varying encrypted key in each call to the webservice based on a key/salt - while my server side would always be able to decode it with the private key. Knowledge of the encrypted token on the wire should not allow a third-party program to simply replicate the fully encrypted token and access the webservice. I am looking into OpenSSL but am a newbie to cryptography. The string being encrypted for identification could be (among other items) the MAC ID of the trusted client, which when decrypted would match the stored value on the server side of the trusted hosts.
I've found lots of possibilities on the Ruby side, but need to ideally ensure that the solution does not impose (or minimizes) any library or installation requirement on the windows client side. What i'm most struggling with is a way to generate a new key each time the call is made, so that anyone sniffing the traffic cannot simply infer the mode to create the encrypted tag by getting access to the key.
As you are authenticating the caller here and not necessarily just the contents of what they send, there's no need to put the authentication mechanism into the SOAP request. Others have tried to do what you are after with WS-Security, so if at all, I'd go with that.
There have been problems with the security of the scheme, though, but probably the biggest deal breaker is that there's no support for it available in Ruby (that I know of at least, please correct me if I'm wrong!).
Probably the easiest way to achieve client authentication on both ends would be using mutually authenticated TLS (the former SSL). This will ensure authentication on the transport level, which should suffice in your case. Actual authentication will then happen by first checking the validity of the certificate that is sent by the client (Ruby OpenSSL takes care of that for you), and once that is established, you check it against a white list of known certificates that you maintain on your server.
Please don't invent your own scheme, cryptographic protocols are among the hardest things to get right (that's why there are problems with WS-Security), TLS is probably as good as it gets right now and it has broad support in any language.
I hate to re-invent the wheel so I'm looking for an existing solution to create a simple authentication system for my application. I've experimented for a while with using CardSpace or OpenID inside the application but I can't convince management that these would be working solutions.
Of course, I could just build a simple login dialog where username, domain and (hashed) password is stored inside a database table and I've done such a thing many times already. I hate this solution since I feel it's just a weak option. And I don't want to spend too much time trying to make the whole logon system as secure as possible, especially since I suspect that there should be existing solutions for this.
So, next to OpenID/OpenAuth and CardSpace, are there any other Authentication solutions that can be used from a Delphi/WIN32 application?
Right now, the application will be used by many customers. Most are single-user environments, although it's likely that some of those will start to have two to 5 users once this authentication system is added. But we want to support a customer who needs to allow about 500 different users on the same application. These are spread over about 100 offices but they all connect to the same SQL Server database. (MS Access right now, but we're making it possible for this user to use SQL Server instead.) To make matters even more interesting, the customer uses Citrix to centralize the user systems and the application has straight access to the SQL Server database. It's not an ideal setup but then again, the customer isn't really paying for this. We're just setting up a test environment. A proof-of-concept which the customer will test for us. Flaws will be solved later on. But right now I need quick solutions and one of them is a practical authentication system where I don't have to write a lot of code.
Have you considered using SQL Server authentication and not allowing authentication for those using an Access Database?
If you use the new SQL Server Native Client and SQL Server 2005 you can have passwords expire and change them from your client application. All of the tools to create and manage user accounts are built into SQL Server Management Studio. And if you decide later to support Windows Authentication you just need to modify your connection string.
We have a system where users on the network use Windows Authentication so they don't need to worry about another user name and password. For users that access the system via a VPN and non-domain joined machines they use SQL Authentication.
Here is the MSDN Page that talks about dealing with passwords programmatically in SQL Server 2005
You do need to make sure that SQL Server Native Client is installed, but that is simple compared to the rest of ADO.
I would suggest then
Delphi - since you are using Delphi :)
Open source - since you need to be able to figure out what is wrong if there is a problem, you probably want it cheap.
So, here are some solutions:
http://www.torry.net/pages.php?id=313
CoWindowsAccount v.1.0
SSecurity v.1.2.1.3
http://free-password-manager-plus.software.informer.com/1.6/
It might work for your purposes, but why not ask Windows for the current domain and user name, and use them as unique IDs. Windows has already done the authentication, and it saves the users making up new passwords or anything. I've used this to good effect. I also made it optional to include the machine name in the ID, so that the same user on different computers would also be unique.