php 7.1, FEED_CRYPT_KEY, and you

[fox]

so looks like mcrypt is getting axed from php[1], which is why FEED_CRYPT_KEY and encrypted feed passwords are going the way of the dodo

i'm not going to reimplement this via some other encryption library because the overall security effect by having this is minimal, imo - if someone has your database they most likely will be able to get config.php too

look at this commit message for migration details:

https://tt-rss.org/gitlab/fox/tt-rss/co ... cf5cb09067

maybe it is a good idea to auto-decrypt all encrypted passwords automatically as a maintenance task so that people won't get caught with their pants down after upgrading.

1. http://php.net/manual/en/migration71.deprecated.php

[extra808]

I'm on a dreaded shared host where my db is on a separate server so there's plenty of potential for someone to get at my database but not config.php.

I know I used to but I'm not sure I even have any authenticated feeds anymore. What would be a command to find all authenticated feeds?

[fox]

select id from ttrss_feeds where auth_pass != '' etc

[extra808]

107 of 138 feeds have a value in auth_pass, including the feed for this forum (feed.php). However, none of them have a value for auth_login so while I don't know where those passwords came from, they aren't needed and shouldn't contain anything confidential

[atrus]

One thing I've noticed is that Chrome really likes to fill in the feed username/password feeds with auto-completed values it's saved from the ttrss login page when I open the feed editor. Something to watch for anyways, that explained a bunch of unexpected passwords showing up there for me.

[JustAMacUser]

The way TT-RSS was coded it would always encrypt the password field as an empty string. So if those values are the same and auth_login is empty, just ignore it.

[fox]

One thing I've noticed is that Chrome really likes to fill in the feed username/password feeds with auto-completed values it's saved from the ttrss login page when I open the feed editor. Something to watch for anyways, that explained a bunch of unexpected passwords showing up there for me.

this form probably should be set to autocomplete="off"

e: doesn't seem to happen here tho

[fox]

The way TT-RSS was coded it would always encrypt the password field as an empty string. So if those values are the same and auth_login is empty, just ignore it.

those are probably salted so encrypted strings are not going to be exactly same btw

anyway the easiest way is batch-decrypting using update.php and then it should be obvious whether the passwords are of any use

[tsimmons]

Do you have any interest in someone else developing this using another library [probably using openssl_encrypt() and openssl_decrypt()] Personally I like the added security (but my DB and web server are in different locations);

I don't want to hack at it if there is zero interest.

[JustAMacUser]

Might not need to reinvent the wheel as there are libraries out there already. This one seems good (no affiliation):

https://github.com/defuse/php-encryption

[fox]

like i said, the benefit of this is minimal so i think it would be better to just remove this altogether

instead of bolting on some library or w/e and then dealing with it forever

[tsimmons]

Roger that. It looked like openssl_encrypt/decrypt was nearly a drop in replacement for mcrypt's functions but it would require PHP to be built with the OpenSSL extension; No worries.