Burton M. Strauss III wrote:

Nope ... ntop's passwords are completely self contained in the ntop_pw.db
file.  Simple crypt() of the value.

You're right, 1admin etc. is the database key...

# dumpgdbm /usr/share/ntop/ntop_pw.db
'2resetStats': 'users=1admin'
'    1admin': 'xxxxxxxxxxx'
'    2showU': 'users=1admin'
'     2shut': 'users=1admin'
'    2chang': 'users=1admin'
'  2deleteU': 'users=1admin'
'2privacyFlag': 'users=1admin'
'  2modifyU': 'users=1admin'
Records read: 8

1s are users
2s are url (prefix) for security.

So 2shut means that any url begining shut is secured, and that the permitted
userid is admin.

But you're seeing something totally different than I am... the

URL_DEBUG: read HTTP header line: Authorization: Basic MWFkbWluOg== [33]

means ntop IS receving the userid/password from the browser.

Feb 8 20:43:02 mainframe ntop[30504]: URL_DEBUG: Retrieving '2showU'

Means you're pulling it out of the database and

Feb 8 20:43:02 mainframe ntop[30504]: URL_DEBUG: gdbm_fetch(...,
'2showU')='users=1admin'

means it did read the record fine.  What was the next few messages???  Those
will tell you if the password check permitted or failed the test (maybe you
just are typing the wrong password...)

-----Burton





-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf
Of Jaco van Tonder
Sent: Sunday, February 08, 2004 12:57 PM
To: Burton M. Strauss III
Cc: [EMAIL PROTECTED]
Subject: Re: [Ntop-dev] [FreeBSD 5.2.1-RC] Web authentication not
working ?


Burton M. Strauss III wrote:




Now that's a brass plated b*tch of a problem to test manually. Problem
is that the authentication is sent via HTTP headers, not as part of
the url. The only tool I know of that lets you construct the complete
request like that is Aman's software's webbug. (Win32, free). But
you'll have to construct valid data for the header... meaning a proper
crypt of the password.

Internally to ntop, however, you *can* see what's going on. Turn on
(globals-defines.h) URL_DEBUG, you will get the details of the HTTP
headers being received and interpreted... Here’s the initial request –
note the 401 and WWW-Authenticate – that’s ntop asking for the password:



Burton,

I did turn on the URL_DEBUG knob, and also changed the contents of
http.c to show the crypted password.

Here is the output that I get from the debuggin now:
Feb 8 20:43:02 mainframe ntop[30504]: URL_DEBUG: read HTTP request line:
GET /showURLs.html HTTP/1.1 [27]
Feb 8 20:43:02 mainframe ntop[30504]: URL_DEBUG: read HTTP header line:
Host: mainframe.savuti.co.za:3000 [33]
Feb 8 20:43:02 mainframe ntop[30504]: URL_DEBUG: read HTTP header line:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5)
Gecko/20031007 Firebird/0.7 [95]
Feb 8 20:43:02 mainframe ntop[30504]: URL_DEBUG: read HTTP header line:
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,tex
t/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
[146]
Feb 8 20:43:02 mainframe ntop[30504]: URL_DEBUG: read HTTP header line:
Accept-Language: en-us,en;q=0.5 [31]
Feb 8 20:43:02 mainframe ntop[30504]: URL_DEBUG: read HTTP header line:
Accept-Encoding: gzip,deflate [29]
Feb 8 20:43:02 mainframe ntop[30504]: URL_DEBUG: read HTTP header line:
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 [46]
Feb 8 20:43:02 mainframe ntop[30504]: URL_DEBUG: read HTTP header line:
Keep-Alive: 300 [15]
Feb 8 20:43:02 mainframe ntop[30504]: URL_DEBUG: read HTTP header line:
Connection: keep-alive [22]
Feb 8 20:43:02 mainframe ntop[30504]: URL_DEBUG: read HTTP header line:
Referer: http://mainframe.savuti.co.za:3000/Admin.html [54]
Feb 8 20:43:02 mainframe ntop[30504]: URL_DEBUG: read HTTP header line:
Cookie: SITESERVER=ID=3dfb2ec82f0afd56bc9276aa5d370469 [54]
Feb 8 20:43:02 mainframe ntop[30504]: URL_DEBUG: read HTTP header line:
Authorization: Basic MWFkbWluOg== [33]
Feb 8 20:43:02 mainframe ntop[30504]: HTTP/I18N_URL_DEBUG: Requested URL
= '/showURLs.html', length = -1
Feb 8 20:43:02 mainframe ntop[30504]: HTTP/I18N_URL_DEBUG: User-Agent =
'Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
Firebird/0.7'
Feb 8 20:43:02 mainframe ntop[30504]: HTTP/I18N_URL_DEBUG: Referer =
'http://mainframe.savuti.co.za:3000/Admin.html'
Feb 8 20:43:02 mainframe ntop[30504]: URL_DEBUG: uri is '/showURLs.html'
Feb 8 20:43:02 mainframe ntop[30504]: URL_DEBUG: Checking
password-protect for '/showURLs.html'
Feb 8 20:43:02 mainframe ntop[30504]: URL_DEBUG: Retrieving '2showU'
Feb 8 20:43:02 mainframe ntop[30504]: URL_DEBUG: gdbm_fetch(...,
'2showU')='users=1admin'

I am not completely sure what the value "1admin" means, but I guess that
it is the index in the database file and the username.
I will fiddle a bit more and see if I can maybe add both the sent
password and the existing password to the debug output, and see
if they match. I am baffled here. :/

Maybe it has something to do with the fact that I set the default
encryption scheme for FreeBSD to blowfish ? (ie /etc/auth.conf)

Will keep you posted.
Regards
Jaco
_______________________________________________
Ntop-dev mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev




_______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev



Shyte, sorry, didnt paste it all.

Feb 8 21:39:56 mainframe ntop[36924]: HTTP/I18N_URL_DEBUG: Referer = 'http://mainframe.savuti.co.za:3000/Admin.html'
Feb 8 21:39:56 mainframe ntop[36924]: URL_DEBUG: uri is '/showURLs.html'
Feb 8 21:39:56 mainframe ntop[36924]: URL_DEBUG: Checking password-protect for '/showURLs.html'
Feb 8 21:39:56 mainframe ntop[36924]: URL_DEBUG: Retrieving '2showU'
Feb 8 21:39:56 mainframe ntop[36924]: URL_DEBUG: gdbm_fetch(..., '2showU')='users=1admin'
Feb 8 21:39:56 mainframe ntop[36924]: URL_DEBUG: User='admin' - Pw='admin'
Feb 8 21:39:56 mainframe ntop[36924]: URL_DEBUG: Record='1admin' = '$2a$04$9u....'


I think the reason it is failing is because of the blowfish encryption.
What is the length of the field that is holding the password in the database? As you can see from the output, the password is in blowfish
format. However, I dont think that the complete encrypted password actuall fits into the database and then cannot be
validated as it does not match. I will put the default encryption to des3 now and try again.


I definately type the password right. ;)

Thanks for helping so far. I am sure I will squash this within the next hour or so. :)

Regards
Jaco
_______________________________________________
Ntop-dev mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev

Reply via email to