4 ms·

You should be able to know all the references to a variable, if you are careful when writing your program. Also, you could write a destructor that scrambles the

by aflag 4y ago

You should be able to know all the references to a variable, if you are careful when writing your program. Also, you could write a destructor that scrambles the memory location before the object is collected. However, you would still not have control over copies that the GC may decide to make and it is a bit trickier to force a free, since the GC is in no obligation of freeing an object as soon as it has no more references (though you can probably force that to happen in most GCed languages).

acatton 4y ago
> You should be able to know all the references to a variable, if you are careful when writing your program. The issue is: what if thread A and thread B hold a reference to the password variable? And you don't know in which order they will execute. In which thread do you scramble the password before releasing the variable reference? From what I understand, OP's point is: because of the nature of C, you have to know where your variable is "free()ed", because you have to do it yourself. Therefore you can scramble there. Even if you have two thread doing: n = decr_reference(password) if (n == 0) { scramble(password) free(password) }
- nebulous1 4y ago
  That issue seems the same in a GC language as it is in a non-GC one. Either way you need to know when you're done with the data and it's time to scramble.
- aflag 4y ago
  One possibility would be to reference a password variable always from t he same thread. But even if you use multiple threads referencing the same memory location, you could make some of them weak references (which the GC doesn't take into account when deleting the object) or you could make sure you stop referencing them in both threads and force the GC to run on that object. The destructor could handle the scrambling.
- deleted 4y ago
  [deleted]
kmeisthax 4y ago
In most GC languages, the String type itself is not a managed handle to a single memory buffer, but a reference into a whole copy-on-write datastore. So you can't even scramble the underlying memory - mutating the string to erase it will not zap the original, it will just create a copy. Your best bet is to ensure no references to the password string exist - including in library code you may use, which means constant revalidations whenever you update a library or your underlying language runtime. Once you do that, you can force garbage collection, either by some explicit language mechanism to request garbage collection, or by trying to allocate gobs of memory in some way that can't be easily optimized out.
- aflag 4y ago
  You don't need to use the String type for your sensitive data, though. You can create your own type that acts the way you want.
  - Faark 4y ago
    There are strong incentives to use the built-in String class. APIs for UI will use it. The first google result for "c# Clipboard" certainly uses string. It'll be a lot of extra effort, that you might not have with a different language. That is, if actually you consider the risk worth it... i probably wouldn't.
duped 4y ago
> Also, you could write a destructor that scrambles the memory location before the object is collected. This assumes you can write destructor at all and that it's run deterministically. > though you can probably force that to happen in most GCed languages I'd actually be surprised if any GC'd language allows this. You normally need to resort to different kinds of tricks for RAII-like behavior.
- im3w1l 4y ago
  Java has try-with-resources for this. Python has with. Unlike say C++ you do have to indent your code once for every such resource though which can be cumbersome.
  - duped 4y ago
    Neither of these things are equivalent to destructors, however
    - im3w1l 4y ago
      They aren't equivalent but they can do the task in question: with prompt_password() as password: stuff Once the scope exits, the context manager can scramble the memory.
- aflag 4y ago
  Python has `gc.collect` which should work for user created types. Besides, it does have a reference counting GC. So, as long as you don't create cycles, you should be able to force the collection of objects similarly to C++'s shared_ptr.
mannykannot 4y ago
To avoid the risk outlined here, knowing all the references to a variable is not sufficient; without an understanding of their lifetimes in every possible permutation of the program's use (and misuse), you cannot act on that information to minimize the exposure posited here. I won't get into the question of whether a programmer should also know all that, as there is another consideration which renders it moot: Even with a non-GC'd language, a programmer could leave variables with sensitive information in memory for the remaining duration of the program (e.g. local variables left deep in the stack when a function returns or throws an exception - do you know when they will be overwritten?) What matters here is that the programmer understands the risks, knows what constitutes the most sensitive data, and acts accordingly - but, armed with that knowledge, the programmer can just as well ameliorate the risk in a GC'd language as one that is not.
eastbound 4y ago
Nono, a lot of GCs copy the whole known variables to a new area, then delete the old area in bulk (“but it consumes twice as much memory!?” yes, but it’s very efficient - doesn’t require tracking). Therefore you may have a constant char[] and it could still be in 2 places in memory.

by aflag 4y ago

acatton 4y ago

> You should be able to know all the references to a variable, if you are careful when writing your program. The issue is: what if thread A and thread B hold a reference to the password variable? And you don't know in which order they will execute. In which thread do you scramble the password before releasing the variable reference? From what I understand, OP's point is: because of the nature of C, you have to know where your variable is "free()ed", because you have to do it yourself. Therefore you can scramble there. Even if you have two thread doing: n = decr_reference(password) if (n == 0) { scramble(password) free(password) }

nebulous1 4y ago
That issue seems the same in a GC language as it is in a non-GC one. Either way you need to know when you're done with the data and it's time to scramble.
aflag 4y ago
One possibility would be to reference a password variable always from t he same thread. But even if you use multiple threads referencing the same memory location, you could make some of them weak references (which the GC doesn't take into account when deleting the object) or you could make sure you stop referencing them in both threads and force the GC to run on that object. The destructor could handle the scrambling.
deleted 4y ago
[deleted]

kmeisthax 4y ago

In most GC languages, the String type itself is not a managed handle to a single memory buffer, but a reference into a whole copy-on-write datastore. So you can't even scramble the underlying memory - mutating the string to erase it will not zap the original, it will just create a copy. Your best bet is to ensure no references to the password string exist - including in library code you may use, which means constant revalidations whenever you update a library or your underlying language runtime. Once you do that, you can force garbage collection, either by some explicit language mechanism to request garbage collection, or by trying to allocate gobs of memory in some way that can't be easily optimized out.

aflag 4y ago
You don't need to use the String type for your sensitive data, though. You can create your own type that acts the way you want.
- Faark 4y ago
  There are strong incentives to use the built-in String class. APIs for UI will use it. The first google result for "c# Clipboard" certainly uses string. It'll be a lot of extra effort, that you might not have with a different language. That is, if actually you consider the risk worth it... i probably wouldn't.

duped 4y ago

> Also, you could write a destructor that scrambles the memory location before the object is collected. This assumes you can write destructor at all and that it's run deterministically. > though you can probably force that to happen in most GCed languages I'd actually be surprised if any GC'd language allows this. You normally need to resort to different kinds of tricks for RAII-like behavior.

im3w1l 4y ago
Java has try-with-resources for this. Python has with. Unlike say C++ you do have to indent your code once for every such resource though which can be cumbersome.
- duped 4y ago
  Neither of these things are equivalent to destructors, however
  - im3w1l 4y ago
    They aren't equivalent but they can do the task in question: with prompt_password() as password: stuff Once the scope exits, the context manager can scramble the memory.
aflag 4y ago
Python has `gc.collect` which should work for user created types. Besides, it does have a reference counting GC. So, as long as you don't create cycles, you should be able to force the collection of objects similarly to C++'s shared_ptr.

mannykannot 4y ago

To avoid the risk outlined here, knowing all the references to a variable is not sufficient; without an understanding of their lifetimes in every possible permutation of the program's use (and misuse), you cannot act on that information to minimize the exposure posited here. I won't get into the question of whether a programmer should also know all that, as there is another consideration which renders it moot: Even with a non-GC'd language, a programmer could leave variables with sensitive information in memory for the remaining duration of the program (e.g. local variables left deep in the stack when a function returns or throws an exception - do you know when they will be overwritten?) What matters here is that the programmer understands the risks, knows what constitutes the most sensitive data, and acts accordingly - but, armed with that knowledge, the programmer can just as well ameliorate the risk in a GC'd language as one that is not.

eastbound 4y ago

Nono, a lot of GCs copy the whole known variables to a new area, then delete the old area in bulk (“but it consumes twice as much memory!?” yes, but it’s very efficient - doesn’t require tracking). Therefore you may have a constant char[] and it could still be in 2 places in memory.