[Pkg-shadow-devel] passwd behavior
Alexander Gattin
xrgtn at yandex.ru
Tue Apr 4 17:33:28 UTC 2006
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
More information about the Pkg-shadow-devel
mailing list