« restful_authentication login security | Main | Rails 1.2.5 security release »
Friday
Oct192007

HTTP Authentication and Feed Security

DateFriday, October 19, 2007 at 12:02AM

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?

AuthorHeiko | Comment17 Comments |

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (17)

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 ?

October 19, 2007 | Unregistered CommenterNed Baldessin

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.

October 19, 2007 | Unregistered CommenterHeiko

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.

October 20, 2007 | Unregistered CommenterTammer Saleh

SSL encrypts everything.

October 20, 2007 | Unregistered CommenterHeiko

[...] HTTP Authentication and Feed Security: [...]

October 21, 2007 | Unregistered CommenterHTTP Authentication and Feed S

if we use basic auth and https. we have same problem for sniffing ?

October 22, 2007 | Unregistered CommenterBolo

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.

October 22, 2007 | Unregistered CommenterHeiko

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 ?

October 22, 2007 | Unregistered CommenterBolo

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.

October 23, 2007 | Unregistered CommenterHeiko

thanks :)

October 23, 2007 | Unregistered CommenterBolo

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 but I’m just not sure where to start. My network security research hasn’t really turned anything up yet.

October 28, 2007 | Unregistered CommenterGerald

Cheap purchasing.World of Warcraft,wow gold Super ...buy cheap wow gold,sell wow gold.Welcome to buy cheap wow gold.We can have wow gold, game,world of warcraft gold,wow Gold, world of warcraft gold deal,Cheap WOW Gold...Welcome to our website for ,buy cheap wow gold,sell wow gold.Welcome to buy cheapest wow gold.World of warcraft gold,Super fast delivery of gold...purchasing.World of Warcraft,wow gold Super.

December 27, 2007 | Unregistered Commenterwow gold

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?

January 28, 2008 | Unregistered Commentertil

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.

February 1, 2008 | Unregistered CommenterEric Larson

Thank you for sharing such good experience.I also like to write such things in own blog. Our iwc replica watches

August 25, 2010 | Unregistered CommenterEunice J. Garner

Solar Power Charger has been in the the success of different ways one of many scientists. Then, the designer come in? In fact, they come to their different ideas on how to innovate. Moreover, these articles and tools variety show with different options and choices.

August 30, 2010 | Unregistered Commenterjing

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

Notify me of follow-up comments via email.