Date: Thu, 17 Oct 1996 22:25:14 +0400 (MSD) From: "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" (Andrey A. Chernov) <ache@nagual.ru> To: pst@shockwave.com (Paul Traina) Cc: CVS-committers@freefall.freebsd.org, cvs-all@freefall.freebsd.org, cvs-lib@freefall.freebsd.org Subject: Re: cvs commit: src/lib/libskey skey_getpass.c Message-ID: <199610171825.WAA02128@nagual.ru> In-Reply-To: <199610171704.KAA17144@precipice.shockwave.com> from "Paul Traina" at "Oct 17, 96 10:04:20 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> I'm not sure this is a good idea. You want to keep things "stealthy" I already think about it. It very is different from 'don't ask password for nonexisten user' case, because you can even visually detect situation when any password will be incorrect. You'll see following picture if you can't match with _any_ password: login: user (s/key required) Password: It is a bit different from normal case: login: user s/key 99 xx1234 (s/key required) Password: I.e. if "s/key ..." line is missing, it is pretty clear that it is impossible to enter, so removing password asking not makes it less "stealthy". For FTP case the same thing: 331 S/key password required for user. Is a bit different from normal 331 s/key 99 xx1234 response. -------------------------------------------------------------------- BTW, as alternate solution another way is possible, I mean: o Remove "(s/key required)" line if user can't specify any password and still ask for them. o Change 'S/key password..." to usual "Password required..." for FTP responce in the same case and still ask for password. This method makes even your s/key system to be undetected for 1) wrong user names or 2) users not in skey database. It is clearly good for 1) but not so good for 2), so I not decide yet. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Making it for 1) but not for 2) is bad way because allows to determine which user name is valid. S/key already introduce some flaw in this direction, I mean that you receive "s/key 99 xx1234" responce for users from skey database and NOT receive it for users not in the database. So, it can be possible to determine it from outside. We can produce fake "s/key <rnd> xx<rnd>" response, but it pretty well detected for repeatable access to the same name. Any ideas? -- Andrey A. Chernov <ache@nagual.ru> http://www.nagual.ru/~ache/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610171825.WAA02128>