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 8 years ago.
Improve this question
I'm sorry if this is the wrong place to put this, but since I normally code in C#, and my potential solution would involve using C# I figured this would be the best place to start.
I've been given a task at work to allow our customers the ability to transmit confidential record information from their office to our in-house, or possibly a new cloud-based, server.
I have been rather adamint that to transmit said data, a SSL certificate must be aquired by us through a third party. But I'm wondering if that really is true.
The more I researched SSL certificates the more I've come to realize that all they really are is one company vouching for another. The encryption (even on an expired certificate or on a self-signed certificate) works and the encryption is just as secure as one that isn't. Sure, the user is presented with nasty icons and red screens showing that "hey! this may not be safe!" But if the user doesn't visit a "https" prefixed website and only visits a "http" website, what would be wrong with encrypting data client-side, submitting it to our server, decrypting it server side and vice-versa?
Encryption is encryption right?
Or what if a WinForms app was created that did the same as above? Encrypt data, submit it to our servers and the servers decrypt it.
I just can't justify paying thousands of dollars a year to have Verisign, or whoever, issue us a certificate when 99% (I'm willing to bet) of the users on the internet don't even bother checking the validity of the certificate.
I obviously want to make sure everything IS secure, and I'm not downplaying the role of SSL certificates or keeping things secure, but I just fail to see the logic behind aquiring one, if the same type of encryption can be achieved in-house with better control and, if you ask me, better security.
Any thoughts or opinions?
You need to learn about MITM attacks, which require some form of authentication to prevent.
If you just use a self-signed certificate, an attacker can impersonate your server and send his own self-signed certificates, and your clients won't know anything is wrong.
If you just encrypt data in Javascript, an attacker can easily modify the Javascript to send him a copy of the plaintext first.
If you already have a secure channel to distribute the client (eg, WinForms) app, you can use certificate pinning and your own CA instead of paying for an SSL certificate. However, this involves more work on your part (remember to handle revocations).
Also, in order to securely distribute the app in the first place, you'll still need SSL. (or an attacker can rip out all of your crypto code before it runs)
I'm not sure what kind of data you are trying to send, but you could certainly avoid using a website altogether to send and receive data. The strategy could be something like:
Client:
WinForm (data entry) -> SFTP server
Server:
SFTP server -> Windows Service -> SQL Database
You would just have to setup the SFTP service and deploy your WinForm and Windows Service securely.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
The functions hosted in my Function app are consumed by an Client UI application. The functions have Function level authorization. So, a function-key needs to be sent while calling function in the request header or the URL itself. Hence, key is not safe and is exposed while the call is in transit and to whoever uses the client application. How can I make the key not visible in the application?
How can I make the key not visible in the application?
By not using the key in the front-end. Anything sent from the front-end is visible to the user using it.
How can I encrypt or make the key safe when the request is travelling to the Function app so it will not intercepted and details of key would not be compromised?
You use HTTPS (TLS) for the connection.
You cannot hold secrets in a front-end UI application.
The app cannot authenticate itself since it is running in an untrusted environment.
The app should in my opinion call either an endpoint that does not require authentication at all or requires the user to authenticate.
With the latter option you then verify the authentication token for the user in your function.
Or you could use IP address filtering that only allows specific users' IP addresses access to the back-end.
This is not 100% secure though since IP addresses can be re-assigned to other people and also degrades the user experience.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have a number of projects developed in WinForms. Despite looking around on SO and other areas I've not really found a satisfactory answer.
The projects make use of the app.config and are deployed to multiple users using ClickOnce. Each physical install on a users machine will have both the deployed application as well as the app.config. The app.config holds credentials for a restricted account for a database.
Is it possible to encrypt data such as credentials for a Db connection in WinForms that is deployed to the masses? Some users work on laptops offsite, so a network connection wont always be available. I'm just trying to find out what the best practices are for securing a WinForms application might be in this scenario.
Of course you can save the credentials as an encrypted string in your app.config. SO provides some good examples on how to use the System.Security.Cryptography.Rijndael symetric algorithm.
This of course requires the same key to encrypt and decrypt the data. That key will be stored in the source code, and .NET sourcecode is not really save, everyone with the ability to use google and use a program with more than one button will be able to find it in the decompiled code and thus, it's only slightly more safe than just having the password not encrypted.
Most important is, that the credentials your app uses to access the database are only allowed to do what the app needs, so not like using SQL Management Studio to oben the DB and being able to reconfigure everything (Saw that once at a customer).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am currently working on an ASP.NET MVC 4.5.2 application. The application stores no really valuable data but in my opinion security should never be underestimated, even harmless data can get harmful in the wrong hands. So I decided to encrypt all user related data like chat messages and personal user data. I am using ASP.NET Identity to add users to the application. The user password is automatically hashed by the Identity Framework. But I wanted to go one step further and encrypt these datasets additionally, so that the password hash, e-mail address, username ... is also encrypted in the database. Every text message send by one application user to another should also be encrypted so that only the authorized users can read the content even if the database gets stolen.
After reading lots of articles about how to encrypt these datasets I decided to use something like AES or maybe other encryption algorithms. Encrypt and store data in a database is no big deal. The whole thing gets not really exciting until it comes to store the encryption keys. I've read a huge amout of tutorials and posts on plattforms like StackOverflow which discuss how to properly encrypt sensitive data, but most of the articles are ending without providing solid solutions on how to store encryption keys.
After some research I found some interesting answers from StackOverflow users on this topic:
PaulGs answer on "How to properly do private key management"
Vault by HashiCorp
The Vault is an open source project focusing on storing secrets. I want to provide these links here for other fellows searching for this topic but unfortunately my reputation is not high enough to add all links so I decided to provide only the two most relevant.
Reffering to PaulGs Answer...
[...] My implementation was to have a Key Server application running on a windows box. This application required entry of two separate 'key server master keys' before it could be used. These keys would be known only to the key server administrators. These keys are xor'd together to generate the Master Key, which is stored only in protected memory whilst the application is running. Application can then automatically generate cryptographically strong Key Encrypting Keys, which are stored in encrypted form using the Master Key. [...]
... my question is:
Edit:
How "good" is PaulGs procedure on a security point of view and how can I create "protected memory" as csharp developer? I hope this question is more specific as my last set of questions.
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 8 years ago.
Improve this question
What are the upsides to using an FTP server (hosted by a third party) to transfer (and maybe store) files when compared to just sending through email? The language of choice is C#.
Email looks easier to implement and if it was going to Gmail then server hosting and upkeep would not be a worry. However, I am not experienced with FTP servers and don't know how big of deal setup and upkeep is on them. All that is being sent is a bunch of text files, most likely each under 1 MB. Security is not a big deal at this point, but I am curious which is more secure without doing a lot of extra setup work.
Emailing means you have no guarantee that the file is received at the other end, or in a timely manner. Maybe this is not important for you? Emailing certainly would be easier to program up compared to FTP.
On the other hand if you use one of the many FTP libraries available for .NET then have complete control. You could include the library in a C# windows service to do the transferring seamlessly for you including exception (error) processing and notification.
Personally I'd take the opportunity to learn about FTP (its easy). You would of course require a FTP service to be setup on your server. All part of the learning.
I don't know your specific use case, but it sound like FTP is more appropriate than email for transferring and storing files. I mean it is called the "File Transfer Protocol" for a reason ;) The upside of FTP over Email is that it is designed for files while email is designed for email messages - it will be more difficult in automating the management of file attachments in email.
Setting up an FTP server is not difficult. Check out FileZilla:
https://filezilla-project.org/download.php?type=server
Sending files via FTP with C# is not difficult either. Here is question on that:
Upload file on ftp
BTW, again without knowing your requirements, there are also cloud services like Dropbox and Box.com that have APIs that might be even more appropriate for you.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I have been asked to develop a system that collects data from a Sql Server database and send that data in "some" format to a client as real-time as possible. The data is basic contact forms from a .net website. Names, phone numbers, email. No SSN type data.
The only parameters I know about the project are:
The client will probably want multiple ways to consume to data.
Excel, Rss readers, lead management systems, etc.
The client has
expressed zero concern for security.
I am not going to just ignore
security because the client doesn't care.
Full Disclosure: I am NOT a security expert.
I want to use some type of secure rss/xml feed because that would seem to offer the most options for the client to consume and it would be as real time as possible. However, many of the posts on this topic here at SO seem to suggest even with basic authentication and SSL, you are asking for trouble.
I could setup up a secure FTP download, but this doesn't seem to make sense as it would require the client to constantly check for incoming contact forms/leads.
If all else fails I could just email CSV files every 2 or 3 minutes but this does not seem very good either.
I guess my main question is: Is there another way I am missing or is a secure Rss/Xml feed OK for this application?
Thanks.
IF the client is known then you can secure this rather good with SSL.
Use SSL not only on the server side but on the client-side too by requiring the clients identify themselves with a certificate... that certificate is installed once on the machine of the client/boss/whoever and made known to your server.
For some information on how to do this with IIS see:
http://support.microsoft.com/kb/315588/en-us
read client certificate from httprequest C#
http://www.iis.net/ConfigReference/system.webServer/security/authentication/iisClientCertificateMappingAuthentication