~/.hashcat/hashcat.pot is world readable

[bjornfor]

Look:

$ ls -l ~/.hashcat/hashcat.pot 
-rw-r--r-- 1 bfo users 108 May 11 16:34 /home/bfo/.hashcat/hashcat.pot

Given that it contains plain text passwords, I'd prefer it not to be world readable. (Maybe it shouldn't be group readable, even?)

(This is oclHashcat from today, v3.00-beta-5-gaefd3b0.)

[d2-d2]

Before running hashcat, set your umask to: umask 027.

[jsteube]

We can place a fixed umask inside hashcat, what you think?

[bjornfor]

My first thought is that setting umask is a "big hammer", it will affect the whole process and all files. Another option is to create the secret file with explicit permission bits.

While at it, maybe the program should check on startup what the permission bits are, and complain a bit if it is group and/or world readable?

[jsteube]

@bjornfor That was my thinking actually. It wouldn't be too bad to affect all files. Do you see any files in which case it would create problems?

[bjornfor]

@jsteube: I have no idea. (I've been using hashcat only a couple of days, I haven't looked at its source code yet.)

But even if using umask doesn't cause real problems, it feels a bit wrong. I don't think it conveys the right intent; "~/.hashcat/hashcat.pot should be private". Instead it says, "all files should be private".

(Isn't it equally trivial to create the file with the correct permission bits, as it is to use umask?)

[matrix]

It's a simple problem ... we can remove the wrong permission without any
problem.
Thanks @bjornfor

On Tuesday, May 17, 2016, Bjørn Forsman notifications@github.com wrote:

@jsteube https://github.com/jsteube: I have no idea. (I've been using
hashcat only a couple of days, I haven't looked at its source code yet.)

But even if using umask doesn't cause real problems, it feels a bit wrong.
I don't think it conveys the right intent; "~/.hashcat/hashcat.pot should
be private". Instead it says, "all files should be private".

(Isn't it equally trivial to create the file with the correct permission
bits, as it is to use umask?)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#331 (comment)

[jsteube]

I still think about using umask(). It maybe is a "big hammer" but it's a fitting one. I don't see a reason why not apply umask on all created files. Anyone has an idea?

[d2-d2]

@jsteube I think it's the best and simplest solution. Hashcat (or user) will set umask prior running anything, thanks to that every file will be properly secured. Otherwise, if you decide to do it in per-file manner, there is a chance that one or another file will not be covered and another 'issue' will be raised.

[jsteube]

I've set the umask now. Let's see if someone complains :)

f5ee678

[bjornfor]

Thanks! (Looking forward to the upcoming release, I plan to package it for Nix/NixOS.)

[cblack-r7]

Apologies for commenting on a massively dead thread, but I was digging into a problem and I did run into this (i.e. me complaining). I have a multi-user instance that uses a shared user group for hashcat, this causes the OCL kernels to be created without group writable permissions and I've had to do some pretty nasty hacks to get around that. Generally not forcing the umask unless in specific sensitive cases is generally considered polite.