In the context of looking for a secure way to send out feeds (RSS, Atom, …), I found several options:
- Use basic access authentication to prompt a user name and password before granting access. This is supported by quite a lot feed readers and browsers (where you have to enter your credentials).
- Advantage: Easy to use, Rails 2.0 provides a method for it: authenticate_or_request_with_http_basic
- Disadvantage: Very insecure as the user name and password is send in plain text over the net (encoding is not encryption), everyone could sniff the network traffic and read the login credentials. Also, it is vulnerable to phishing.
- Digest access authentication works basically the same, but encrypts the user name/password and other values using MD5 before sending.
- Advantage: No clear text passwords will be transmitted, much more secure than basic authentication, but it is not intended to replace strong authentication
- Disadvantages: The clear text password or the HA1 hash (MD5(user:realm:password)) must be stored on the server. If someone gets access to it, he may use rainbow tables to compute the password. This takes very very long for such long strings, but fortunately the user name and realm is known and the password can be found relatively fast, especially if it is a weak password from a dictionary.
Also it is vulnerable to Man in the middle attacks. - Do not prompt the user name/password that the user uses to login to the web application. Maybe you set up another special user name which is allowed to view the feed, only. Keep in mind to turn off sessions for feeds (session :off). If you don't, and someone gets hold of the special user's credentials, he will have a valid session not only for the feed but (possibly) for the application, too.
- There is a plugin for Rails: htdigest :user=>"maiha", :pass=>"812b1d067e9ce1e44f09215339e3cd69", :type=>:crypted
or in a table: htdigest :class=>"FeedUser", :user=>"login", :pass=>"ha1" - Digest authentication is far better, but has its weaknesses. If you use it to authenticate access to a feed, it will be alright. Consider using a different user model though.
- Update: Create a long URL which grants access to the feed. However, the URL becomes the password and can be seen in plain text traveling through the net. It's good over SSL, though.
- This is an interesting solution. The plugin Greasemonkey is evil though, well if you don't know the particular script.
- Use basic access authentication over SSL. Probably the best solution, as it encrypts the feed and the user name/password in transit. The tradeoff, however, is the slower speed
Any comments?
