From: Christopher M. <chr...@gm...> - 2006-09-07 18:01:06
|
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 |