[GH-ISSUE #277] Hashed Passwords #148

Closed
opened 2026-04-08 16:50:41 +03:00 by zhus · 3 comments
Owner

Originally created by @Protinon on GitHub (Nov 3, 2023).
Original GitHub issue: https://github.com/sigoden/dufs/issues/277

Support for hashed passwords in authentication

Currently passwords can only be specified in cleartext. Storing hashes would be much more secure, especially if passwords are kept in a configuration file.

Implement Suggestion

Currently the syntax is username:password. I suggest an implementation similar to the /etc/shadow file used in Unix OSs: username:$type$salt$hashed$. Where type specifies the algorithm (MD5/SHA-256/...), salt and hashed are combined to secure the password. Cleartext passwords could still be specified using the current syntax, so this doesn't need to break existing configuration. Hashed passwords are represented as hex, so they would not interfere with the currently used special characters : and @.

An example of authentication using plaintext passwords would be admin:admin@/:rw. That same user with an MD5 hashed password would be admin:$1$US11Sj3d$33qmh0VIXWPcLdeELHOpC@/:rw

At a basic implementation, MD5 would be the only available algorithm. /etc/shadow supports many types, which probably isn't necessary for dufs. The /etc/shadow syntax seems common, so implementing other algorithms may be trivial if a password library is used for this.

This could be put in dufs documentation so users can easily generate their own hashed password: https://unix4lyfe.org/crypt/

For more reference, this explains the /etc/shadow file in greater detail: https://www.cyberciti.biz/faq/understanding-etcshadow-file/
3Proxy implements very similar authentication: https://github.com/3proxy/3proxy/wiki/How-To-(incomplete)#USERS

Originally created by @Protinon on GitHub (Nov 3, 2023). Original GitHub issue: https://github.com/sigoden/dufs/issues/277 ## Support for hashed passwords in authentication Currently passwords can only be specified in cleartext. Storing hashes would be much more secure, especially if passwords are kept in a configuration file. ## Implement Suggestion Currently the syntax is `username:password`. I suggest an implementation similar to the `/etc/shadow` file used in Unix OSs: `username:$type$salt$hashed$`. Where `type` specifies the algorithm (MD5/SHA-256/...), `salt` and `hashed` are combined to secure the password. Cleartext passwords could still be specified using the current syntax, so this doesn't need to break existing configuration. Hashed passwords are represented as hex, so they would not interfere with the currently used special characters `:` and `@`. An example of authentication using plaintext passwords would be `admin:admin@/:rw`. That same user with an MD5 hashed password would be `admin:$1$US11Sj3d$33qmh0VIXWPcLdeELHOpC@/:rw` At a basic implementation, MD5 would be the only available algorithm. `/etc/shadow` supports many types, which probably isn't necessary for dufs. The `/etc/shadow` syntax seems common, so implementing other algorithms may be trivial if a password library is used for this. This could be put in dufs documentation so users can easily generate their own hashed password: https://unix4lyfe.org/crypt/ For more reference, this explains the `/etc/shadow` file in greater detail: https://www.cyberciti.biz/faq/understanding-etcshadow-file/ 3Proxy implements very similar authentication: https://github.com/3proxy/3proxy/wiki/How-To-(incomplete)#USERS
zhus closed this issue 2026-04-08 16:50:41 +03:00
Author
Owner

@sigoden commented on GitHub (Nov 3, 2023):

Very good idea, but there is one problem: digest-auth cannot use hashed password.

<!-- gh-comment-id:1792203773 --> @sigoden commented on GitHub (Nov 3, 2023): Very good idea, but there is one problem: digest-auth cannot use hashed password.
Author
Owner

@sigoden commented on GitHub (Nov 3, 2023):

Another consideration is, is it really necessary to hash the password for basic auth?

If someone can access the system and see the password file, then it wouldn't be any harder to obtain the password through the Authorization header.

<!-- gh-comment-id:1792313605 --> @sigoden commented on GitHub (Nov 3, 2023): Another consideration is, is it really necessary to hash the password for basic auth? If someone can access the system and see the password file, then it wouldn't be any harder to obtain the password through the Authorization header.
Author
Owner

@Protinon commented on GitHub (Nov 3, 2023):

I think it's important for users who configure dufs using configuration files. In particular docker configuration using docker-compose.yml files, putting configuration inside systemd service files, or in my case I was setting up a Nix service which would contain the password.

Currently I need to be very cautious where and how I store these configuration files.

If this was implemented, I suppose digest Auth would no longer be needed.

<!-- gh-comment-id:1792522520 --> @Protinon commented on GitHub (Nov 3, 2023): I think it's important for users who configure dufs using configuration files. In particular docker configuration using docker-compose.yml files, putting configuration inside systemd service files, or in my case I was setting up a Nix service which would contain the password. Currently I need to be very cautious where and how I store these configuration files. If this was implemented, I suppose digest Auth would no longer be needed.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sigoden/dufs#148