[Pkg-shadow-devel] passwd behavior

[Alexander Gattin]

Hi!

On Mon, Apr 03, 2006 at 06:34:19PM +0200, Tomasz Kłoczko wrote:
> >AFAIR this is done to make life of password bruteforcer
> >harder. I.e. when he enters wrong _initial_ password,
> >PAM or no-pam-shadow will delay (for e.g. 3s IIRC). By
> >using ^C he/she will be ably to bypass this delay.
> >
> >But when user enters _new_ passwword and _retypes_ it,
> >he/she shouldn't have SIGINT blocked.
> 
> IMO "easier/harder" criteria isn't correct.
> Correct is "it is possible/not possible".

I disagree. All that harder/easier stuff is about
Average Time needed To Break (AT2B). If SIGKILL to suid
root processes is disabled by some security framework
like grsec/selinux (AFAIR there's no such feature in
grsec ATM), pam_unix's or passwd's delay after seeing
wrong password actually helps to increase the AT2B.

Why? Because after supplying wrong password to
passwd, %), the latter binary will hang among processes
for the configured amount of time.

It will consume memory, some CPU time and some limited
resources like nproc.

> Next what I see: in casse "initial pasword" .. there is no initial
> password case :_)
> Why ? OK. Lets look on usual cycle adding new user .. user is added 
> without password (in shadow map sits "x" as password digest).
> Usualy only root can change password.

I see, but this does not invalidate the fact that
during authentication phase we need Unix signalls
blocked.  Just in _this_ case there's no auth phase. :)
Well, actually it is there, but in simplest form
(uid==0).

> In case changeing password on this stage if root 
> will ommit messages like "password is too short" or "based on dictionary 
> word"
> _now_ is powssible bruteforce attack .. and look this is not "initial" 
> password but only "weak" passowrd. Isn't it ?

Heh, if I have root shell, I'll not be interested in
bruteforcing with `passwd`. Usually at this stage no
bruteforcing is ever needed. ;)

> If password is not weak -> is using SIGINT for passwd changes 
> something ? Lokks like .. not :)

Changes! Not right now, though. But I'm sure this
feature (protect suid root binaries from user's
SIGKILL) _will_ be implemented.

> In this variant only is neccessary detecting passwd 
> bruteforce attack (probably can be done on for example logwatch or 
> other syslog log or audit log analiser level).

This is another issue. I have one great idea, but just
too lazy to implement. I'm sure there already exist
very similar pam modules, somewhere...

> Answer is: still _not_. So ..

Agreed. But, _still_. ;)

> My current conclution is: still I'm shure about unblocade SIGINT in 
> passwd.

Tomasz, I think this is not good ATM. More detailed
research is definitely needed.

-- 
WBR,
xrgtn