Safer alternative to using .smbcredentials

At work we are using a server for our working group where we all have our own accounts. We also have storage from the institution that our group is part of. So everyone's storage is mounted in the /etc/fstab file, e.g.

//external/storage /mounting/point cifs noperm,cred=/home/user/.smbcredentials,domain=WORK,iocharset=utf8,vers=3.0,sec=ntlmv2i,uid=user,gid=WORKGROUP,dir_mode=0770,file_mode=0770 0 0

and everyone put their credentials in their /home/user/.smbcredentials file, e.g.

user=user
password=pass

However, this file is in plain text. The permissions are correct so only the user can view/change the file, but so can sudo AFAIK. The issue is that the password is also the password to sensitive information of the user as part of the institution (so the storage is linked to the same account as the sensitive information). My fear is, then, that if the server or even just the user's account is compromised, this may have grave consequences because the passwords are available right there in plain text.

My question then is: how can this be made more secure? Surely there must be an alternative to plaintext passwords?

8

2 Answers

Currently, there is no support for encrypted credentials. From the smbclient manpage regarding -U and -A which is what is passed behind the scenes:

 -A|--authentication-file=filename This option allows you to specify a file from which to read the username and password used in the connection. ... Make certain that the permissions on the file restrict access from unwanted users. -U|--user=username[%password] Sets the SMB username or username and password. ... A third option is to use a credentials file which contains the plaintext of the username and password. This option is mainly provided for scripts where the admin does not wish to pass the credentials on the command line or via environment variables. If this method is used, make certain that the permissions on the file restrict access from unwanted users. See the -A for more details. ...

This is current even in 20.04 currently. You must use plain-text credentials.


You state the 'risk of a user's account being breached' is a risk, and these credentials are also admin creds:

The passwords required by the institution are one for everything (admin, mail, storage).

Rule #2 of IT Security is the concept of least privilege and privilege separation. This is where you separate admin and non-admin accounts. All good organizations have some aspect of this in play and this then prevents 'admin' access on other systems. Storage and Email access is simply a matter of having to audit access attempts or restrict how someone can access information.

The other problem though is, if your system is hacked, you have a host of other problems the least of which is password leakage for one specific user (which you could fix with a forced password change in your Active Directory / LDAP system).

The only other way to do this without password leakage might be to write a wrapper around the mounting, request credentials manually, and then execute a mount command directly without exposing the credentials file or the password. The tricky part here is, this has to be manually user-entered and executed, which means your automatic fstab mount won't work. It also would require specialized access (or a specific sudoers entry to work right) because you'd be passing the mount options in and only root can do that currently in all mount setups.

And as for the rest of your comment:

... perhaps I suggest that they allow (or better, require) different passwords for samba/storage access

... you'd have to take that up with the Samba developers on samba.org. Chances are though this is a request already somewhere in line, but Windows interoperability is a pain so...

7

You could try Cifscloak. You can install it using:

sudo python3 -m pip install cifscloak

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password

Post as a guest

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

You Might Also Like