On Tue, May 08, 2012 at 02:38:38PM +0200, Tito wrote: > On Tuesday 08 May 2012 08:37:05 you wrote: > > Hello > > > > On Tue, May 8, 2012 at 1:56 AM, Tito <[email protected]> wrote: > > > So if you plan to allow users to change their secret > > > this file would be readable by all, better store the secret > > > in the users directory than, there it is somewhat protected > > > and you don't have all the trouble about concurrent > > > secret changing attempts. > > > > Possible- yet a useland tool to change /etc/otp would also be possible > > - just like the passwd command. > > > > I don't know what is the best option, even if would tend say a > > /etc/otp file would be better for user without a homedir or which > > should not be able to read their own pinless one-time passwords (ex: > > FTP user) > > > > Maybe both ~/.optw and /etc/otp? > > > > I would tend to say none since I'm not sure that it will be very > > usefull for many people. > > > > It can still be added later if there is a strong demand. > > > > > You guess the time if the server is syncronized with some ntp > > > service, you can peek at the shared secret if you have another > > > account on the server or some malicious software on the client > > > > How exactly do you peek at the secret if the file is root readable only? > > If you will allow users to change their secrets then the file > must be rw like /etc/passwd, unless you use su/sudo > or a setuid binary (or use the users' homedir).
The very fact that we're having a discussion about the redesign of this OTP system on the busybox list seems like proof enough that it's a very specialized need that does not belong on busybox. I'm very much a fan of one-time passwords and I've used several systems in the past, but I would not dream of asking busybox to include one simply because there ARE several and different people have different needs, and including them all would be a mess. Even including one or two increases the already-hideous #ifdef hell. I'm 99% sure this can be taked on to busybox without putting any code in busybox by wrapping the OTP code with some stubs that make its interface compatible with the PAM api, then enabling PAM but changing -lpam to -lotp_pamapi Rich _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
