How about giving me the data I asked for? What are the next messages in the
log? It's either this:
Feb 8 09:27:54 tigger ntop[13192]: URL_DEBUG: Retrieving '2shut'
Feb 8 09:27:54 tigger ntop[13192]: SECURITY: request for url
'shutdown.html' disallowed
or this:
Feb 8 09:22:30 tigger ntop[12129]: URL_DEBUG: Retrieving '2shut'
Feb 8 09:22:30 tigger ntop[12129]: URL_DEBUG: Page: 'shutdown.html'
The first means the passwords don't match, the second means they did and
ntop is returning the page.
If you are sure you are tyring password correctly, then just delete
ntop_pw.db and recreate it.
Now, as to the other - unless you've got some perverted crypt() function,
get off the fish-wagon!
Listen to me. THERE IS NO BLOWFISH CODE IN NTOP.
Read the code in admin.c:
strncpy(cpw, (char*)crypt(value, (const char*)CONST_CRYPT_SALT),
sizeof(cpw));
Read the man page:
# man crypt
CRYPT(3) Library functions
CRYPT(3)
NAME
crypt - password and data encryption
SYNOPSIS
#define _XOPEN_SOURCE
#include <unistd.h>
char *crypt(const char *key, const char *salt);
DESCRIPTION
crypt is the password encryption function. It is based on the
Data
Encryption Standard algorithm with variations intended (among
other
things) to discourage use of hardware implementations of a key
search.
key is a user's typed password.
salt is a two-character string chosen from the set [a–zA–Z0â€
“9./]. This
string is used to perturb the algorithm in one of 4096 different
ways.
By taking the lowest 7 bits of each of the first eight characters
of
the key, a 56-bit key is obtained. This 56-bit key is used to
encrypt
repeatedly a constant string (usually a string consisting of
all
zeros). The returned value points to the encrypted password, a
series
of 13 printable ASCII characters (the first two characters
represent
the salt itself). The return value points to static data whose
content
is overwritten by each call.
Warning: The key space consists of 2**56 equal 7.2e16 possible
values.
Exhaustive searches of this key space are possible using massively
par-
allel computers. Software, such as crack(1), is available which
will
search the portion of this key space that is generally used by
humans
for passwords. Hence, password selection should, at minimum,
avoid
common words and names. The use of a passwd(1) program that checks
for
crackable passwords during the selection process is recommended.
The DES algorithm itself has a few quirks which make the use of
the
crypt(3) interface a very poor choice for anything other than
password
authentication. If you are planning on using the crypt(3)
interface
for a cryptography project, don't do it: get a good book on
encryption
and one of the widely available DES libraries.
RETURN VALUE
A pointer to the encrypted password is returned. On error, NULL
is
returned.
ERRORS
ENOSYS The crypt function was not implemented, probably because
of
U.S.A. export restrictions.
GNU EXTENSION
The glibc2 version of this function has the following additional
fea-
tures. If salt is a character string starting with the three
charac-
ters "$1$" followed by at most eight characters, and optionally
termi-
nated by "$", then instead of using the DES machine, the glibc
crypt
function uses an MD5-based algorithm, and outputs up to 34
bytes,
namely "$1$<string>$", where "<string>" stands for the up to 8
charac-
ters following "$1$" in the salt, followed by 22 bytes chosen from
the
set [a-zA-Z0-9./]. The entire key is significant here (instead of
only
the first 8 bytes).
Programs using this function must be linked with -lcrypt.
CONFORMING TO
SVID, X/OPEN, BSD 4.3, POSIX 1003.1-2001
SEE ALSO
login(1), passwd(1), encrypt(3), getpass(3), passwd(5)
2001-12-23
CRYPT(3)
It's likely you're seeing the MD5 hash not the DES encryption...
-----Burton
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf
> Of Jaco van Tonder
> Sent: Sunday, February 08, 2004 1:46 PM
> To: [EMAIL PROTECTED]; Burton M. Strauss III
> Subject: Re: [Ntop-dev] [FreeBSD 5.2.1-RC] Web authentication not
> working ?
>
>
> 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
>
_______________________________________________
Ntop-dev mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
