One of the items on the docs page for this item says:
" Explore/research other methods of opening up RSS in a safe way to the outside world."
Is there any reason that we're preferring obscurity (weird and long urls with a key a la google calendar) to using something like basic auth?
Most (surely almost all) rss readers support basic, at least the ones I've had anything to do with.
We just encountered this same problem with Mahara and after a long discussion about it we decided to go with basic:
http://git.catalyst.net.nz/gw?p=mahara.git;a=shortlog;h=refs/heads/rss
Many major clients don't, including big names like Windows Vista and IE 7, as well as Google Reader, and so on.
Even Firefox Live Bookmarks doesn't support it, although I hear a workaround for it, and perhaps other clients, is to include the username and password in the URL.
That just isn't good enough, as an exposed password in the URL is an exposed password. On top of that, you'd need to ensure the server, e.g. Apache, was configured to handle basic auth and could properly auth with Moodle.
By using private URLs, it means that we can generate our own secure hashes, track its use if necessary, and if the URL ever leaks, we could blacklist and generate a new hash, while maintaining security for the password. And a user would never be confused by having to type in yet another username and password once logged in.
Such URLs are already standard practice with Google Calendar and Basecamp, etc. so users familiar with RSS and feed readers will understand the concept, while basic auth is still rare.
Even Firefox Live Bookmarks doesn't support it, although I hear a workaround for it, and perhaps other clients, is to include the username and password in the URL.
That just isn't good enough, as an exposed password in the URL is an exposed password. On top of that, you'd need to ensure the server, e.g. Apache, was configured to handle basic auth and could properly auth with Moodle.
By using private URLs, it means that we can generate our own secure hashes, track its use if necessary, and if the URL ever leaks, we could blacklist and generate a new hash, while maintaining security for the password. And a user would never be confused by having to type in yet another username and password once logged in.
Such URLs are already standard practice with Google Calendar and Basecamp, etc. so users familiar with RSS and feed readers will understand the concept, while basic auth is still rare.
Yes, and further: we really don't want to be encouraging users to start storing their Moodle/Mahara usernames and passwords all over the web in other systems ...
Feed readers are just one type of client, there are all sorts of other RSS consumers (even Moodle has one).
Feed readers are just one type of client, there are all sorts of other RSS consumers (even Moodle has one).
>> On top of that, you'd need to ensure the server, e.g. Apache, was configured
>> to handle basic auth and could properly auth with Moodle.
This part at least is not true. You can get PHP to do basic auth from within the application.
>> to handle basic auth and could properly auth with Moodle.
This part at least is not true. You can get PHP to do basic auth from within the application.
Have you actually tried basic auth in any feed readers? IE7 works fine, it pops up the basic auth dialog as you'd expect. Firefox's live bookmarks does the same thing. Google reader doesn't support it, as you say. [1] There's mixed support from reader to reader after that (linked document from 2003), though the trend over time has been for more applications to support it.
As Penny said - basic auth has nothing to do with apache. The git branch linked to shows a perfectly working method in pure PHP. It's only a few lines of code.
Also, if the user is logged in to the site and clicks on the feed, they're not made to do basic authentication, because they already sent a valid cookie. There's no confusing extra step involved.
I grant that obscure URLs are, as Martin says, better in terms of not giving out your password to other systems. They do have the advantage that you're only giving access to certain information about the user, rather than details that a hacker could use to impersonate a user. But they don't seem like the best solution to this problem either - once discovered, they allow anyone to see the data, and I doubt users will be as careful protecting a fancy URL compared to a password. Talk of regenerating hashses is moot. Users can change their password just as easily as you can regenerate them a hash, and are probably less likely to recognise when a hash has become compromised.
Perhaps a better solution than either would be something like Oauth - which allows you to export private data to allowed applications without exposing usernames and passwords.
To summarise my thoughts - HTTP basic auth is more secure, until the user wants to use the feed in another system, when token URLs become safer. There are probably better methods than either.
Background reading:
http://instantbadger.blogspot.com/2007/08/perennial-rss-authentication-dilemma.html
http://labs.silverorange.com/archives/2003/july/privaterss
http://blog.jonudell.net/2007/03/27/authenticated-rss-feeds/
[1] You can try with this feed
Edit: linkified URLs
As Penny said - basic auth has nothing to do with apache. The git branch linked to shows a perfectly working method in pure PHP. It's only a few lines of code.
Also, if the user is logged in to the site and clicks on the feed, they're not made to do basic authentication, because they already sent a valid cookie. There's no confusing extra step involved.
I grant that obscure URLs are, as Martin says, better in terms of not giving out your password to other systems. They do have the advantage that you're only giving access to certain information about the user, rather than details that a hacker could use to impersonate a user. But they don't seem like the best solution to this problem either - once discovered, they allow anyone to see the data, and I doubt users will be as careful protecting a fancy URL compared to a password. Talk of regenerating hashses is moot. Users can change their password just as easily as you can regenerate them a hash, and are probably less likely to recognise when a hash has become compromised.
Perhaps a better solution than either would be something like Oauth - which allows you to export private data to allowed applications without exposing usernames and passwords.
To summarise my thoughts - HTTP basic auth is more secure, until the user wants to use the feed in another system, when token URLs become safer. There are probably better methods than either.
Background reading:
http://instantbadger.blogspot.com/2007/08/perennial-rss-authentication-dilemma.html
http://labs.silverorange.com/archives/2003/july/privaterss
http://blog.jonudell.net/2007/03/27/authenticated-rss-feeds/
[1] You can try with this feed
Edit: linkified URLs
I grant that obscure URLs are, as Martin says, better in terms of not giving out your password to other systems. They do have the advantage that you're only giving access to certain information about the user, rather than details that a hacker could use to impersonate a user. But they don't seem like the best solution to this problem either - once discovered, they allow anyone to see the data, and I doubt users will be as careful protecting a fancy URL compared to a password.
I agree there is not really good solution, but I just prefer to go with the the fancy urls. It may not be the worlds best security, but they are of limited risk [read only, only a specific forum] vs the huge risk of username/passwords being compromised, particularly when tied to other external authentication systems.
(And afterall, we currently just display rss feeds to all without any magic at the moment, so its a small step forward if not rock-solid).
(I am biased as I use google reader ;) )
I think if someone can steal your private URL, then it won't be a really big problem for him to steal login and password too.
Of course, it's a little bit more difficult, but I think this small difference is not worth the risk of the username/passwords being compromised.
Of course, it's a little bit more difficult, but I think this small difference is not worth the risk of the username/passwords being compromised.
I may be incorrect and/or out of date, here, but I thought security based on the obscurity/secrecy of a URL was considered weak because URLs leak all over the place, e.g:
- browser history (particularly relevant on shared computers)
- HTTP Referrer tag (particularly relevant if the feed contains a link to another site)
- proxies
- anybody sniffing the local subnet
I don't know what the solution is but I think security by obscurity is not the way to go. However, I agree that basic auth is no better and arguably worse because at least a compromised URL would (hopefully) only compromise a single feed.
- browser history (particularly relevant on shared computers)
- HTTP Referrer tag (particularly relevant if the feed contains a link to another site)
- proxies
- anybody sniffing the local subnet
I don't know what the solution is but I think security by obscurity is not the way to go. However, I agree that basic auth is no better and arguably worse because at least a compromised URL would (hopefully) only compromise a single feed.
You are absolutely right about security through obscurity. However, this is a common work-around used by many web applications for the fact that RSS readers do not support any forms of proper security. So it is definitely a compromise.
However, it is not that bad a compromise. To start with, the intention is that you generate one of these obscure URLs and then copy and paste that URL into your RSS reader, and then don't use it for anything else. So that URL may never be visited in your browser, or at most visited once. It will never appear as a referrer. Proxies are a problem, as is subnet sniffing. If you are transmitting really secure data over HTTP you should be using HTTPS instead.
And this URL does not give complete access to your Moodle login. It just gives acces to a certain part of data. There is no way to go from that to full access to your account.
So, the consensus among web application designers is that this is a tolerable compromise.
However, it is not that bad a compromise. To start with, the intention is that you generate one of these obscure URLs and then copy and paste that URL into your RSS reader, and then don't use it for anything else. So that URL may never be visited in your browser, or at most visited once. It will never appear as a referrer. Proxies are a problem, as is subnet sniffing. If you are transmitting really secure data over HTTP you should be using HTTPS instead.
And this URL does not give complete access to your Moodle login. It just gives acces to a certain part of data. There is no way to go from that to full access to your account.
So, the consensus among web application designers is that this is a tolerable compromise.