Talk:Protecting Memory Secrets

Draft Status

Despite the wording in some of the standards which may sound overly prescriptive, I expect the intent is not to ban the use of popular languages from use. As such I expect that the requirements will evolve. This is an attempt to step back from some of the wording to look at the risks and a broader set of options to meet the objective. This task should evoke a healthy constructive discussion. As such, I don't see this as cast in stone.

Motivation for task

Recent trends in data breaches are increasing focus on preventing breaches. One of the emerging areas is the entire area of secrets management, things like credentials at rest. There are a number of platform based secrets managers addressing these risks. The protection of secrets in working memory is less mature. Some emerging standards are calling for protections that may not exist in all languages.

Like it or not, some developers will need to demonstrate that they can code to these standards, provide language documentation, and verify the measures work.

Standards with Secrets Management

At Rest

OWASP has a secrets management cheat sheet

Transient

The Payment Card Industry has approximately a dozen standards for the protection of credit/debit information. Some of these cover organizations others cover solutions. Bothe the P2PE and Secure Software standards require developers to address secrets in memory.

Reddit Discussion

Reddit discussion of secrets in memory

This discusses a variety of instances and techniques

Context Managers (e.g. Python)
Rust's Secrecy features
Platform Specific Interfaces such as secure enclaves could help but make the solution more platform dependent
In-memory encryption has been suggested but you still need to worry about the plain text input/output phases plus you need good encryption keys which has other challenges
ORAM has been suggested but it sounds like fits another purpose
Garbage Collection challenges

attempting to zero elements one at a time could make the situation worse by creating partial strings in languages where new strings are created
performance impact unless there is some way to constrain the size of the collected region
not all languages can request collection and some delay the collection or take it as a suggestion

Perhaps missing the point

This is sort of like trying to close the barn door while the horse is walking through it.

Proper protection for "memory secrets" has to be viable outside of the machine.

In other words, secrets need to be mixed in with garbage such that a snoop has a high probability of picking up plausible looking garbage when looking for secrets. (Also, conceptually: if snoops are a problem you want to have a way of detecting their presence and taking some sort of legal action or whatever against them.)

Worse, from a rosettacode point of view (worse partially because the approach outlined here can assist in the creation of plausible looking garbage), the fact that there is no "task" here, means that there's no way for us to compare implementations, let along judge the viability of any claims about implementations for the general case. (We might judge in the context of specific machines, but without intimate knowledge of the machine architecture we'll have difficulty even there.) --Rdm (talk) 03:31, 13 January 2023 (UTC)

Disagree, Task is valid

I'll agree this is not an ideal task. Having said that real life doesn't deal out ideal situations very often. There are security standards for development that make this a requirement. Whether you or I or anyone else agrees with the approach is mute. Whether or not there is a better way is also mute.
As for several ways to complete the task, I could easily create 3, 4, or 8 separate tasks for this. I don't think that really helps anyone.
Mixing in plausible garbage is just one approach.
Pointing to language documentation is a valid part of a task. Documentation is part of programming and reference documentation is also a part. It may not be the most fun part but it's valid.
If people don't like the task, they don't need to try it.
One thing I like about this task, is it invites flexibility of approach.
I am encouraged by some early additions even when these are in discussion form

EnigmaticC (talk) 01:44, 15 January 2023 (UTC)

Valid as a useful concept for some contexts, definitely. But is it valid as a *rosettacode* task? If so, how?

Also, some questions:

First, what is a secret? Is it a bit pattern or is it the information represented by that bit pattern? (A bit pattern is much easier to deal with, in a concrete sense, than an abstraction is.)

Several examples of secrets are given in the description. For the example any set of characters or numbers will do. EnigmaticC (talk) 23:32, 15 January 2023 (UTC)

Second, what does it mean to erase a secret? Specifically: how much responsibility must the software author have over the underlying hardware and operating system? (For example: if the operating system has swap enabled, or preserves memory images in some other fashion, is that an issue for the language or is that out of scope for this task?)

I explained the language of the standard and further elaborated the intent was to minimize the time a secret is vulnerable to memory skimming. EnigmaticC (talk) 23:32, 15 January 2023 (UTC)

Third is there some meaningful "minimum size" for consideration here? Short bit patterns can happen coincidentally so are probably not relevant, correct?

This is getting pedantic. The size of the secret is not relevant to the task as defined. Only the capability is. If you like call it a credit card. There are several well known 16 digit test cards 4111....1111, 42...42, 54..54, but it could be anything and at least one of the contributors made up their own. EnigmaticC (talk) 23:32, 15 January 2023 (UTC)

Philosophically speaking, all secret knowledge is temporary -- either all holders of the secret expire, losing the knowledge, or the information is eventually propagated or re-discovered rendering it non-secret. Here, we're aiming for partial expiration -- partial because of limitations of software scope. But we still need to define that scope.

Philosophy? Really! There is a defined objective. If you disagree with the philosophy behind the standard either challenge it or avoid it. That doesn't make this an invalid task. EnigmaticC (talk) 23:32, 15 January 2023 (UTC)

Anyways... it seems to me that adequately addressing this task takes us deep into rosettacode's "things to avoid" territory. --Rdm (talk) 05:28, 15 January 2023 (UTC)

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. 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. --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. 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. 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 validate(string password) 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. --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. EnigmaticC (talk) 15:04, 17 January 2023 (UTC)