Mailing List Archive

?Bug? with crypt function
Hi,

I think I've discovered a bug with the crypted passwords if the password is
8 or more characters... Hopefully it's not a bug. Basically, when using a
crypted password, if the correct password is appended with random(any?)
characters, then the user is allowed to login. I'm running the v1.2.1 with
no other modifications.

Note: real servername replaced for protection :-)

See attached transcript/log below

Matt

[root@server root]# dbmail-adduser a test {crypt:}testtest 0 0

*** dbmail-adduser ***
Opening connection to database...
Opening connection to authentication...
Ok. Connected
Adding user test with password {crypt:}testtest, 0 bytes mailbox limit and
clientid 0...Ok, user added id [29]
adduser done

[root@server root]# telnet 127.0.0.1 110
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
+OK DBMAIL pop3 server ready to rock <8731.1067127715@server>
user test
+OK Password required for test
pass testtest24436p4rg54g2
+OK test has 0 messages (0 octets)
quit
+OK see ya later
Connection closed by foreign host.

Oct 26 01:21:55 server dbmail/pop3d[8731]: PerformChildTask(): incoming
connection from [127.0.0.1 (server)]
Oct 26 01:21:55 server dbmail/pop3d[8731]: PerformChildTask(): client info
init complete, calling client handler
Oct 26 01:21:56 server dbmail/pop3d[8731]: pop3(): incoming buffer: [user
test]
Oct 26 01:21:56 server dbmail/pop3d[8731]: pop3(): command issued :cmd
[user], value [test]
Oct 26 01:21:56 server dbmail/pop3d[8731]: pop3(): command looked up as
commandtype 1
Oct 26 01:22:04 server dbmail/pop3d[8731]: pop3(): incoming buffer: [pass
testtest24436p4rg54g2]
Oct 26 01:22:04 server dbmail/pop3d[8731]: pop3(): command issued :cmd
[pass], value [testtest24436p4rg54g2]
Oct 26 01:22:04 server dbmail/pop3d[8731]: pop3(): command looked up as
commandtype 2
Oct 26 01:22:04 server dbmail/pop3d[8731]: __auth_query(): executing query
[SELECT user_idnr, passwd, encryption_type FROM users WHERE userid = 'test']
Oct 26 01:22:04 server dbmail/pop3d[8731]: auth_validate(): validating using
crypt() encryption
Oct 26 01:22:04 server dbmail/pop3d[8731]: __auth_query(): executing query
[UPDATE users SET last_login = '2003-10-26 01:22:04' WHERE user_idnr = 29]
Oct 26 01:22:04 server dbmail/pop3d[8731]: pop3(): validation OK, building a
session for user [test]
Oct 26 01:22:04 server dbmail/pop3d[8731]: db_query(): executing [SELECT
mailbox_idnr FROM mailboxes WHERE name='INBOX' AND owner_idnr=29]
Oct 26 01:22:04 server dbmail/pop3d[8731]: db_query(): executing [.SELECT *
FROM messages WHERE mailbox_idnr=29 AND status<002 AND unique_id!="" order
by status ASC]
Oct 26 01:22:04 server dbmail/pop3d[8731]: pop3(): user test logged in
[messages=0, octets=0]
Oct 26 01:22:06 server dbmail/pop3d[8731]: pop3(): incoming buffer: [quit]
Oct 26 01:22:06 server dbmail/pop3d[8731]: pop3(): command looked up as
commandtype 0
Oct 26 01:22:06 server dbmail/pop3d[8731]: pop3_handle_connection(): user
test logging out [messages=0, octets=0]
Oct 26 01:22:06 server dbmail/pop3d[8731]: PerformChildTask(): client
handling complete, closing streams
Oct 26 01:22:06 server dbmail/pop3d[8731]: PerformChildTask(): connection
closed
RE: ?Bug? with crypt function [ In reply to ]
Hello,

There's no bug there - that's how your crypt() works (and
most traditional crypt() implimentations). That was the single
biggest migration pain when we moved to dbmail; users wrote
down 8 char passwords when they signed up, but typed more than
8 chars into their email client. It worked fine under the old
crypt() we had, but with dbmail we moved to md5 hash passwords,
and those users broke. If you want more than 8 chars to be
significant, use md5 passwords (hash, or even md5sum checksums).

jn

---- Original Message ----
From: Matt Dickinson <dbmail-dev@dbmail.org>
To: <dbmail-dev@dbmail.org>
Subject: [Dbmail-dev] ?Bug? with crypt function
Sent: Sun, 26 Oct 2003 01:36:13 +0100

> Hi,
>
> I think I've discovered a bug with the crypted passwords if the password is
> 8 or more characters... Hopefully it's not a bug. Basically, when using a
> crypted password, if the correct password is appended with random(any?)
> characters, then the user is allowed to login. I'm running the v1.2.1 with
> no other modifications.
>
> Note: real servername replaced for protection :-)
>
> See attached transcript/log below
>
> Matt
>
> [root@server root]# dbmail-adduser a test {crypt:}testtest 0 0
>
> *** dbmail-adduser ***
> Opening connection to database...
> Opening connection to authentication...
> Ok. Connected
> Adding user test with password {crypt:}testtest, 0 bytes mailbox limit and
> clientid 0...Ok, user added id [29]
> adduser done
>
> [root@server root]# telnet 127.0.0.1 110
> Trying 127.0.0.1...
> Connected to 127.0.0.1.
> Escape character is '^]'.
> +OK DBMAIL pop3 server ready to rock <8731.1067127715@server>
> user test
> +OK Password required for test
> pass testtest24436p4rg54g2
> +OK test has 0 messages (0 octets)
> quit
> +OK see ya later
> Connection closed by foreign host.
>
> Oct 26 01:21:55 server dbmail/pop3d[8731]: PerformChildTask(): incoming
> connection from [127.0.0.1 (server)]
> Oct 26 01:21:55 server dbmail/pop3d[8731]: PerformChildTask(): client info
> init complete, calling client handler
> Oct 26 01:21:56 server dbmail/pop3d[8731]: pop3(): incoming buffer: [user
> test]
> Oct 26 01:21:56 server dbmail/pop3d[8731]: pop3(): command issued :cmd
> [user], value [test]
> Oct 26 01:21:56 server dbmail/pop3d[8731]: pop3(): command looked up as
> commandtype 1
> Oct 26 01:22:04 server dbmail/pop3d[8731]: pop3(): incoming buffer: [pass
> testtest24436p4rg54g2]
> Oct 26 01:22:04 server dbmail/pop3d[8731]: pop3(): command issued :cmd
> [pass], value [testtest24436p4rg54g2]
> Oct 26 01:22:04 server dbmail/pop3d[8731]: pop3(): command looked up as
> commandtype 2
> Oct 26 01:22:04 server dbmail/pop3d[8731]: __auth_query(): executing query
> [SELECT user_idnr, passwd, encryption_type FROM users WHERE userid = 'test']
> Oct 26 01:22:04 server dbmail/pop3d[8731]: auth_validate(): validating using
> crypt() encryption
> Oct 26 01:22:04 server dbmail/pop3d[8731]: __auth_query(): executing query
> [UPDATE users SET last_login = '2003-10-26 01:22:04' WHERE user_idnr = 29]
> Oct 26 01:22:04 server dbmail/pop3d[8731]: pop3(): validation OK, building a
> session for user [test]
> Oct 26 01:22:04 server dbmail/pop3d[8731]: db_query(): executing [SELECT
> mailbox_idnr FROM mailboxes WHERE name='INBOX' AND owner_idnr=29]
> Oct 26 01:22:04 server dbmail/pop3d[8731]: db_query(): executing [.SELECT *
> FROM messages WHERE mailbox_idnr=29 AND status<002 AND unique_id!="" order
> by status ASC]
> Oct 26 01:22:04 server dbmail/pop3d[8731]: pop3(): user test logged in
> [messages=0, octets=0]
> Oct 26 01:22:06 server dbmail/pop3d[8731]: pop3(): incoming buffer: [quit]
> Oct 26 01:22:06 server dbmail/pop3d[8731]: pop3(): command looked up as
> commandtype 0
> Oct 26 01:22:06 server dbmail/pop3d[8731]: pop3_handle_connection(): user
> test logging out [messages=0, octets=0]
> Oct 26 01:22:06 server dbmail/pop3d[8731]: PerformChildTask(): client
> handling complete, closing streams
> Oct 26 01:22:06 server dbmail/pop3d[8731]: PerformChildTask(): connection
> closed
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
-- End Original Message --


--
Jesse Norell
jesse (at) kci.net
RE: ?Bug? with crypt function [ In reply to ]
Jesse Norell wrote:
> Hello,
>
> There's no bug there - that's how your crypt() works (and
> most traditional crypt() implimentations). That was the single
> biggest migration pain when we moved to dbmail; users wrote
> down 8 char passwords when they signed up, but typed more than
> 8 chars into their email client. It worked fine under the old
> crypt() we had, but with dbmail we moved to md5 hash passwords,
> and those users broke. If you want more than 8 chars to be
> significant, use md5 passwords (hash, or even md5sum checksums).
>
> jn

Thanks for confirming, I had a feeling it might have been something like
this as soon as I hit the sent button.

Sorry for causing any alarm,

Matt