Wikipedia:Reference desk/Archives/Computing/2016 February 28

Computing desk
< February 27 << Jan | February | Mar >> February 29 >
Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.


February 28

edit

How to make sure data in a cloud cannot be accessed by ransomware

edit

I intend to store data in a cloud. I thought about using Duplicati in order to encrypt the data there. However, as I noticed Duplicati stores both the password for the cloud and for the encryption. Hence, I fear that if my PC got infected with a ransomware, also my data in the cloud might get lost. Is there a way to make sure no ransomware could affect the cloud? --46.126.45.1 (talk) 16:01, 28 February 2016 (UTC)[reply]

Ransomware is only a problem for people who don't do proper backups. That is 2x usign different method, incremental. You should be thinking how to implement a robust backup routine. --Scicurious (talk) 16:18, 28 February 2016 (UTC)[reply]
If you have an old PC, you might keep it offline and just use it to store data. You can copy the data over on flash drives. Yes, it's possible a virus could get onto the flash drive and get there that way, but far less likely than on a PC that's always online. StuRat (talk) 17:29, 28 February 2016 (UTC)[reply]
Thanks. I am aware of other possibilities, but I would like to use a cloud. I am interested in protecting the cloud from ransomware as much as possible. --46.126.45.1 (talk) 17:33, 28 February 2016 (UTC)[reply]
When it's in the cloud you lose control. (Whoever manages those servers has control over whether your data is protected, not you.) You could encrypt it to keep anyone else from being able to read it, but that won't keep them from deleting it. Having multiple copies in different locations makes it safer, but not absolutely safe, say if there is a major cyber attack. StuRat (talk) 17:37, 28 February 2016 (UTC)[reply]
My question is really just on how to make sure that ransomware cannot access the encrypted data in the cloud (via my PC). I do have the data also on an external HD. Maybe there is a software other than Duplicati that does not store the passwords. --46.126.45.1 (talk) 19:34, 28 February 2016 (UTC)[reply]
As long as your computer has access to the cloud there's obviously no way to prevent software with sufficient access to your computer from fooling around with whatever is on the cloud. You could use software which allows you to not be constantly logged on to the cloud. There's obviously software like this but there's so many different cloud providers and so much different software that I don't know if it's useful to give specific example. This of course negates one of the advantages most people have with the cloud namely that your data can be stored remotely soon after creation. Also, depending on how often you log in to store data, you could easily do it while the ransomware is present. And if you use a shared password which is stored somewhere on the computer, or the password happens to be stored somewhere on the computer, or the software is able to reset your password using email (if you're logged in to the email) or whatever, the software could work out how to login even if you aren't logged on or explicitly storing the login. (Although the increasing sophistication required, the less likely the software is going to have it unless you are specifically targetted.)

Alternatively you could use a cloud provider which will keep your data after being stored for a set period even if you delete or remove it. This of course requires that you uncover the ransomware before this time period runs out. This may also raises costs (due to the more data that needs to be stored, particularly if you keep lots of versions of files or screw up and store way more than you intended to). And the fact that you can't quickly delete your data (even if it is encrypted) may raise security concerns. Although you'll probably find most cloud providers don't guarantee you deleting your data means they will have no copy of it anytime soon.

You could use a combination of these i.e. a cloud provider which requires a seperate login to be able to remove data. This will of course mean you to some extent get all the disadvantages and advantages of both. Ultimately as earlier respondents hinted at, there's no simple solution other have having more disconnected backups and being vigilant with security. Sometimes if you find some problems with your backup regiment it means you're using the wrong options, but often as much as anything it means you're using the options you do choose incorrectly (although these two are often related).

P.S. I'm assuming your concern is with deleting the data on the cloud. If your concern is about the software viewing the data on the cloud, you could choose something which uses Public-key cryptography. Although again, this assumes the ransomware never gets access to the private key before you thoroughly remove it. Also it's pointless worrying about what the software can find on the cloud if it can also find it somewhere else, e.g. on your computer (even if nominally deleted) or for that matter any other backups you connected while it's presented. Probably for this and similar reasons (e.g. the difficulty managing the backup), I don't think many cloud backup solutions use public-key cryptography.

Nil Einne (talk) 20:42, 28 February 2016 (UTC)[reply]

Thank you for your detailed answer. I will need some time to think about your suggestions. You mentioned that there are so many cloud providers. Mine uses WebDAV. --46.126.45.1 (talk) 01:38, 29 February 2016 (UTC)[reply]

Dropbox used to have a packrat feature that allowed unlimited revisions. I think they still offer that, but only for business accounts. Nowadays you have the Extended Version History which will store them for a year. It costs 40 euro extra. The Quixotic Potato (talk) 18:42, 29 February 2016 (UTC)[reply]

Structures in C

edit

Can we not initialize a structure member of type string inside main method in C? I have a code like this

struct college
{
	char name[30];
	char course[30];
	int fee;
};
struct college c1={"purnia","m.com",5000};     
struct college c2;
int main()
{
/*1*/	struct college c2={"magadh","fine arts",5200}; // compiles        
/*2*/	c2.name="magadh";                              // error    
/*3*/	c2.course="fine arts";                         // error    
/*4*/	c2.fee=3000;                                   // compiles  
/*5*/	strcpy(c2.name,"magadh");                      // compiles

// rest of the code

}

When I compile the code then I get error for c2.name="magadh"; as incompatible type assignment for constant char[7] to char[30] and similar error for the very next line(3) but other initialization like line 5 or like those in line 1 compiles well.I tried online resources on C but could not figure out why we can not initialize a string member like the one in line 3 as such.The compiler I am using is GCC 4.8.1 64 bit.123.238.96.162 (talk) 18:04, 28 February 2016 (UTC)[reply]

[I've restored your original question and fixed the formatting]. The problem is in the assignment lines - you need to use strcpy rather than just c2.name = "magadh"; The name element of the structure is a pointer, not an actual string. See C string handling. You might also want to use a floating-point variable for the fee, rather than an integer. Tevildo (talk) 19:15, 28 February 2016 (UTC)[reply]
The name element is not a pointer. Arrays decay to pointers; that's not the same as being a pointer. See the comp.lang.c FAQ, section 6 for more about the weirdness of C arrays.
Fundamentally it's just a historical accident that C doesn't allow lines 2–3. In C99 you can even write c2 = (struct college){"magadh","fine arts",3000};, which requires the compiler to generate exactly the same code as it would have had to generate for lines 2–3 if they were allowed. But they still aren't allowed. -- BenRG (talk) 00:55, 29 February 2016 (UTC)[reply]
To make it explicit, Tevildo's statement of the error was exactly backwards. The name element of the struct is not a pointer, but the string literal "magadh" decays to a pointer. C strings decay into pointers when used as values, e.g. on the right-hand side of =. The fact that a string literal can be used to initialize an array is a special case. --69.159.61.172 (talk) 03:30, 29 February 2016 (UTC)[reply]
To expand the answer a little - the compiler will interpret the initialization on Line 1 as:
char c2.name[30] = {'m', 'a', 'g', 'a', 'd', 'h'};
This will work properly - see Initialization (programming). On line 2, however, the variable is already initialized, so you can't do this. Tevildo (talk) 19:22, 28 February 2016 (UTC)[reply]
This issue doesn't have anything to do with the fact that you're using a struct, you'd get the same error with this code:
char name[30];
name = "magdah";

As mentioned, you need to use a string function to assign a string, not the assignment operator. However you should use strncpy, not strcpy, as the latter is almost never safe. For example, this code will overflow the name array and cause unpredictable results:

char name[30];
strcpy(name, "Janaropolopoulous-Featherstonehaugh");

Mnudelman (talk) 19:57, 28 February 2016 (UTC)[reply]

To follow up on an important point - if you use strncpy, remember that the variables can only hold 29 characters, not 30. Tevildo (talk) 20:03, 28 February 2016 (UTC)[reply]
That's not quite correct. strncpy(name,str,sizeof(name)) will store 30 chars in name, but the result is not null terminated, which can cause other problems. strncpy(name,str,sizeof(name)-1) doesn't solve the problem either, since the result can still be non null terminated. strlcpy or strcpy_s are alternatives if they are available. strncpy(name,str,sizeof(name)-1); name[sizeof(name)-1] = 0; is a possible, although verbose, option. C_string_handling#Replacements discusses this. Mnudelman (talk) 21:43, 28 February 2016 (UTC)[reply]