Authenticated feeds

Support requests, bug reports, etc. go here. Dedicated servers / VDS hosting only
jdelamater99
Bear Rating Master
Bear Rating Master
Posts: 109
Joined: 11 Apr 2013, 17:45

Authenticated feeds

Postby jdelamater99 » 12 Apr 2013, 18:32

ttrss_feed_auth.jpg
ttrss_feed_auth.jpg (21.77 KiB) Viewed 3475 times
I was in the process of migrating servers, and noticed that my starred articles didn't get moved over. And before I found the import/export plug in for saving out starred articles, I was digging through the db to see if I could find out how they were stored, and determine how difficult it would be to move them by hand if necessary.

Anyways, while looking through the ttrss_feeds table, I noticed that two of my feeds had authentication turned on, and that the passwords were stored in plain text, which is something that I absolutely do not want.

I did a search, and didn't find anything related to this, so when I get a chance, I'm going to start digging through the code and implement 2-way encryption, so this data isn't just sitting there for everyone to see, should there ever be a compromise.

I'll post updates here, for anyone that's interested.

craywolf
Mr. Awesome
Posts: 97
Joined: 19 Mar 2013, 18:07

Re: Authenticated feeds

Postby craywolf » 12 Apr 2013, 18:57

jdelamater99 wrote:I noticed that two of my feeds had authentication turned on, and that the passwords were stored in plain text, which is something that I absolutely do not want.

I did a search, and didn't find anything related to this, so when I get a chance, I'm going to start digging through the code and implement 2-way encryption


TT-RSS will need to be able to decrypt the password into plaintext. To do this, it needs to store the decryption key. That key should be unique, either per-install (OK), per-user (better), or per-feed (best). If an attacker has compromised your database, where are you going to put the decryption key that TT-RSS can get to but the attacker can't?

ibreakcellphones
Bear Rating Trainee
Bear Rating Trainee
Posts: 31
Joined: 28 Mar 2013, 09:49

Re: Authenticated feeds

Postby ibreakcellphones » 12 Apr 2013, 19:13

Just brainstorming, but maybe if you have authenticated feeds, base the decryption key off the user password but store it in a cookie if you have "Remember me" checked. If you don't have it checked, then generate the key on the fly with the entered password once the initial authentication passes. Note that there would have to be two different hashing functions in order to keep the password secure.

jdelamater99
Bear Rating Master
Bear Rating Master
Posts: 109
Joined: 11 Apr 2013, 17:45

Re: Authenticated feeds

Postby jdelamater99 » 12 Apr 2013, 19:17

Wouldn't using a cookie limit you to the computer you accessed the feed from the first time?

jakob42
Bear Rating Trainee
Bear Rating Trainee
Posts: 15
Joined: 20 Mar 2013, 16:43

Re: Authenticated feeds

Postby jakob42 » 12 Apr 2013, 19:32

Cookie wouldn't work, the update method would need to have access to the password, but it runs independent from the browser. And I really would feel much safer with clear text password in the database than in the cookie.

User avatar
fox
^ me reading your posts ^
Posts: 6318
Joined: 27 Aug 2005, 22:53
Location: Saint-Petersburg, Russia
Contact:

Re: Authenticated feeds

Postby fox » 12 Apr 2013, 20:42

>which is something that I absolutely do not want.

You don't say.

jdelamater99
Bear Rating Master
Bear Rating Master
Posts: 109
Joined: 11 Apr 2013, 17:45

Re: Authenticated feeds

Postby jdelamater99 » 12 Apr 2013, 21:55

What about storing the key in the config file, along with the DB information itself. Or, going beyond that, storing it outside of the public_html folder so that it isn't web accessible at all?

User avatar
ezterry
Bear Rating Trainee
Bear Rating Trainee
Posts: 1
Joined: 28 Mar 2013, 08:02

Re: Authenticated feeds

Postby ezterry » 12 Apr 2013, 23:08

I see no way to prevent the web server's user from having access to the plain text of the password.. since the update script will need it to send to the website with the request for the feed.

That said I'd not mind seeing an optional authentication password in the config.php.. that when hashed with a per-authenticated feed salt produced a decryption key of the user/password. The point being not so much that a user of the system.. or someone with full access to your web-user couldn't get the passwords. However it will be harder to access do to a hypothetical sql injection attack (no I don't know of any) or if someone had a dump of the database. (of course my actual backups have dbdump + cfg + feedicons)

That said I'm a bit to lazy to implement such things with a clean transition.. particularly when all feeds on my server with authentication seem to be using insecure http and a quick conversion to base64 encoding makes it so I can't read your password if inadvertently have the column selected when I query the table. (even if its easily decoded if I deliberately decide to do so.. or in the hypothetical attack that somehow successfully access the data) ..

User avatar
fox
^ me reading your posts ^
Posts: 6318
Joined: 27 Aug 2005, 22:53
Location: Saint-Petersburg, Russia
Contact:

Re: Authenticated feeds

Postby fox » 13 Apr 2013, 09:48

Adding insecure encryption is a terrible idea because it promotes false sense of security. I don't see how proper encryption/hashing is possible in this case because updater needs the plaintext password (like said above).

User avatar
fox
^ me reading your posts ^
Posts: 6318
Joined: 27 Aug 2005, 22:53
Location: Saint-Petersburg, Russia
Contact:

Re: Authenticated feeds

Postby fox » 13 Apr 2013, 18:28

After further thinking I suppose it makes sense to add this, in case the hypothetical attacker only accesses the database (e.g. through another app which has shared database with tt-rss). I have been thinking about this earlier, so schema plumbing for this was done years ago.

Anyway, I retract my statement above.

https://github.com/gothfox/Tiny-Tiny-RS ... 0d1d66c746

If FEED_CRYPT_KEY is not empty and mcrypt functions exist, authentication data will be encrypted. This is fully backwards compatible, previously unencrypted passwords will be encrypted when you edit and save the feed.

Installer will default on filling in FEED_CRYPT_KEY if it detects mcrypt functions, otherwise it will leave the constant blank.

jdelamater99
Bear Rating Master
Bear Rating Master
Posts: 109
Joined: 11 Apr 2013, 17:45

Re: Authenticated feeds

Postby jdelamater99 » 13 Apr 2013, 20:55

Awesome! Thank you so much for implementing this.


Return to “Support”

Who is online

Users browsing this forum: No registered users and 9 guests