Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

~/.hashcat/hashcat.pot is world readable #331

Closed
bjornfor opened this issue May 11, 2016 · 11 comments

Comments

Projects
None yet
5 participants
@bjornfor
Copy link

commented May 11, 2016

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

This comment has been minimized.

Copy link

commented May 14, 2016

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

@jsteube

This comment has been minimized.

Copy link
Member

commented May 14, 2016

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

@bjornfor

This comment has been minimized.

Copy link
Author

commented May 15, 2016

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

This comment has been minimized.

Copy link
Member

commented May 17, 2016

@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

This comment has been minimized.

Copy link
Author

commented May 17, 2016

@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

This comment has been minimized.

Copy link
Member

commented May 17, 2016

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

This comment has been minimized.

Copy link
Member

commented May 18, 2016

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

This comment has been minimized.

Copy link

commented May 18, 2016

@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 added a commit that referenced this issue May 18, 2016

Use umask(077), mainly to secure hashcat.pot from reading from other …
…users, but should be a good idea for all files. See #331 for details
@jsteube

This comment has been minimized.

Copy link
Member

commented May 18, 2016

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

f5ee678

@jsteube jsteube closed this May 18, 2016

@bjornfor

This comment has been minimized.

Copy link
Author

commented May 18, 2016

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

@cblack-r7

This comment has been minimized.

Copy link

commented Oct 16, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.