Hot answers tagged confidentiality
15
The worst thing you can do is tearing them apart. It's time consuming and attacker just needs extra time and patience to put pieces together.
The same rule applies for shredding - if after shredding are left too large pieces, again, attacker just needs time and patience.
There are several shredding techincs (from wikipedia)
Strip-cut shredders, ...
15
The HTTPS protocol is equivalent to using HTTP over an SSL or TLS connection (over TCP).
Thus, first a TCP connection (on port 443) is opened to the server. This is usually enough to reveal the server's host name (i.e. www.mysite.com in your case) to the attacker. The IP address is directly observed, and:
you usually did an unencrypted DNS query before,
...
13
As @Paŭlo Ebermann and @Jeff Ferland have told you, the GET request is encrypted under SSL and so is safe. However, don't forget that many web servers log GET requests and parameters, and any credentials or other sensitive information you send via GET could be written to a log somewhere. For that reason, you should use POST (which will also be encrypted ...
12
SSL serves three purposes (I'll use a snail-mail analogy to illustrate):
Keep the communication secret: prevent the mailman from reading your letters.
Verify that the communication is unaltered: prevent the mailman from altering your letters.
Verify the identity of the sender: prevent someone else from sending you letters under a false name.
Note that ...
11
Why even store it in a MySQL database when you can be using Authorize.Net's Customer Information Manager API and taking PCI compliance and security issues right out of your hands completely and letting them do all of the heaving lifting for you? CIM let's you create customer payment profiles by storing the customer's credit card information on their end and ...
10
On any Wi-Fi network - encrypted or not, given today's Wi-Fi encryption protocols - any sufficiently skilled and equipped user of the network (and especially the network administrator) could easily access any data you transmit or receive via cleartext protocols. This includes usernames and passwords as well as web pages, documents, and other data sent or ...
10
There are three meanings for "safety" here:
safe against eavesdroppers (confidentiality);
safe against malicious alterations and/or theft (integrity & availability);
safe against accidental alteration and/or loss (integrity & availability, also).
Amazon S3 is a service which strives at providing safety types 2 and 3, but not 1. However, their ...
10
None that I know of. And I believe this is because.. I don't think the solution (implied by the question) is a good solution/proposal.
Not only because hashing function may have collisions (even if it has a very low probability, the impact would be major, so why should we add such a risk ?) but also because you have another problem prior to hashing: unless ...
10
They will get a CA that is in the CA root zone for all browsers to issue them valid certificates. This CA will probably be a UK based company. Spying will be completely transparent to the users. Browsers will show no warnings. This will work for a few days, until it is detected by the public at which point browser vendors will revoke the root certificate of ...
9
On a theoretical point of view, an HTTPS site with a warning on the certificate is no better, but no worse either, than a plain HTTP site. As long as you only browse, reading data but not sending anything, and not especially trusting what you read, then you can ignore the warning. However, it is quite rare that a reading-only site goes to the trouble of ...
9
Keeping information in RAM can enhance security, if done right and if the requirements allow it. I'm going to show two security architectures where keeping the data in RAM provides a security benefit. These are fairly specific scenarios; most of the time keeping data in RAM doesn't help.
Protection against file dump attacks
Consider a web application that ...
9
To answer my own question:
It seems that some systems are, or rather were indeed insecure, leaking environment information to other processes.
A similar issue to the present one is raised on github by user 'mitchblank' for the 'mosh' application (mobile shell). The author writes:
Background: in the process image argv[] and envp[] are stored in the same ...
9
To a large extent, yes. See RFC 4880, section 5.1: for each recipient, there is a "Public-Key Encrypted Session Key Packet" which contains the recipient key ID. This key ID is a 32-bit value which is used as index in key servers; there are key ID collisions, so this is not an absolute, totally accurate indication of the recipient, but it still gives a lot of ...
9
In security, attacks are generally divided into two categories: Opportunist attacks and targeted attacks. The former are generally low-effort and low intelligence (ie, no specific information or recon on the target), the latter have to be assumed to be motivated, well-equipped, and intelligent.
The broader issue behind this question is: Does obscurity do ...
8
Simply put - any unencrypted message which is sent can be seen by an attacker who has access to the communications channel. This can be more of a problem with a wireless network, as it is broadcast as opposed to a wired network, which would require an attacker to gain access to a point on the route.
The solutions to this are:
to encrypt the message
to ...
8
Burning is a cheap and effective way to get rid of this data. Included are some links to some burning standards:
US Army Data Destuction (Check out Section V) http://www.apd.army.mil/pdffiles/r380_5.pdf
(Search for "burn") http://kdla.ky.gov/records/Documents/Destruction%20Guidelines.PDF
One of the biggest issues with burning is that you end up with ...
8
The key regulation you must follow is the Payment Card Industry Data Security Standard (PCI DSS) and of specific interest here is section 3.4 -
Protect Stored Cardholder Data
Render PAN unreadable anywhere it
is stored (including on portable digital
media, backup media, and in logs) by
using any of the following approaches:
One-way hashes based on ...
8
Rather than "bypass" encryption, they can spoof the identity of the server, so as to perform a MITM attack (effectively).
Encryption itself is only one part of the configuration when setting up an SSL/TLS connection: this ensures the confidentiality of the communication between the client and the server. Before that, the client needs to verify the identity ...
7
You should assume that the URL is not protected, i.e., that a passive eavesdropper may be able to learn what URL you are visiting.
I realize this contradicts what some other folks are claiming, so I'd better explain.
It is true that everything after the domain name is sent encrypted. For instance, if the url is https://www.example.com/foo/bar.html, then ...
7
This may sound very non-technical, but the simple way to do this is:
Start as per @ThomasPornin's answer -
use strong encryption on your data for confidentiality, and use a very long passphrase (sufficent to rule out brute forcing in any reasonable timeframe)
store the encrypted data in various locations for availability (personally I wouldn't want to ...
7
The short answer is that when you put your data on the cloud the provider has the technical capability to do what they want with it. They could sell it, trade it, share it, etc. What is keeping them from doing just that is a) the terms of service or contract agreed (read it to make sure they don't have rights to your data as some claim rights over anything ...
7
Theoretically yes. In practice, it is a bit complex for amateurs.
In Older Times, when people used dialup modems, plugging on the line was just a matter of a pair of crocodile clips and hooking another modem, tuned to be "receive only". Nowadays, people use ADSL, coaxial cable or optic fiber, and the much higher data rates mean that inexpert plugging will ...
6
I like the point that SSL provides:
Point to point confidentiality - the ssl provider on the server side and your browser are sharing an encrypted session that is not easily breakable by a man in the middle - this gives you both privacy, and integrity between the points.
Assurance of the server's identity - when the server side certificate provides proper ...
6
Yes and no.
The url in encrypted properly, so query parameters should never be revealed directly.
However, traffic analysis can get the length of the URL often - and knowing the server and the length of the url is often enough to eavesdrop what pages are being accessed, especially if assuming that links on a page are clicked. Google for "traffic analysis ...
6
There are two ways to achieve mutual authentication within SSL/TLS:
Use certificates. The server presents his public key within a certificate, as is customary; the client validates the server certificate with regards to some root CA that the client knows beforehand (this part is what commonly occurs with HTTPS Web sites). Then the server can ask for a ...
6
They are feeling comforted by a false sense of security by obscurity
If someone gains root access to your machine then they can see all the contents of everything that any application can. Encryption won't help if the application has to be able to work with the plain text since the application will have to store the keys somewhere. Hiding those keys is ...
6
In a perfect world, you are right: there should be no point in keeping data encrypted in RAM. The OS should keep strong separation between processes, clear RAM when it is reallocated to another process, and, if the attack model allows for an attacker stealing the device afterwards and doing some harddisk analysis, encrypt the swap (or use no swap at all, ...
5
The following things will leak before your session starts:
IP Address of the server
Certificate of the server
That will include the domain name published on the certificate, though that doesn't guarantee it will match what you used.
You DNS queries
No data or requests that aren't related to creating the SSL connection (GET ...) are sent to the server ...
5
Just chiming it to point that "unshredding" is not purely theoretical. It was done on a large scale with East German archives when the Iron Curtain fell, in order to determine (among other things) who was snitching on who.
More on the subject in Wired : http://www.wired.com/politics/security/magazine/16-02/ff_stasi?currentPage=all
Data destruction is ...
5
They can gain access to such information through a combination of techniques.
First of all, they can easily do online searches about a person. You will be surprised how much information can be glimpsed about a person just from his Facebook, Twitter or other social networking sites. Google, and other dedicated "people-finder" search engines like Pipl can ...
Only top voted, non community-wiki answers of a minimum length are eligible
