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?
Bookmark to
13 responses so far ↓
1 Ned Baldessin // Oct 18, 2007 at 15:08
You didn’t mention that using username/passwords for feeds requires the user to enter those credentials in his feedreader.
Why not generate a very long URL, and offer to possibility to “regenerate” the URL if the user thinks the link has been compromised ?
2 Heiko // Oct 19, 2007 at 1:02
I updated the text to clarify the username/password thing.
The problem with long URLs as a key to the feed is, that it is basically a password which is sent unencrypted over the net. So it’s the same problem as with basic auth: anyone who sniffs your traffic can read the feed and use the URL as long as it stays valid. And how does the user notice that the link has been compromised?
Well, it depends on what level of security you need. Should be good over SSL, though.
3 Tammer Saleh // Oct 20, 2007 at 5:35
bq. 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.
While SSL encrypts the body of the url being used, I didn’t think it encrypted the transmission of the url itself. I may be wrong about that, though.
4 Heiko // Oct 20, 2007 at 7:22
SSL encrypts everything.
5 HTTP Authentication and Feed Security // Oct 21, 2007 at 12:25
[…] HTTP Authentication and Feed Security: […]
6 Bolo // Oct 22, 2007 at 4:47
if we use basic auth and https. we have same problem for sniffing ?
7 Heiko // Oct 22, 2007 at 6:31
HTTPS encrypts the data traveling over the network, so it is generally safe. Your data can be sniffed, but an attacker can’t decrypt it.
8 Bolo // Oct 22, 2007 at 10:48
Heiko > thanks and an other question. If i use basic access authentication with a rest API.
i have a code like that
xml = open(’https://api.test.com/posts’,
http_basic_authentification => [username,password])
username and password can be sniffed , an attacker can decrypt them ?
9 Heiko // Oct 23, 2007 at 2:42
No matter if it’s an API, XML file or whatever, it travels over http(s). The rule is as simple as that: basic auth with http is unsafe, with https it is safe and the attacker can’t decrypt it (i.e. your example seems safe).
The encrypted text, however, always can be sniffed, but it’s harder if the communication is between two servers on the net, but do not rely on that. Try to sniff https traffic on your own computer, e.g. with Ethereal.
10 Bolo // Oct 23, 2007 at 6:01
thanks
11 Gerald // Oct 27, 2007 at 21:39
Does anyone on this page know of a program that will provide me with a security vulnerability assessment tool? None of the ones I’ve tried so far have really done much for me except frustrate me. I’ve detected threats better manually than these programs did. While you at it does anyone know where I might find an all inclusive program that will give me superior desktop security? Right now the only ones I run are ad aware and spyware which only seem to find a small portion of the things that could potentially put my computer at risk. It’s time for a change and I need a tool that will allow me to do a complete Security Risk Assessment but I’m just not sure where to start. My network security research hasn’t really turned anything up yet.
12 til // Jan 28, 2008 at 11:21
What’s the point of securing data (ie. a feed) with a login when it is then sent unencrypted over the network anyway? Shouldn’t it either be SSL always for authenticated traffic that is worth protecting, or unauthenticated traffic without SSL?
13 Eric Larson // Feb 1, 2008 at 9:16
There is also WSSE authentication which just implements WS-Authenticated (or whatever it is called) using only HTTP (more or less). It is relatively secure if you aren’t using SSL/TLS and a bit simpler to implement than digest if you are doing it yourself.
Leave a Comment