On Fri, Sep 30, 2022 at 01:49:40PM +0200, Stefan Eissing via curl-library wrote: > > > > Am 30.09.2022 um 13:41 schrieb Daniel Stenberg <dan...@haxx.se>: > > > > On Fri, 30 Sep 2022, Stefan Eissing wrote: > > > >> I know of threee patterns to solve this problem (and increase usability > >> as a side effect): > > > > Those methods transfer the data to another process, and that is certainly > > even more safe since then the sensitive data is not even present in the > > heap of the first process. > > > > But: introducing a second process or a daemon or something for this > > purpose, while safer, would be a significant new factor and complication > > that would basically prevent a huge portion of our users from using it. > > > > I think a simpler first step could be to just "scramble" the data while > > "long-term stored" in memory. > > It's certainly simpler and it makes leaking the "interesting" parts of > memory easier. But for cases where someone gets access to all the memory or > a core dump, it will not make things more secure, just obscure. > > One thing I have seen for memory scanning protection is to put protected > pages around the location where sensitive data is. So someone scanning > memory from above or below will run into a segfault.
Hi, Plus (on platforms supporting this) lock the pages into memory and exclude them from dump. Further question as I did exactly this for libcurl data with custom memory management; Does libcurl use the custom memory management also for the passwords? - Ville -- "I want to move to Theory, everything works in theory." [l...@iki.fi][+358-50-386 6269] -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html