Re: Securing data in memory (was "Locking physical memory (RAM)

Simon R Knight (srk@tcp.co.uk)
Mon, 23 Nov 1998 15:49:26 0000

• Next message: coderpun: "Request for information.(hopefully on topic)"
• Previous message: Jim Adler: "Re: Securing data in memory (was "Locking physical memory (RAM) under Windows")"

> Jim Adler" <jadler@soundcode.com> wrote
>> Frank O'Dwyer <fod@brd.ie> wrote:
>
>
> >Thanks for making this available. I have one suggestion -- as far
> >as I am aware a related bug can occur when you need to obtain some
> >secret on the GUI--notably a password. I believe this is because
> >the dialog control for a password uses swappable memory as an edit
> >buffer. Do you know if it would be possible to arrange for a dialog
> >control to use an SCNSM allocated page as its edit buffer (maybe by
> >subclassing the existing control?), or is this so hardcoded into
> >Windows as to be unfixable?
>
>
> I haven't looked into the details, but others have. I believe a
> thread dealt with this about a year ago. As you point out, the
> first approach would be to subclass the existing control. Another,
> of course, is to write it from scratch with the same look and feel
> as the Windows dialog. One last thought is to simply subclass (or
> rewrite) the "edit control" and not the entire dialog.

Another possibility would be to intercept any key event, and store the
value (or hash of the value) in non-swappable memory, while assigning
a hash or asterisk symbol to a password edit control.

Simon R Knight

• Next message: coderpun: "Request for information.(hopefully on topic)"
• Previous message: Jim Adler: "Re: Securing data in memory (was "Locking physical memory (RAM) under Windows")"