Irssi: Stop storing passwords in plaintext

[redconnection]

Unfortunately irssi currently stores passwords in plaintext. There are well-known workarounds that have been implemented, however, it would be great to see this functionality built-in into irssi itself.

Thanks

[ahf]

This is something we have discussed multiple times in the community and whilst I am aware that other clients does support this feature, I don't think this is something we should prioritise right now.

I am not sure I fully understand what it is that you will get from this? You can protect yourself from other users on a shared system using the UNIX permission system. You can't, however, protect yourself against a malicious root. For the encrypted passwords to be usable, we would have to store the key in memory and root would easily be able to attach a debugger to your irssi process and fetch the key and thus steal your encrypted passwords. I do give you that it would be an extra layer of security, but not a very giving layer.

There are also quite a few different ways we "authenticate" to IRC servers: operators via the OPER command, SASL, Quakenet's Q, NickServ, X, ChanFix, etc. and all of them have different formats that people tend to store in their configuration files - we would have to do something a la what weechat does to support this.

I am going to leave this bug as open, but it's not something I am going to prioritise unless I hear some valid use cases for this other than "$client does this!" :-)

[Hello71]

the only reasonable threat model here is one of an offline attacker, i.e. someone removes the hard drive from your computer and scans it for passwords.

obviously the attacker cannot be stopped if one continues using the computer, but we can protect against the other case where one does not.

the counter to this attack is to encrypt the password with a key and then preferably store it in some central wallet or password manager.

unfortunately, irssi is sufficiently configurable and scriptable (as ahf has said) that it would not really be feasible to implement wallets in irssi core; however, it should be easy to use WhateverWalletManagerYouWant; in a perl script that would authenticate for you.

[hoffoo]

I would think most people have their disks encrypted, irssi would be my last concern if I were susceptible to an offline attack.

How much more of a pita will be for people to use gnome-wallet-manager or kdewallet on a remote shell shell with no X?

[squidsoup]

One usecase for keeping passwords out of the config, is storing the config along with other dotfiles on a codehosting service like launchpad or github. It is convenient to bootstrap a new environment very quickly this way, but currently irssi needs to be reconfigured manually, or the config restored from backup.

[ygt-mikekchar]

I'm having a similar problem. Just to explain the issue, I use irssi to log into slack. Slack uses an application password (not of my choosing and not particularly memorable) for logging into their service. I also work on many different machines and I need to keep my config files (including the one for irssi) synced on all my different machines. I use Github to do this.

At the moment I can not sync my irssi config file with this method because anybody who has access to my Github repository (currently the whole world) will have access to my Slack account. As others have said, there are many, many workarounds that I could do (for example use a shim that seds the password into the config file when I run the app, or store the entire config file in Github encrypted), but they are all fairly sub-optimal.

The solution needn't actually encrypt passwords in the config file, there just needs to be a way to inject passwords from a separate file (as in https://github.com/irssi/irssi/issues/246). Even simply having a kind of #include in the config file so that the server command could go in another file would go a long way to helping.

[colemickens]

+1

Most of the workarounds have disadvantages as well. I was starting to implement the sed method, but realized that I will basically never be able to /save again with that workflow.

[ailin-nemui]

The following two links may provide some practical hints for those who are interested in the passwords mainly for github: https://github.com/jotrk/etc.irssi/blob/2a5e44fc297c45c594a39f94404dbff0b8a2e424/.irssi/readme.md https://github.com/oohlaf/dotsecrets/

[ewilazarus]

+1

[WhyNotHugo]

swick/irssi-passwd has a script that allows loading the password from an external command, but it requires patching irssi. Is there any chance that this patch makes it into master (I don't see any PRs or other issues mentioning it, sorry if it's been rejected for some reason before).

TPH, that script cover pretty much all reported variations of "keep password out of the config file", (eg, .netrc, using pass, keyrings, etc).

[XVilka]

Is this still a case in 2019?

[dequis]

Yes

[JL2210]

Can't we just bitwise-XOR each character with a few random bits (i.e. 0xA5) and store those along with the password? That would be the quickest most trivial implementation that prevents the most basic attacks.

[dequis]

No

[dequis]

The main reason this isn't moving forward isn't anything like "cryptography is hard", but the fact that we have to decide an approach that is clean and makes everyone happy (or at least covers most use cases).

Easily reversible obfuscation protects nothing and makes no one happy.

[WhyNotHugo]

Can't we just bitwise-XOR each character with a few random bits (i.e. 0xA5) and store those along with the password? That would be the quickest most trivial implementation that prevents the most basic attacks.

This is an awful idea -- it makes people think their passwords are safe, and they're not. A false sense of security is worse than no security.

There's a bit more discussion on this topic in Pidgin's wiki, since they've had the same problem.

[XVilka]

Easiest approach that is possible right now is just to implement the include directive: https://github.com/irssi/irssi/issues/1050

[WhyNotHugo]

include still means it's in plaintext elsewhere. I'd much rather be able to specify a command to run to fetch it (eg pass).

[machinedgod]

I have tried the proposed patch (which seems to work very similar to mutt, which is good), it did not work for me, but that's besides the point - what I'm curious is, why isn't that patch applied to master and this problem fixed?
P.S. regarding the script: code needs $server in order to do its work, so it doesn't execute correctly if I'm not connected to any servers -I think-, and it works fine if I execute it through a command after i manually establish the connection.

[leocp1]

An alternative is to put a login script in ~/.irssi/scripts/autoload/:

sub escpw {
    my ($pw) = @_;
    $pw =~ s/\\/\\\\/g;
    $pw =~ s/'/\\'/g;
    return $pw;
}
# Use instead if password is sent in autosendcmd
# See parse_special_string in src/core/special-vars.c
sub escasc {
    my ($pw) = @_;
    $pw =~ s/\\/\\\\/g;
    $pw =~ s/;/\\;/g;
    $pw =~ s/\$/\\\$/g;
    return escpw($pw);
}
# arbitrary shell command
my $pw = escpw(`pass show IRC/freenode`);
# arbitrary irssi command
Irssi::command( 'network add '
    . '-sasl_username leocp1 '
    . "-sasl_password '${pw}' "
    . '-sasl_mechanism PLAIN '
    . '-autosendcmd \''
    . 'wait 2000; '
    . 'server remove chat.freenode.net; '
    . 'network remove freenode; '
    . '\' freenode' );
# ... etc

Caveat emptor: the string escaping functions may be incorrect, and there are cleaner ways to use the perl bindings to log in.