|
It doesn't matter if it's Crystal Reports, a spreadsheet, a Word document, or just a letter to your Mum - all documents have "sections"
TM
______________
| Header |
|________|
| |
LM| Body |RM
| |
|________|
| Footer |
______________
BMTM, BM, LM, and RM are Margins - areas where you do not print (or not normally)
The Body is the area on the page where the actual content goes. Content flows from the Body of page 1 to the Body of page 2 seamlessly, and then continues in the Body of page 3, and so on
The Header and Footer are areas which are common to all pages (subject to special requirements) that are not part of the normal flow of content, and contain "metadata" such as a file reference, the page number, number of pages, production date, security classification, revision status, and so on. They do not contain content, they contain information about the content.
Whatever you put into the header or footer of any document will appear on all pages. You cannot put contecnt such as summary information there, that needs to be in the body of the document.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Fairly simple if I remember it correctly but you need to suppress the footer on all pages except for the last one:
right click on the page footer
go to Format text
write a conditional suppress formula.....
formula -----> PageNumber <> TotalPageCount;
|
|
|
|
|
You should be able to create sections in the body (see OGs reply) of the report, mode the summary out of the footer and into a section at the end of the body.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I need some help with an exercise. We've been asked to create a simple software to simulate GDPR compliance for a fake company that handles patient data.
The exercise itself required us to create:
> A secure database (done, Always Encrypted)
> Secure communication (done, SSL & Reliable Sessions)
> A way to store encrypted data on the server
Not sure how to best proceed with the third part. One client uploads a file, it should be stored encrypted on the server. A second client downloads that file and it should be decrypted.
Our idea was to store the key in two sets. The client software holds one part of the key. The Service holds the second part. After a client has been authenticated it sends a query to say GetKey() when it needs to en/de-crypt a file, using a SerializableSecureString. That string is then directly read into a SecureString on the client.
But I'm not sure if this is the best way to do it. Or, if a better solution would be do Encrypt/Decrypt the files on the server, storing any keys in DPAPI. The downside with that is, if an attacker gets hold of the server, by hacking rdp or something like tha,t it instantly gets hold of all files. If an attacker gets hold of a client machine, it will only get access to that users files and the files he/she can access.
Any ideas would be greatly appreciated.
/Updated for clarity to reduce OT replies. 
modified 28-Feb-18 14:07pm.
|
|
|
|
|
I think you are going to have to explain in more detail exactly what you are trying to do, and why you need this security - particularly where the source of the encryption keys is concerned.
As you know, encrypted data can't be decrypted without the key, so trying to get it client encrypted and different client decrypted without central key storage is going to be ... um ... problematic!
So we need to know a fair amount more about the whole idea and the relationship between the clients involved before we could begin to work out a suitable system.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Message Closed
modified 28-Feb-18 8:25am.
|
|
|
|
|
ZilverZtream wrote: over SSL and straight into a SecureString.
Which webrequest puts its result directly into a SecureString?
Also, given 100 clients, does that mean that the decryption keys are on EACH client, and not on the server? To "increase" security?
ZilverZtream wrote: And an attacker that gets hold of a client machine, would be forced to guess the Username/Password for the client login (not stored) and then guess the customer ID's & ID's of the files.
I don't like to guess; if I have physical access I'll simply introduce a hardware keylogger. If enough time to get behind the keyboard myself, a complete rootkit.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Quote: Which webrequest puts its result directly into a SecureString?
Also, given 100 clients, does that mean that the decryption keys are on EACH client, and not on the server? To "increase" security?
What I meant was, storing the reply from the service directly into a SecureString before disposing it. Since the service communication is SSL, the reply can't be sniffed, and my hopes was the using a SecureString to hold the reply, I could decrypt the file without exposing the full key.
And yes, half of the key anyway, would be the same on all clients. That's why I'm asking for ideas. I was just giving one of mine.. like I said, I don't know how to best do this.
If there's a way to do this on the server instead, with no way for a hacker to get access to the files, even if he/she gains access to say, TeamViewer or RDP and even the admin account of that server, I'd love to know how.
Quote: I don't like to guess; if I have physical access I'll simply introduce a hardware keylogger. If enough time to get behind the keyboard myself, a complete rootkit.
True, but one client has access to maybe 100-1000 possible "patients", while the system itself has millions. So it's still limiting the impact of a hack. Sure, if that hacker gets enough time, he could sit there, keylogging every ID that particular client has access to, it's still very few.
|
|
|
|
|
ZilverZtream wrote: So it's still limiting the impact of a hack. Sure, if that hacker gets enough time, he could sit there, keylogging every ID that particular client has access to,
I wouldn't be after the ID's, but the username and password of the client
See, much will stand and fall with authentication; can you trust the client to be the real intended client? If you can't be sure who you're talking to, then it will hardly matter how secure things are stored on the server.
Online banking requires me to pick up a small device, point it at a generated token, and enter a number generated by said device. That's a bit harder to recreate than a password. It is a separate device, not an app on a smartphone - you'd have to do a lot of expensive reverse-engineering to generate a viable password-token.
You'll have no control over the clients' security, so giving them keys that the client-computer can read might not be a great idea. Don't use them to store secrets.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
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.
The question is if anyone have any ideas or potentially a solution on how to store files as secure as possible on the server, while being able to have clients download and view the files, limiting a potential hack if possible.
We need to take the most secure way, depending on potential Pro's/Con's of the ideas we can come up with.
So far the only idea i can come up with is a two part key, split between the clients and the server.
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
