Talk:Protecting Memory Secrets: Difference between revisions
m
→pithier, maybe: nice
EnigmaticC (talk | contribs) m (→Disagree, Task is valid: rebuttal) |
EnigmaticC (talk | contribs) m (→pithier, maybe: nice) |
||
| (2 intermediate revisions by one other user not shown) | |||
Line 89:
:: Really which ones? I am not asking for a specific language feature. I am asking people who use various languages to provide guidance on how they would meet the intent of a requirement. I'm not even asking for an exceedingly rare feature. I'm not looking for an extremely small solution - I've gone out of my way to be flexible and solicit the input of folks that know their languages. And I have not asked for the fastest possible solution. [[User:EnigmaticC|EnigmaticC]] ([[User talk:EnigmaticC|talk]]) 23:32, 15 January 2023 (UTC)
:::I would agree and say I cannot see any overlap at all between this task and "things to avoid". I did in fact have a genuine use case for this sort of thing five years or so ago, when I was collaborating with someone 5,000 miles away and it was pretty obvious we did not want to be accidentally emailing our credentials between each other along with the debug info we did need to frequently share. --[[User:Petelomax|Petelomax]] ([[User talk:Petelomax|talk]]) 10:06, 17 January 2023 (UTC)
: I will reiterate, I made this a draft task for the reason that it isn't as well defined and may change or evolve. I expect this will be evolution toward more clarity as solutions appear. Folks responding to draft tasks know that. [[User:EnigmaticC|EnigmaticC]] ([[User talk:EnigmaticC|talk]]) 23:32, 15 January 2023 (UTC)
: I get that for whatever reason, this task seems to offend your notion of RosettaCodeness, but your arguments aren't convincing. Just because it isn't a neat and tidy little algorithm doesn't invalidate it. Please feel free to '''ignore''' this task if you don't like it. [[User:EnigmaticC|EnigmaticC]] ([[User talk:EnigmaticC|talk]]) 23:32, 15 January 2023 (UTC)
=== pithier, maybe ===
I had a quick go at writing a rather pithier task description, which I think it covers it, more for discussion and refinement than for wholesale adoption, and I promise not be be even slightly offended if this is completely rejected. One term that I quite like but missed is "skimming memory".
There are many forms of sensitive data, such as login credentials/passwords and credit card details. An entirely separate matter, outside the scope of this task, is how you might permanently store such on disk. At some point however, a program must read in and possibly decrypt such information for use: what steps might you take to minimise the possibility of another program reading process memory, or scanning error files, core dumps, and log files from discovering such sensitive information? One obvious step is to keep such information in memory for the shortest possible time and ensure it is overwritten with garbage/binary zeroes as soon as possible. Some programming language features, including but not limited to object orientation, data hiding, and closures, may make it rather difficult to be certain that raw binary copies of the data are not left in memory for much longer than desired. For instance, a call such as <code>validate(string password)</code> might well leave string password earmarked for garbage collection but otherwise out in plain sight and unencrypted. It may be sensible to only ever store sensitive information in explicitly programmer managed memory. Discuss any other means available to ensure that you can and have securely wiped all last traces of any such asap after use. --[[User:Petelomax|Petelomax]] ([[User talk:Petelomax|talk]]) 10:06, 17 January 2023 (UTC)
: I'll strongly consider this. I think it would help to make clear the out of scope things like secrets at rest, memory/debugging dumps, etc. and note these are addressed in other parts of the standards. Cleary saying what's out will help folks avoid going down the secret lifecylcle rabbit hole. It may also help to provide quotes for the specific requirements. I probably won't get to an update for several days. [[User:EnigmaticC|EnigmaticC]] ([[User talk:EnigmaticC|talk]]) 15:04, 17 January 2023 (UTC)
| |||