From: Trevor H. <tre...@th...> - 2006-09-07 20:43:27
|
Christopher Murtagh wrote: > On 9/7/06, Shawn <sg...@op...> wrote: >> The case here is only PARTIALLY an SQL-Ledger problem (IMO). Yes, the >> authentication process can be made stronger. But show me an application >> where that is not the case. > > Shawn, > > It's clear that you do not understand the severity of the design > flaw. There are very few apps that have this sort of problem. Web > based authentication can be made to be very secure (otherwise you > wouldn't have online banking), the current problem with SQL-Ledger is > that it is not secure at all. > >> THe problem with the cookies is NOT an SQL-Ledger specific problem. > > Wrong. The problem isn't that the system is using cookies for > authentication. The problem is that the cookie content is simply the > users name and a timestamp. The equivalent in the physical world would > be that to withdraw from the bank, all you need to do is provide them > with your name and the time of day without any verification that you > are who you say you are. > > For me to get access to any SQL-Ledger server all I have to do is > create a cookie (a trivial thing to do) called 'SQL-Ledger-shawn' and > give it a value which is the current unix epoch time. This completely > bypasses any credential verification done in the software. Clearly, a > big problem. To make matters worse, if I created a cookie called > 'SQL-Ledger-root login' with the current timestamp, I could access the > admin script, which would give me all the user names and the ability > to change passwords, create accounts, delete datasets, etc.. So, in > this case, I don't even need to know the users login name. > >> The way the info in the cookies can be used on the URL is. EVERY browser >> out there will have the same flaw with the cookies. So how is Dieter to >> fix that? Does he contact Microsoft, Mozilla, KDE, etc. and submit a >> patch for their browsers? Or does he focus on the SL specific problems. > > Like I said, this is not a browser or a cookie problem, it is a > design flaw in the application, proof being that our patch solves the > cookie problem completely. > >> I do not see a disregard for this issue at all. It has been discussed >> on the list. Dieter has stated where he thinks the problem to be, and >> that the issue is browser and/or environment related. > > And that is part of the problem. Dieter doesn't seem to understand > the flaw, while many others do. > >> Chris himself has >> pointed out a fix for the issue that does not involve code - put the SL >> sites behind SSL. Or require .htaccess authentication. Both of these >> are very simple solutions, and *could* be a recommeneded practice for >> running SL. > > Using SSL does not proctect you from this design flaw in any way. A > .htaccess solution would be fine for some, provided that the > installation has only one account. If you have multiple accounts on > the same server, then you would need to change the code to get the > username from the authenticated user according to apache (and have > them sync with the members file). > > Cheers, > > Chris > Passing clear text passwords across the Internet is always wrong, so using a secure web server which requires the additional login to the https server first should be standard practice - it is for any system I configure. So using SSL WILL protect MOST of the users of SQL-Ledger - those that have the need to access their accounts across the Internet, that is. If your SQL-Ledger server is not accessible from the Internet you have far less to worry about. As you say it is when you have multiple accounts - ie a hosted SQL-Ledger application for a number of different companies that you have the main problem. That reduces the number of people affected. Undoubtedly the problem should be fixed - but it does NOT affect all SQL-Ledger users, so I think some proper reporting of the vulnerability is required - currently it sounds like scare mongering - or does it just happen to coincide with this fork? If any one need help setting up a secure web server let me know. Regards Trevor Hennion http://www.infocentrality.co.uk |