You are not logged in.
Hi all,
I have several configuration files where my passwords are stored in the clear. I have noticed that some configuration files (such as wpa_supplicant.conf) allow for the passwords to be stored in hashes. Is there a way do this in vpnc.conf and muttrc so I don't compromise other systems where I connect regularly ?
Thanks !
Offline
There's no general solution to this, it works for wpa_supplicant because the hashed variant is what is actually transmitted as part of the WPA protocol. if vpnc or mutt do not implement anything for hashing the PW you can't really do much about this, other than using one-time/generated passwords.
Last edited by V1del (2022-10-26 10:32:54)
Offline
wpa_passphrase generates the PSK using pbkdf2 and sha1 from the SSID and passphrase.
The generated PSK is not comparable to a password hash that protects a plain text password from being read.
The PSK itself, though technically being a hash, is also a secret!
There is no way to store a password safely and to be able to recover it. This is a contradiction.
Either you use a one-way hash function and are not able to recover the password from it, or you store it in such a way that it is recoverable.
As a middle course, you could use a keyring to store your secrets in an encrypted manner.
However, if an attacker gets hold of your keyring's master password, your entire keyring will be compromised.
The most secure way is to not store secrets at all and only enter them on demand.
Last edited by schard (2022-10-26 10:37:14)
Inofficial first vice president of the Rust Evangelism Strike Force
Offline
Hi Videl and Schrad, thanks so much for the info. My normal approach has always been not to store passwords and always being prompted to introduce it whenever I use VPN, ssh, read my email, etc ... but honestly I am getting a bit tired of typing my password 30 times a day ... moreover, with the complicated passwords I am asked to produce my rate of mistyping increases. So I end up typing passwords 100 times a day ... it is so cumbersome. I have seen that neomutt accepts a gpg key file in the .conf file (https://wiki.archlinux.org/title/Mutt#P … management) so I could use that, but I still need to introduce the master password ... maybe I should do that: at least I use always the same password and the probability of error would decrease. I have also seen that for vpnc.conf it is possible to generate a hash (https://github.com/coldfix/cisco-encrypt)
Offline
Depending on your intentions, have a look at
https://wiki.archlinux.org/title/Dm-cry … _container
https://wiki.archlinux.org/title/Tomb
You can put the configs w/ sensitive data there, add symlinks in their canonical places and decrypt & mount the container at login (and umount it at logout or on a timer or whenever)
Online
You mention wpa_supplicant which I can't speak to, but IWD supports profile encryption when using systemd. This is an experimental feature but may be worth checking out:
Offline
What do you want to protect these passwords from? In the case of mutt, the password is needed by a program that runs as a regular user, so you have a choice to either A) have the password not accessible by a process run as an ordinary user and re-enter it manually each time you want to sync/check mail, or B) have the password accessible by processes run as an ordinary user in which case it could be grabbed by anyone who is able to run code on your machine. It's one or other other. Any any hashing or other steps can obscure the facts of which condition you are in but cannot create any other conditions (i.e., cannot add security).
So decide which condition (A or B) you'd rather be in. Then forget about obfuscating passwords, and either put them in the config file, or leave them out. Additionally, you can move between conditions: encrypt your data and config files. While encrypted, anyone who gets access to your machine cannot read the passwords or anything else in the configs (condition A). While unencrypted, they can be read (condition B). You can't, however, have data in both states at once.
As noted above, the hashed passwords in wpa_supplicant are sufficient to connect (thus they aren't really hashed passwords ... they are just passwords, obscure-looking though they may be). They are really a false sense of security in my view (perhaps the only use case is when the same password is used for multiple services which is iteself a bad idea; stealing the hashed wpa password would allow one to connect to your network, but not give them access to the plain text password [as far as I know] for them to use on other services of yours).
Last edited by Trilby (2022-10-26 20:14:17)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline