On 7/6/2014 4:22 AM, Rikki Cattermole wrote:
On 6/07/2014 6:45 p.m., Nick Sabalausky wrote:
The idea behind the auto-zeroing Password type in DAuth: you do your
best to give it [hopefully] the one and only copy of the plaintext
password data, in mutable form, and DAuth nukes it from memory as soon
as it's able to. Not if/when GC kicks in, sweeps it, and reuses it. And
not just a copy of the data, but the actual [hopefully] original buffer.
Any further attempts (deliberate or accidental) to read that data
through any other reference will only receive zeros.
My reasoning is simple. Only upon setting the password for a user will
the plaintext version ever be in memory or when logging in for
authentication.
Now this should be coming as a parameter via routes in some format as a
string. If this cannot be caught by the GC and cleaned up, how exactly
does your method help?
So as far as I'm concerned, if it cannot be cleaned up, there are bigger
problems to worry about then just securing this one tiny piece of code.
I wanted to keep the door open for, and help encourage, applications
that *do* avoid having a password in an immutable buffer.
I realize that your library relies on vibe anyway, so in your case, yes
this measure wouldn't help without corresponding changes within vibe.d.
That is a fair point. But DAuth (again, I may want to change the name),
is designed to be a general-purpose password-based user authentication
tool, reusable from any sort of program, so that situation/limitation
doesn't necessarily apply to DAuth.
Unless of course, we want some method to guard against this e.g. all
data given to routes in Vibe is actually protected and will be
forcefully freed upon finishing of the route.
That's actually an interesting idea. I had been imagining a possible
enhancement to vibe that would handle passwords separately, but
depending on the application, a password isn't necessarily the only
sensitive data sitting around.
