|
The Junior wrote: The exercise is to expect that the client authentication itself is "100% secure", using a personal device, probably like the banking device you're talking about. So that part is kinda moot and OT.
Once you are sure of that, securing the server is simple.
If only authenticated clients can download, not much can go wrong, as long as they don't store that data.
You seriously need to make an inventory of possible attacks and weak points - that's how you secure a server. Not just by stacking imaginary locks.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
But it still doesn't really answer how we can encrypt the files on the server so that a potential hacker can't read the files even with root/rdp access.
That's a part of GDPR, to write down any possible/potential weaknesses, they even point at "how to secure data that someone has their hands on", for example a hard drive, direct access to a server/computer/database and so on. For the Database we're using Alwasy Encypted, with card readers and access keys in order to gain access. And the drive it resides on is locked using BitLock+USB. The communication between the server/client is using SSL with Reliable Sessions and authenticated using a personal Banking Device.
Final part is to limit access to the files available on the server, if the server is compromised. Hence, the two set keys idea we had.
And after reading the GDPR documents, it's all about locks, smoke and mirrors.
|
|
|
|
|
Correct, because that problem no longer exists once you successfully limit access 
Once the hacker has root/rdp to the server you're screwed, regardless of your clever intentions. That is, unless the server knows nothing about how to "read" the data it is serving - in which case you opt to put that secret (how to read the data) onto all its clients.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
So, in the split key solution I posted, how would a hacker with access to the server know the client part of the key? It's never sent to the server.
The hacker would have access to the server key, but it wouldn't be able to decrypt anything using that.
|
|
|
|
|
In your split-key solution, the secret is on the client. That would be my attack-vector, since it needs both parts to read the data.
Since you have no control over the clients, they'd likely be more vulnerable than the server anyway (think auto-updates being turned off, people browsing some interesting sites, people using USB-sticks with malware etc) and I'd have a lot more places that I could potentially break into, seeking out the weakest.
Instead of one security problem, you now have a problem on every client, on hardware that is outside of your control
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Yes, but each client only has access to a handful of files.
If it's a matter of limiting a potential threat, say it's about your own money, would you prefer losing $100, or $1,000,000?
While both are bad, I'd take the first over the later any day.
So it's threat assessment, what is more likely:
A hacker finding every single client in the world, hack each system to get root access and then have access to all data, forgot, he also needs to everyones banking device.
Or, hack one server, instantly gain access to everything.
|
|
|
|
|
You're focussing too much on a single aspect, and you're solution sounds simply like providing a dropbox-like service, where the server simply doesn't know the data and other clients cannot read it.
The Junior wrote: A hacker finding every single client in the world, hack each system to get root access and then have access to all data, forgot, he also needs to everyones banking device.
If you store the decryption keys on the client, I do not need the banking device. I'll be content enough to read the local data
The Junior wrote: Or, hack one server, instantly gain access to everything.
Yes, if it is simple storage where the server doesn't know anything, and data is not shared, dropbox it is 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Quote: If you store the decryption keys on the client, I do not need the banking device. I'll be content enough to read the local data Smile |
Without the banking device, you'll only be able to read the data read during that session. Well, unless like you said, you install memory logger device to read the data from the computer memory while the client is looking at the file (it's not saved on the client, only presented, during the session)
With the banking device you'd be able to get hold of the files (only pdf and images), available for the account, if you know the file ID's.
And I'm focusing on this part because it's the description of the exercise AND GDPR. 
How would you limit the impact if a potential hacker gets hold of your server or client.
Quote: Yes, if it is simple storage where the server doesn't know anything, and data is not shared, dropbox it is
Well, not really. One user can upload a file, specify who/what group can get access to that file. The server has no need to know what the file is, but multiple clients will access the file.
The server only cares about who the uploader was and who's allowed to view the file. There's no need for the server to know more than that.
Like I said, the threat we see is someone gaining access to the server, how would we limit the harm and how would one encrypt the files so that a potential hacker can't read them all, but still allow users to be able to view the files they are authorized to view.
But if you're saying that the best way to handle this is to have the keys on the server alone I'll take your word for it, I'm anything but a pro.
|
|
|
|
|
The Junior wrote: And I'm focusing on this part because it's the description of the exercise AND GDPR.
Ah; I'm done excercising
The Junior wrote:
But if you're saying that the best way to handle this is to have the keys on the server alone I'll take your word for it, I'm anything but a pro.
I did not say that; in the classic dropbox-scenario the server doesn't need any part of the key. Why would it? If it is the clients data and it is only for sharing bytes, than the server need nothing of the key. Or simpeler terms, I can zip & password protect a file, put it on a share at the Google cloud and still determine who has access, without google needing any part of my password.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Is this a school exercise, or a real world application?
Because if it's the later, you shouldn't be getting advice from an insecure website - you need to employ a good security consultant (as a contractor is probably fine) because you are wading hip-deep into a minefield! Get it wrong because you don't know enough and miss something and you are into a world of litigation; both from patients who are misdiagnosed because vital files couldn't be retrieved, and from the media / governments if medical info is released inappropriately. This is not a simple task, and needs very careful handling.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Updated my first question to make everything more clear.. I hope.
modified 28-Feb-18 8:27am.
|
|
|
|
|
A "random" client and file that needs "decrypting"...
That's where your whole thought process falls apart. You can have "anon"; but not "random".
You issue "security keys" (e.g. Guid's); one per machine mac / ip / email.
A security key entitles you to a download. You get to track who is using which keys and how often.
Keys can be linked to "trial versions", boxed versions, "expired" versions.
One form of "software protection" is frequent updates (with newer and better features).
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
The below commnand ran successfully when i click the respective button but no changes on the database
SqlCommand command = new SqlCommand("select distinct * into #tmp From bounce delete from bounce insert into bounce select * from #tmp drop table #tmp)", connection);
connection.Close();
MessageBox.Show("Cleared Duplicates");
Note: Table bounce having only one column called email to remove the duplicates I created this button function
|
|
|
|
|
Change the table.
Never have a table with one column: always include an ID column to ensure that you can uniquely identify a row, regardless of the content.
Add an INT, IDENTITY column to the table called ID
Then the query is trivial:
DELETE m FROM MyTable m
INNER JOIN MyTable d ON m.ID > d.ID AND m.Email = d.Email;
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Thanks for your suggestion
|
|
|
|
|
You're welcome - trust me, you only make extra work for yourself by not having an ID column in every table!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
That did not run at all. Nowhere did you state a command.ExecuteNonQuery(). It will crash: that's terribly malformed SQL, so much that I cannot guess what you plan to do.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
Thanks,
after command.ExecuteNonQuery() this line I am getting error called
a local variable name connection is already defined in this scope and I checked my code only once I used the variable connection. kindly help me on this.
For the below code
SqlCommand command = new SqlCommand("truncate table clean"), connection);
connection.Open();
command.ExecuteNonQuery();
connection.Close();
MessageBox.Show("Cleared All data");
I am getting error
a local variable name connection is already defined in this scope
If the sql commanand to
SqlCommand command = new SqlCommand("truncate table clean)", connection);
getting an error
Incorrect syntax near ')'.
|
|
|
|
|
Shankar M wrote: getting an error
Incorrect syntax near ')'.
Remove the ) after clean.
This space for rent
|
|
|
|
|
Thanks for your suggestion
|
|
|
|
|
Which unit testing framework for C# can create unit tests automatically?
|
|
|
|
|
What do you mean by creating unit tests automatically? Are you referring to tests like PEX and MOLES or Intellitest?
This space for rent
|
|
|
|
|
I mean that I have a code that contains some methods...
I'm looking for a tool that would go over my code and create unit tests for the methods automatically... Does a tool like that exist in the market?
|
|
|
|
|
To a certain extent, yes it does (see the links in my original post to PEX and Moles from Microsoft research). The real question is, how much value do these tools provide? For instance, it's simple enough to automatically check whether or not a value is null but what about range checks? Would a tool know that your code expected a value between 0 and 5? Don't fall into the trap of just blindly adding tests, which is the problem with this idea. Your tests should really be there to exercise the expected logic of your code; for instance, if you changed the acceptable range from 0 to 6 and passed 6 into the code expecting the test to follow the fail path, it would suddenly follow a different path through your code so you would know that your test needs to change.
This space for rent
|
|
|
|
|
No framework can predict your expected results; so there's no such thing as creating tests automatically.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
